You can make money from code you already wrote in five realistic ways: sell it as a product, package parts of it as templates or plugins, use it to win freelance work, ask for open source sponsorship, or license it to AI labs as training data. The first four need something extra, usually users, polish or more of your time. The fifth does not. AI labs license real source code and the git history behind it to train coding models, and they pay for code that never found a market. The license is non-exclusive, you keep ownership, and you are paid each time a license closes.
What are the ways to make money from code?
Most advice on this topic assumes the code is a product looking for customers. That works when it is. For the repo that has sat untouched for two years, the picture changes. Here is how the usual routes compare.
| Route | Needs users or revenue? | Effort | Keeps ownership? |
|---|---|---|---|
| Sell the product to customers | Yes, it is the business | High: marketing, support, updates | Yes |
| Sell the codebase outright | Usually; buyers want traction | High: listing, due diligence, handover | No, ownership transfers |
| Templates, themes and plugins | Needs buyers and a polished, reusable product | High: packaging, docs, support | Yes, buyers get a license |
| Freelance or consult on top of it | Needs clients | Ongoing hours | Yes |
| Open source sponsorship | Needs an active user base | Ongoing maintenance and community work | Yes |
| License it as AI training data | No | Low: request access, connect read-only, pick repos | Yes, non-exclusive |
Acquisition marketplaces want revenue and users. Template marketplaces want polished, reusable products. Sponsorship follows popularity. Freelancing pays for your hours, and the code is only a calling card. Each of these is a fine route for the right project. None of them is built for a private repo with a long history and no customers.
Can you get paid for code that has no users or revenue?
Yes, through licensing to AI labs. Labs building coding models need large amounts of real software to train and evaluate them. Public code is already on the internet, so what they lack is private code: the products, internal tools and services that companies and developers kept to themselves.
That changes what counts as valuable. A shelved SaaS, a dead startup, an internal dashboard, a half finished side project or a legacy system that ran a business for a decade all qualify. The code does not need to build, run or have a single user. It needs to be real, and you need to hold the rights to it. If your project is a personal one, the page on how to sell a side project covers that case in detail.
The deal is a license. The lab gets a copy of the code and history under terms that let it train on that copy. Nothing is transferred. Your repository stays where it is, untouched, and you can keep working on it, ship it or license it again. For the full background, read sell code for AI training.
Why do AI labs pay for old code?
Because real code is scarce. Labs can generate synthetic code, but synthetic code does not show how software is actually built and maintained. Real repos do. They show the bug found in production and the fix that followed, the refactor that took three attempts, the test added after an outage, the dependency upgrade that broke half the build.
Demand is rising as labs compete on coding models. Across the licensing program, owners earned $6M in the last 60 days from 11,069 licensed repos. Commercial success makes no difference to a repo’s value for training. A tool that served one team counts the same as a product with paying users.
What makes a repo valuable to AI labs?
Git history comes first. Labs pay for the history as well as the final source, and across the program history makes up about 79% of licensed tokens. A repo with years of real commits is worth far more than the same code squashed into one.
What raises the value:
- Long, real git history. Many commits over months or years, with fixes, refactors and reviews.
- Tests. A test suite shows how the code was meant to behave and how it was checked.
- Production patterns. Error handling, migrations, configuration, deployment scripts and the other parts of software that ran for real.
- Size. More source and more history mean more tokens, and pay is set per token.
- Demand for the language and domain. Older or less common languages can be in short supply.
What lowers it:
- Code that is mostly generated or copied from tutorials.
- History squashed into a handful of commits.
- Third-party code, which is excluded from what is licensed anyway.
Polish, design, documentation and revenue are not on either list. That is the point. The qualities that make a product sellable are different from the qualities that make a repo useful for training.
How much can you make from licensing code?
Pay is set per token. Source code pays $100 per million tokens and git history pays $40 per million. A typical repo earns about $1,000 to $1,500 per license, a light one about $400 to $700 and a deep one about $2,500 to $4,000. A few repos with long production histories and solid tests have earned tens of thousands of dollars.
Because the license is non-exclusive, the same repo can be licensed more than once. How often depends on buyer demand, and nobody can promise a number. Ten typical repos come to about $10,000 to $15,000 if each is licensed once. For the working and the depth table, read how much is my code worth.
You are paid within 15 days each time a license closes and the buyer pays. Rates can change on 30 days’ notice, never retroactively.
Is licensing code a source of passive income?
Close to it, once you are set up. The work happens once: you request access, read and sign the agreement, connect GitHub, GitLab or Bitbucket with read-only access, and pick the repos you want to license. There is no clean-up. Secrets and personal data are stripped from the review copy before any buyer sees it, in both code and history.
After that, your code is graded and taken to buyers in batches. Each license that closes pays you, and you do nothing between licenses. It is fair to call it recurring income with uneven timing, since payments depend on when labs buy.
There is one condition you control: only license code you hold the rights to. Client work and code written for an employer usually belong to someone else. If you are unsure, read who owns the code before you submit anything.
How do I start?
- List the repos you own that are sitting idle: products, side projects, internal tools, old experiments.
- Check the rights for each one. Leave out anything that belongs to a client or a former employer.
- Get a valuation. You get set up, and once you connect Git you see a real per-repo estimate.
- Read the agreement, sign once and select only the repos you want to license.
It costs nothing to join and there is no commitment. If the estimate is not worth it to you, withdraw and keep your code exactly as it was.