How do you value software and source code?
There are four standard methods. Cost to rebuild asks what it would take to write the code again. A revenue or earnings multiple prices the cash flow the software produces. Comparable sales look at what similar software sold for. Licensing value asks what someone will pay to use the code itself. Software with revenue is usually valued on the second. Code with no revenue or users is valued on the fourth, because AI labs pay to license real source code and git history to train coding models. The license is non-exclusive, so you keep ownership and are paid each time. Get a valuation to see your figure.
What are the main software valuation methods?
Each method answers a different question, and each needs different evidence.
| Method | Best for | Needs revenue? |
|---|---|---|
| Cost to rebuild | Accounting, insurance, tax, internal tools | No |
| Revenue or earnings multiple | SaaS and app businesses with paying customers | Yes |
| Comparable sales | Businesses similar to recent public deals | Usually |
| Licensing value | Idle or shelved code, private repos, code with no users | No |
Cost to rebuild
This method estimates the hours a team would need to write the software again and prices them at a market rate. Some versions use lines of code or function points to estimate effort. It is the usual basis when software sits on a balance sheet, when it is insured, or when it moves between related companies for tax purposes.
Its weakness is that it measures cost. A codebase that took three developer-years to write is not worth three developer-years to a buyer unless that buyer needs exactly that code and cannot build it more cheaply. Most buyers can, or think they can.
Revenue or earnings multiple
This is how most software businesses are priced. A buyer takes annual recurring revenue, or profit for smaller products, and multiplies it. The multiple rises with growth, low churn, high margins and low dependence on the owner. A discounted cash flow model is a more formal version of the same idea: it projects future cash and discounts it to today.
It is the right method when there is revenue to multiply. When there is none, it returns zero, which is why a pre-revenue SaaS or an app with no users is so hard to sell as a business.
Comparable sales
This method looks at what similar software or software companies sold for and adjusts for differences. It is common in acquisition work and in appraisals. In practice, comparables are usually quoted as revenue or profit multiples, so the method still leans on revenue. Private code with no product attached has few public comparables.
Licensing value
This method prices the right to use the code itself. Historically it applied to software that other companies paid to embed or run. Today it also applies to any real private codebase, because AI labs license source code and git history to train and evaluate coding models. They pay for the code and its history, whether or not the product ever earned anything.
Which valuation method should I use?
Match the method to what the software has:
- Revenue and growth: a multiple of revenue or earnings, checked against comparable sales.
- A balance sheet, an audit or an insurance policy: cost to rebuild.
- A strategic buyer who needs the technology: cost to rebuild sets a floor, and comparables help.
- No revenue, no users, or a product you have stopped running: licensing value.
The methods can sit side by side. A live SaaS can be valued on its revenue for a future sale and still license its code to AI labs today, since a non-exclusive license leaves ownership with you.
Why is code with no revenue valued on licensing value?
Because the other methods have nothing to work with. A multiple of zero is zero. Comparables for private, unreleased code barely exist. Cost to rebuild gives a number, but no one pays it. Licensing value is the one method backed by buyers paying today for code on its own merits.
AI labs pay because real production code is an input they cannot generate. Public code is already in their training data. What they lack is the private software companies and developers kept to themselves: shelved products, internal tools, dead startups and side projects. Revenue, users, design and whether the code still builds make no difference to them. Size, history depth, tests and realism do. For why labs pay at all, read sell code for AI training.
How is licensing value calculated?
By the token. A token is a short chunk of text, roughly three or four characters of code. Source code and git history are counted separately and paid at different rates:
Value per license = source tokens × $100 per million + history tokens × $40 per million
Take an illustrative repo: an invoicing platform shelved in 2024, with 0.6 million source tokens and 23.5 million history tokens. The source pays its share at the source rate. The history, nearly forty times larger, pays at the history rate and supplies most of the value. Together they come to about one typical repo’s worth, in the range of $1,000 to $1,500 per license.
That pattern holds across the licensing program, where history makes up about 79% of licensed tokens. A few years of genuine commits usually outweigh the final source many times over.
Third-party code is left out of the count. Vendored libraries, generated files and dependencies belong to someone else. Only your own code and the history of how you changed it are counted.
What makes source code more valuable?
Four things move the figure:
- Source tokens. How much real code there is.
- History depth and realism. Years of genuine commits, fixes and refactors. Squashed or generated history is worth far less.
- Tests. They show what the code is meant to do, and labs use them to grade models.
- Buyer demand. Some languages and domains are scarcer than others. Demand decides how often a repo is licensed.
By depth, a light repo earns about $400 to $700, a typical repo about $1,000 to $1,500, and a deep repo about $2,500 to $4,000 per license. A few long-lived codebases with years of production history and tests have earned tens of thousands of dollars. These are illustrative, conservative ballparks of what the owner takes home, and a repo can fall outside its band in either direction. Licenses are non-exclusive, so the same repo can be paid again.
For an interactive estimate by number of repos and depth, use the estimator on how much is my code worth. For general software and internal tools, see sell software source code.
How do I get a real valuation of my code?
Connect it. Estimates by depth are a starting point, and a real figure needs a token count of your actual repos. Request access, sign the agreement once and give read-only access to GitHub, GitLab or Bitbucket for only the repos you choose. A per-repo estimate appears within minutes, with no commitment and no upfront cost. Secrets and personal data are stripped from the review copy before any buyer sees it, and your repository is untouched.
Get a valuation to see what your code is worth.