We evaluate every codebase against the same seven checks: the product, its size, how much of it is original, its git history, its docs and tests, the rights, and any sensitive data inside it. A codebase that passes them gets a cash offer. One that needs a closer look on one point gets an answer that names that point. One that is clearly not a fit gets a no, with the reason. How we value a codebase is explained on the call.
Why do we start from what you tell us, not from your code?
The first review is based on what you tell us through the homepage form and on a short call. No code changes hands before a signed written agreement, and we never ask anyone to install or run anything on their computer. That is deliberate. A fair buyer does not need your code, or access to your machine, before a contract exists. If anyone sends you a script to “scan” your repository, do not run it on a computer that holds your code or credentials. The guide to red flags when someone offers to buy your code lists the other warning signs.
What are the seven checks?
| Check | What we ask | What we hope to see |
|---|---|---|
| Product | What it was and whether it still earns | A real product that no longer makes money |
| Size | Roughly how many lines, in which languages | A complete product, not snippets |
| Originality | Who wrote most of it | Mostly code your own team wrote |
| History | Whether the repository and its history survive | Commits, branches, pull requests, reviews |
| Docs and tests | What exists beyond the code | Some docs, some tests, ticket exports |
| Rights | Who owns the code | You, or a company you can sign for |
| Sensitive data | Secrets and personal data in the code | Known, and removable before transfer |
1. Is it a real product that no longer earns?
We buy the source code of real products: web apps, mobile apps, SaaS, platforms and marketplaces, games, backends and APIs, and internal tools. The product can be shut down, abandoned, obsolete or never launched, and it can still be online or fully offline. What it must not do is make money today. Software that still earns is a running business, and a running business belongs with a marketplace or a broker, not with us.
2. How big is the codebase?
Size is one of the factors that shape value, along with the languages used. We ask for a rough count of lines of code, and a bucket is enough: under 10,000, 10,000 to 50,000, 50,000 to 250,000, or more. If you want a number, free counters such as cloc and tokei report lines by language, but we never ask you to run anything. A small but complete product can still qualify. A handful of snippets does not. The guide on how to count lines of code explains what to leave out of the count.
3. How much of it did your team write?
We buy original code: the part your own team wrote. Open source inside it is normal. Black Duck found that 98% of the commercial codebases it audited for its 2026 report contained open source components. Those libraries are third-party code and stay under their own licenses, with their notices kept in place. What we pass on is a repository that is mostly a template, a fork, a tutorial project, copied libraries or generated code, because then there is little original work in it.
4. Is the git history still there?
Git history shows how and why the software changed: commits, branches, pull requests and code reviews. That record of decisions is part of what makes real-world code useful for AI training and R&D, so full history adds to value. Code without history is still sellable. A zip export usually carries only the latest files, so if the original repository still exists on GitHub, GitLab or Bitbucket, keep it. The guide on why git history makes old code worth more goes into detail.
5. Are there docs, tests and project records?
Technical documentation, a test suite, ticket exports from Jira, Linear or GitHub Issues, design files and documented processes such as runbooks all add to the picture. None of them is required. Each one shows what the code was meant to do and how the team checked it worked, which is why docs and tests are among the factors behind value.
6. Can you sign for the rights?
You must own the rights or be able to sign for the company that does. In the US, code an employee writes as part of the job is a “work made for hire” owned by the employer, while code from an outside contractor usually needs a signed IP assignment. Client work you have no rights to is a no. Co-founder or contractor gaps are common and can often be sorted out. This is general information, not legal advice: for your case, ask a qualified lawyer. The guide on who owns the code covers founders, employees, contractors and agencies.
7. What sensitive data is inside it?
Old code often holds things that must not travel: API keys, passwords and tokens in environment files or config files, and personal data in seed files, fixtures and logs. GitGuardian reports that 32.2% of internal repositories contain at least one hardcoded secret. Finding them is not a reason to stop. Any key that was ever committed should be revoked or rotated first, because deleting a file does not remove it from git history. Secrets, keys and personal data are then removed before transfer, and we help; the guide on removing API keys and passwords from old code explains the order of steps. Personal data rules vary by country, so this is general information, not legal advice. We never take databases, user records, customer data or chat logs.
What are the three outcomes?
Every review ends in one of three answers, and we tell you which one.
- Offer. The code meets what we look for. We make a concrete cash offer: one agreed price, paid on transfer, with no earn-outs and no obligation to accept. Terms are set out in a written agreement before any transfer.
- A closer look. One point needs attention, for example rights that depend on a contractor’s sign-off, or a codebase on the small side. We explain what it is and what would usually resolve it.
- Not a fit. The software still makes money, it was client work, it is mostly a template or copied code, or several points fall short. We say so and explain why, so you can decide what to do next with a clearer view.
What are the limits of these checks?
Two limits matter most. First, the review starts from what you tell us, so it is only as accurate as the answers. The written agreement describes what is being transferred, which is why it pays to be precise about size, history and rights from the start.
Second, a no from us is not a verdict on the work. We pass on software still making money because it belongs with a buyer of running businesses, and we pass on client work because the rights sit with someone else. Neither says anything about the quality of what you built.
What to do next
- Run the free code value check to see roughly where your code stands against these checks.
- Find the original repository and confirm who holds admin access to it.
- Send us a few details for a free code valuation and we will come back with one of the three outcomes.
Frequently asked questions
Do you need to see my code before you make an offer?
No. The first review is based on what you tell us about the product, its size, who wrote it, its history, docs and tests, and who owns the rights. No code changes hands before a signed written agreement, and we never ask you to install or run anything. Be wary of anyone who wants your code, or access to your machine, before a contract exists.
Do you tell me how you price a codebase?
How we value a codebase is explained on the call. Value depends on size, originality, languages, quality, history, docs and tests, and the offer is made after review. This page describes what we check and the three outcomes a review can end in. Payment is cash only, one agreed price, paid on transfer.
My code uses lots of open-source libraries. Is that a problem?
No. Open source is normal in commercial software, and using libraries does not stop a sale. What we look at is the code your own team wrote on top of them. Third-party code stays under its own license, so keep its license notices in place. A repository that is mostly a template, a fork or copied libraries is a different case, and that one we pass on.
What if I am not sure who owns the rights?
That is common, especially where contractors or co-founders were involved. Unclear rights are usually a point to sort out rather than an automatic no. On the call we can explain what is normally needed, such as a written assignment from a contractor. This is general information, not legal advice; a qualified lawyer should look at your specific case.
Will you take our database or user data?
No. We never take databases, user records, customer data or chat logs. Before transfer, secrets, keys and personal data are removed from the code, including from seed files, fixtures and logs, and we help you do it. What we buy is the code, its history, docs, tests and related project material, not the people who used the product.
Find out what your old code is worth right now.
Tell us about the product in about a minute. No code needed. We review the details and come back with a cash offer or a plain no.
Get my free code valuation →