How Selling Your Old Code Works, From First Message to Payment

Selling old code to Odys AI Labs is a short, ordered process: you describe the product in a form, we talk, we review what you told us, we make a cash offer, both sides sign a written agreement, secrets and personal data are removed, the code is transferred and you are paid on transfer. Nothing about your code leaves your hands before the agreement is signed. Each step below says what you do, what we do and what usually decides how long it takes.

What does the whole process look like at a glance?

Here are the eight steps in order. Most sellers spend the most effort on steps 5 and 6, because that is where paperwork and cleaning happen.

The column on the right is the point of the whole design. A fair buyer does not need your source code to decide whether it is interested, and you should never have to hand it over before you have a signed contract.

Step 1: What do you tell us in the 60-second form?

The form asks for the basics, with no code and no attachments: what the product was, what kind of software it is (web app, mobile app, SaaS, game, backend or internal tool), whether it makes any money today, roughly how big it is, how much your team wrote, whether you still have the git history, whether there are docs and tests, and who owns the rights.

You do not need exact numbers. If you want a rough size before you start, free counters such as cloc and tokei will tell you lines of code by language in a minute, and our guide on how to count lines of code explains what to leave out. If you are unsure whether your code fits at all, the free code value check asks the same questions and gives a plain verdict.

When you are ready, send us a few details for a free code valuation. That is the only way to start; we never ask you to email files.

Step 2: What happens on the first call?

The call is a conversation, not an audit. We ask how the product came about, why it stopped, who built it and what is left: repositories, branches, pull requests, documentation, tickets, design files. You ask whatever you want about us and about what happens to the code.

This is also where we explain how we value a codebase. Our method is ours, but the factors are not secret: size, originality, languages, quality, history, docs and tests. How they combine is explained on the call. The methodology page lists what we check.

Bring the person who can answer ownership questions. If the code belongs to a company, that might be a co-founder or a director rather than the lead developer.

Step 3: How can a review happen without seeing the code?

The review is based on what you tell us. We look at whether the product qualifies: shut down, abandoned, obsolete or never launched; making no money today; original code written by your own team; a complete product rather than snippets; and rights you own or can sign for on behalf of the company that owns them.

We may come back with follow-up questions. Typical ones are which parts came from outside libraries, whether a contractor wrote a large module, whether there is customer data mixed into the repository, and whether the history goes back to the first commit. Honest answers here matter more than polished ones, because the written agreement will later ask you to confirm them.

Some codebases are not a fit, and we say so plainly rather than make a low offer. The two most common reasons are that the software still makes money, in which case a marketplace for running businesses is the better route, or that the seller does not hold the rights, as with client work. The full list of what we pass on is in our guide on what old source code is still worth.

Step 4: What does the cash offer look like?

If the review goes well, you typically receive a concrete cash offer. It is a single price, not a range or a formula, and it is the whole price: no earn-outs, no royalties and nothing tied to what happens to the code later.

You are under no obligation to accept. Take the time you need, ask questions, and talk to a co-founder, an investor or an accountant. Many sellers ask how the sale will be taxed before they say yes; our guide to taxes when you sell source code summarizes the main rules in the US, UK, EU, Canada and Australia.

If you decline, nothing changes: you keep your code and owe nothing.

Step 5: What goes into the written agreement?

Once you accept, both sides sign a written agreement before any code moves. In many countries this is not just good practice but the law for transferring copyright. In the US, a transfer of copyright ownership is not valid unless it is in writing and signed by the owner or an authorized agent, and in the UK an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the seller.

The agreement usually covers what is being sold, the assignment of rights, your confirmations about ownership and originality, the cleaning you will do before transfer, how the transfer happens and when you are paid. Our guide to what is in a source code purchase agreement walks through each part in plain English.

This is general information, not legal advice. Have a qualified lawyer read the agreement, especially if the code belongs to a company, a dissolved company, an estate or a business in insolvency. If you are not sure the company still owns the code, our guide on who owns the code explains the usual gaps, such as contractor work without a signed IP assignment.

Step 6: What has to be cleaned before transfer?

Before anything is handed over, secrets, keys and personal data come out. We help you do it.

Secrets are things like passwords, API keys, tokens and private certificates. They often sit in an environment file (.env), config files, deployment scripts or old commits. Private repositories are where they hide most: GitGuardian found that 32.2% of internal repositories contain at least one secret, against 5.6% of public ones. Deleting the file in a new commit is not enough, because GitHub’s own documentation notes the data will still be available in the repository’s history.

The usual order is simple. First revoke or rotate every key that was ever committed, so it no longer works. Then scrub history with git-filter-repo, the tool both Git and GitHub point to. Our guide on removing API keys and passwords from old code explains each step without assuming you are a developer.

Personal data comes out too: seed files, fixtures, logs, test accounts with real emails, exported customer lists. We never take databases, user records, customer data or chat logs, so anything like that stays with you or is deleted, as your own obligations require. Those obligations depend on where you and your users are; this is general information, not legal advice, and a qualified lawyer can confirm what applies to you.

Step 7: How does the transfer actually happen?

The transfer covers exactly what the agreement lists, typically the cleaned repository with its history, plus any docs, tests, ticket exports and design files you agreed to include. On GitHub, a repository can be transferred to another account with its issues and pull requests, which keeps the history intact. Other routes, such as a bundle of the git repository, work too. The agreement names the method.

At no point do we ask you to install anything, run a script or give remote access to your machine. If anyone in any deal asks for that, stop: our list of red flags when someone offers to buy your code explains why.

Step 8: When are you paid?

You are paid the agreed cash price on transfer, as the agreement sets out. One price, one payment moment, no conditions about how the code performs afterwards.

After the sale, Odys AI Labs uses the code for AI training and R&D: models learn to read, write and fix real software. We may also work on it with research partners. We never use your brand or name, never relaunch the product as yours, and keep the sale confidential.

What usually slows a sale down?

We do not promise durations, because most of the time sits on the seller’s side and differs a lot between cases. A few things come up again and again:

• Unclear ownership. A contractor who wrote a core module without an assignment, or a co-founder who left and never signed anything.
• Authority to sign. A company needs the right director, a dissolved company may need restoring, and a liquidator or executor needs to confirm their role.
• Secrets deep in history. Rotating keys is quick; rewriting history across many repositories takes care.
• Mixed-in customer data. Fixtures and logs with real records need finding and removing.
• Scattered repositories. Code spread across personal accounts, old hosting and laptops needs gathering first.

Our guide on how to prepare a codebase for sale covers each of these in order, and doing it before the call is the single best way to keep things moving.

What if the old product also had a website?

Many shut-down products leave behind a domain and a site that still gets visits. The code and the website are separate assets. If the site still has real traffic, our sister service TheBlueOceanWebsites.com buys websites of former businesses, so you can deal with both without relaunching anything.

What to do next

• Write down what you still have: repositories, where they live, and who has admin access.
• Check who owns the code and who can sign, using the ownership guide above.
• When you are ready, send us a few details for a free code valuation.