You Have Code From an Old Side Business or Venture

Side businesses end quietly. The evenings run out, a new job takes over, or the niche turns out to be smaller than hoped, and the code goes into a personal GitHub account and stays there. If that code is a complete product you wrote, it still has value. Odys AI Labs, the research and development arm of Odys, buys the source code of software people no longer use, for cash, to use for AI training and R&D. A side business is one of the most common sources.

What your code is likely still worth

Side-business code has a particular strength: it is usually almost entirely original code, written by one or two people who made every decision themselves. It often spans the whole product, from the database schema to the front end, the billing integration and the deployment scripts. The history tends to be honest, too, with small commits, false starts and fixes for real customer problems.

Suppose a developer spent three years running a scheduling tool for driving schools: a Django back end, a Vue front end, an SMS integration and a small admin dashboard, all written alone, with a few hundred commits. The business stopped when the main customers moved to a larger platform. That is a complete product with a clear author, which is what a buyer wants to see.

The weak points are usually size and finish. A product built in evenings may be smaller than a funded startup’s, have fewer tests and thinner documentation. That does not rule it out; it changes the offer. To get a sense of scale, our guide on counting lines of code shows how to use cloc or tokei and what to exclude. We do not publish price figures; the offer typically comes after review, and how we value a codebase is explained on the call.

What a buyer will check

• Is it a product? Something that ran for real users or a real client, not a tutorial, template or fork.
• Is it yours? Written by you, or by people who assigned their rights to you. If you ran the venture through an LLC or limited company and wrote the code for it, the company may be the owner, and then the company is the one that signs.
• Is it free of your employer’s claims? See the first risk below.
• Does it make money today? It must not. A side business still earning is not something we buy.
• What else is in the repo? Personal files, keys and customer data.

Three risks specific to this situation

1. Your employment contract. This is the risk most specific to side projects. In the US, code an employee writes as part of the job is a work made for hire, owned by the employer, and in the UK the employer owns code staff write in the course of their job, unless agreed otherwise. Many contracts reach further, claiming anything related to the employer’s business or built on company equipment. If you built the side business on a work laptop, during work hours or in your employer’s field, read the IP clause closely. Our guide on who owns the code explains the basics. This is not legal advice; an employment lawyer can confirm where you stand.

2. A friend who helped. Side businesses are often built with a friend, a partner or a freelancer paid in favors. Whoever wrote code owns it first, unless there is a written assignment. If someone else wrote a meaningful part, get their written agreement before selling. It is usually a short conversation, and much easier while you are still in touch.

3. Personal and client material mixed into the repo. A personal account blurs lines. The same repository may hold a freelance client’s code, your dotfiles, a personal .env with your own cloud keys, and a few customer emails in a test file. Client work you have no rights to is not part of a sale. Separate the product from everything else, rotate any personal keys that were ever committed, and remove personal data. Our guide to personal data in old code lists where it hides, including commit author emails and log files.

What to do this month

1. Gather every repository the product used: app, API, admin panel, scripts.
2. Check the history is complete and pushed, not only on an old laptop.
3. Read your employment contracts from the years you built it, especially IP and invention clauses.
4. List everyone who wrote code and whether they signed anything.
5. Move client work and personal files out; rotate keys that were ever committed.
6. Write a one-page overview: what the product did, who used it, when it ran, the stack.

Your options

One point matters to many side-business owners: we never use the seller’s brand or name and never relaunch the product as theirs. Odys AI Labs uses the code for AI training and R&D after cleaning, and we may also work on it with research partners. Sales are confidential; we do not publish who we buy from.

Taxes depend on where you live and how you held the code. In the US, a copyright you created yourself is usually not a capital asset, so the sale is generally ordinary income. Our overview of taxes when you sell source code covers other countries. This is not tax advice; ask an accountant.

Keep the process safe. We never ask you to install or run anything, and no code changes hands before a signed written agreement. If someone offers to buy your side project but wants a copy of the code, or wants you to run their scanner on your machine, before any contract exists, walk away.

What to do next

• Separate the product’s repos from personal and client material.
• Check your employment contracts and talk to anyone who co-wrote it.
• Send us a few details for a free code valuation; it takes about a minute and needs no code.