How to Sell Startup Assets to AI Labs

When a startup closes, useful details about its software can be lost. Tool subscriptions end, private packages become hard to access, and engineers leave. Save the code and its history while the team can still explain how it works.

An AI buyer may be able to use those records to train or test agents. At HUD, we build tools for agents to practice tasks in software, which helps explain why this history matters. DataVendor gives owners a way to offer their code and data to buyers.

Save the code and records

Export repositories with their history. Keep the links to issues, reviews, documents, and tests. Record the dates, versions, and tools behind each export.

Ask an engineer to write up one example from start to finish: the reported problem, the old code, setup steps, and the checks used to confirm the fix. This can reveal missing pieces while someone still knows where to find them.

Keep the original archive secure. Use separate copies for rights review and delivery. Follow the company's recordkeeping and shutdown requirements when deciding what to save or delete.

Document one part of the product

You may not have time to explain every service and every year of history. Start with one part of the product that has clear records and someone who still understands it. This gives a buyer a useful example and helps the team estimate the effort to prepare more.

For example, consider an internal reporting tool. You might save a request for a new report, the code before it was added, the final change, and a test that checks the output. Write down where the input records came from and whether they can be shared or need to be replaced.

Have another team member try to follow the setup notes. If that person cannot run the example without asking the original engineer, add the missing steps. You do not need perfect documentation of the entire company to make one package understandable.

Record limits as you find them. A missing attachment, an expired package, or an untested old version is useful information for a buyer. It helps define the work left to do and keeps the description accurate.

Check what will run after shutdown

Run a small example and record each outside dependency: company logins, hosted databases, private packages, and services you plan to cancel. Keep access to live customer systems out of the buyer package. Document an approved replacement setup where the buyer needs one.

For example, a report that reads from a customer database might run against a small test database instead. That can preserve the exercise without preserving every feature of the live system. Explain what the test records cover and what they leave out.

Some dependencies may be replaced with a small local service; others may be too costly to recreate. Test the replacement before promising a working environment. Be clear whether the offer includes saved files, working software, or material the buyer could turn into tasks later. The setup should not depend on someone keeping a personal account active after leaving the company.

Set limits on extra work

A buyer may be interested in the code without asking you to build a training environment. If it does ask for new tasks or a working setup, compare the request with the time your team has left.

Linking a few issues to their fixes may be manageable. Getting years of old software versions to run could take much longer. Agree on what is included, what costs extra, and what you will be able to support after delivery.

Write down the stopping point for the team's work. For example, the agreed job might end when a reviewed archive and one working example have been delivered. A clear finish line lets the buyer plan what it will own next and helps the company avoid leaving open tasks in the hands of people who have already left.

Review rights and deal terms

Review who owns the work, what contracts allow, and what approvals are needed. Flag private records, code funded by customers, third-party materials, and any creditor claims for legal review.

A sale transfers ownership of the items named in the deal. A license can let the company retain ownership while allowing agreed uses. If the company is closing, decide who can hold the rights and manage any ongoing agreement. Work through this with legal counsel as part of the shutdown plan.

Compare offers on what you will keep after costs, when payment arrives, and what work remains. Treat possible future sales separately from money you can count on for the closure.

Agree on support

A buyer may need help understanding old code after delivery. Discuss that work before signing. Name the person who can answer questions, the period when they will be available, and the kinds of help included in the price.

Separate explaining the existing package from building new features or tasks. A short call about setup is different from weeks spent repairing an unsupported library. If the buyer wants continued development, it needs a clear plan and someone able to take on that work.

Include a review step before the final handoff. Let the buyer run the agreed example and raise specific issues while the relevant engineer is still available. Record the fixes and any limits both sides accept.

If no one will remain to provide support, say that early. The offer can then focus on the files and notes the company can deliver, with the buyer deciding whether it can handle the remaining work. Clear expectations are especially important when there will be no team to return to later.

Prepare the handoff

Make a list of the files, setup steps, useful examples, and anything left out. Name the person who can approve sharing and the person who can answer technical questions. Include the deadline for a deal and how much work the team can still do.

Use that description to register the codebase in DataVendor Inventory. If the package is ready, follow the listing process. Let the buyer's needs guide any work beyond saving and explaining the existing code.

Frequently Asked Questions

What should I save before my startup shuts down?

Export repositories with their history, and keep the links to issues, reviews, documents, and tests. Record the dates, versions, and tools behind each export. Keep the original archive secure, and follow the company's recordkeeping and shutdown requirements when deciding what to save or delete.

Do I need to document the whole product?

No. Start with one part of the product that has clear records and someone who still understands it. You do not need perfect documentation of the entire company to make one package understandable.

What if the software depends on services we plan to cancel?

Run a small example and record each outside dependency. Keep access to live customer systems out of the buyer package, and document an approved replacement setup where the buyer needs one. Test the replacement before promising a working environment.

Who holds the rights if the company is closing?

Decide who can hold the rights and manage any ongoing agreement. Work through this with legal counsel as part of the shutdown plan.

What if no one will remain to provide support?

Say that early. The offer can then focus on the files and notes the company can deliver, with the buyer deciding whether it can handle the remaining work.