How Codebase Value Is Measured: Size, Originality, History, Quality and Rights

Codebase value is measured on five factors: how big the original code is, how much of it your team actually wrote, how much history comes with it, how good it is (including docs and tests), and whether the rights are clean enough to sell. Languages run through several of them. Each factor can be checked first from what you tell a buyer, then confirmed after a contract is signed, so nobody needs your code to give you a first answer.

This guide takes each factor in turn: what it means, how it is checked without sharing code, and where a product that stopped running can still score well. How we value a codebase, meaning how the factors are weighed into a cash offer, is explained on the call. What follows is the part any owner can use on their own.

The five factors at a glance

Notice what is missing: revenue, users, traffic and whether the servers are still on. Those matter for selling a running business. They do not matter when the code is bought for AI training and R&D, which is what Odys AI Labs, the research and development arm of Odys, does. Our pillar guide on what old source code is still worth explains why.

How do the factors trade off against each other?

The factors are not a checklist where every box must be ticked. A strength in one can make up for a weakness in another, within limits. Two illustrations make the point.

Suppose a three-person team spent five years on a logistics platform: around 120,000 lines, almost all their own, with full history on GitHub, but very few tests and only a short README. Size, originality and history are all strong. Thin tests and docs lower the picture somewhat, but the long, honest history explains much of what the docs do not.

Now suppose an agency built a polished mobile app over six months: around 15,000 lines, a good test suite and clean docs, but half the code came from a purchased template and the repository was squashed into a single commit before it was archived. Quality looks good, yet originality and history are weak, and that usually matters more.

Rights sit apart from the trade-offs. Strong scores on the other four cannot make up for code you are not able to sell. If ownership is unclear, that is the first thing to fix, and it usually can be fixed.

Size: how much real software is there?

Size is the easiest factor to measure and the easiest to get wrong. Lines of code is a crude measure on its own, but it is a fair first signal of how much work a product represents, especially when it is broken down by language.

Two free tools do this well. cloc counts blank lines, comment lines and physical lines of source code in many languages. tokei does the same job quickly and supports over 150 languages. Both run on your own machine and send nothing anywhere. Nobody needs you to run them to make an offer; they are simply a good way to answer the size question for yourself.

What matters is excluding what your team did not write:

• Package folders such as node_modules, vendor, Pods or packages.
• Build output, dist folders and compiled assets.
• Minified JavaScript and CSS.
• Code produced by generators, such as API clients or ORM models created from a schema.

Our guide on how to count lines of code walks through it and shows how to turn the count into a size bucket. Languages matter here too: a mix of backend, frontend and mobile code shows a complete product, and a less common language can be interesting precisely because less of it is available anywhere.

Originality: how much did your team write?

Originality is the share of the codebase that is your team’s own work. It is the factor owners most often misjudge, in both directions.

Almost every commercial codebase includes open source. Black Duck’s 2026 open source report found open source in 98% of the 947 commercial codebases it audited, and in its 2025 report, about 70% of scanned code had open source origins. That is normal and does not stop a sale. What is sold is the original code your team wrote; third-party code stays under its own license and is not what anyone is paying for.

Originality is low when a repository is mostly:

• A fork of an open-source project with light changes.
• A purchased template or theme with a few custom screens.
• A tutorial project or course exercise.
• Generated code from scaffolding tools, low-code platforms or schema generators.

Originality is high when your team designed the data model, wrote the business logic, built the API and handled the hard edge cases themselves. An honest estimate, such as “about 80% ours, the rest is libraries and a generated API client”, is all that is needed at the start. Our guide to open source inside your codebase covers licenses in more detail.

History: can you see how it was built?

Git history is the record of every commit: what changed, when, by whom and, in a good message, why. Branches show parallel work. Pull requests and code reviews show the discussion around a change, including what was rejected.

For learning how software gets fixed and improved, history is often the most instructive part of a codebase. A snapshot shows the final state; history shows the path, including the bugs and the fixes. That is why a full history raises value and a zip export with no history lowers it.

To check what you have without sharing anything, look at three things: whether the repository still exists on GitHub, GitLab or Bitbucket with all its commits; whether pull requests and their review comments are still there; and whether anyone holds a full local clone. Our guide on why git history makes old code worth more explains how to export it safely.

Quality: is it coherent, tested and documented?

Quality here does not mean perfect code. Real production code has rough corners, and that is part of what makes it useful. Quality means the code hangs together as a real product, and that there is material explaining it:

• Tests. A test suite shows what the code was supposed to do. Even partial coverage helps.
• Documentation. READMEs, architecture notes, API docs, setup guides. This is technical documentation in the broad sense.
• Tickets. A ticket export from Jira, Linear or GitHub Issues links problems to the changes that fixed them.
• Designs and processes. Figma files, runbooks and SOPs show how the product was meant to work and how it was operated.

Each item can be described in a sentence before any review: “about 400 tests, mostly backend; a docs folder; three years of Linear tickets”. Our guide on docs, tests, tickets and designs covers what each one adds and what to leave out.

Rights: can you legally sell it?

Rights decide whether a sale can happen at all. You can only sell code you own, or code owned by a company you can sign for.

Owning code does not depend on registering it. Under the Berne Convention, copyright protection must not depend on any formality, and across the EU software is protected by copyright as a literary work, the same way a book is. So the rights question is never “is it registered?” but “who was the first owner, and has ownership passed on in writing since?”

A buyer checks that with three plain questions, all of which you can answer without opening the code:

• Who wrote each major part? Founders, employees, outside contractors or an agency.
• Under what paper? Employment contracts, contractor agreements, any signed IP assignment. Employee code generally belongs to the employer; contractor code often needs an assignment before the company owns it.
• Who can sign today? A director, all co-founders, a liquidator or an executor, depending on what happened to the owner.

The common gaps are contractor code without an assignment, agency client work, co-founders who left without signing anything, and companies that have been dissolved. Most are fixable with a signature from the right person. Our guide on who owns the code explains the US, UK and EU rules and how each gap is usually closed, and the guide to preparing a codebase for sale lists the documents to gather. This section is general information, not legal advice. A qualified lawyer can confirm ownership for your specific case.

What lowers the score, whatever the factors?

Some code is ruled out before the factors are weighed at all: most often because the software still makes money or the seller has no rights to it. The full pass-on list is in our guide on what old source code is still worth.

Sensitive data is a different matter: it lowers nothing if it is handled properly. Secrets, keys and personal data are removed before transfer, and we help. We never take databases, user records, customer data or chat logs. Hardcoded secrets are common: GitGuardian found that private company repositories are about six times more likely than public ones to hold them. That is fixable, and it is not a reason to give up on a sale.

How is all this checked without anyone seeing your code?

Every factor above starts as a sentence you write, not a file you send. The first review works from those answers; code is only seen and transferred after a written agreement is signed, once secrets and personal data are out. If the answers point to a fit, you typically receive a concrete cash offer. The full sequence, from the form to payment on transfer, is in our guide on how selling your old code works.

That order protects you. A fair buyer never needs your code before a contract and never asks you to install or run anything. If anyone asks you to run a script on a machine that holds your code or credentials, refuse. Our page on how we evaluate a codebase sets out the checks and the possible outcomes.

What to do next

• Write one line per factor: size by language, share that is original, state of history, tests and docs, and who owns the rights.
• Run the free code value check for a first verdict.
• Send us a few details for a free code valuation, with no code and no obligation.