Preparing a codebase for sale comes down to eight jobs: find every repository, confirm who owns it, separate your team’s code from third-party code, remove secrets from the files and the history, remove personal data, keep and export the history and supporting material, write a one-page overview, and hold on to everything until a written agreement is signed. You do not need to refactor anything. The code is worth most as it was actually built, with secrets and personal data taken out.
This guide is written for founders, developers and also non-technical owners such as a CEO, a liquidator or an heir. Where a step needs a developer, it says so.
Why prepare before you talk to a buyer?
Because almost everything that slows a sale is known in advance. Unclear ownership, keys buried in old commits, customer records in a fixtures folder and repositories scattered across personal accounts all take time to sort out. Doing it first means the first call is about the product rather than about gaps, and your answers in the review are ones you can confirm in writing later.
Preparing also protects you. Rotating keys and removing personal data are things you should do with any old codebase, whether you sell it, archive it or delete it. Our guide on how selling your old code works shows where each of these steps fits in the overall process.
Step 1: How do you inventory every repository?
Make a simple table, one row per repository. Columns: name, where it lives (GitHub, GitLab, Bitbucket, a server, a laptop), who has admin access, what it contains (frontend, backend, mobile app, infrastructure scripts) and its last commit date.
Check the obvious places and the forgotten ones: company organizations, personal accounts of founders and early developers, old CI services, backup drives. Then size each repository. cloc is a free tool that counts lines of code by language, and tokei is a fast alternative that supports over 150 languages. Record the result per language. Our guide on how to count lines of code explains what to exclude so the number reflects your own work.
Note anything unusual as you go: a repository that was forked from a public template, a branch that holds an experimental rewrite, a mobile app kept in a separate account, infrastructure code in a different tool. None of these is a problem in itself, but each one belongs in the inventory so nothing is a surprise later.
Lock down access while you are here. Make sure at least one person you trust has admin rights to every account, and remove access for people who have left.
Step 2: How do you confirm who owns the code?
A buyer can only buy what you can sign away, so ownership comes before cleaning. Write down who wrote each major part: founders, employees, contractors, an agency.
Employee code usually belongs to the employer. In the US, code an employee writes as part of the job is a “work made for hire”, and the company, not the coder, is the author and owner. Contractor code is different: it is usually not work for hire by default, so you generally need a signed IP assignment. In the UK, the employer owns code staff write in the course of their job unless agreed otherwise, and EU rules give the employer the commercial rights to code written on the job unless the contract says otherwise.
Gather the documents: employment contracts, contractor agreements, any assignments, and for a company the details of who can sign for it. If the company is dissolved, in liquidation or part of an estate, find out who holds authority now. Our guide on who owns the code covers the common gaps and how they are usually fixed. This is general information, not legal advice; a qualified lawyer should confirm ownership in your specific case.
Step 3: How do you separate your code from third-party code?
Expect more third-party code than you remember. In Black Duck’s 2026 audit, the average codebase pulled in about 1,180 open source components, most of them dependencies of dependencies. Using them is normal and does not stop a sale: what is sold is the original code your team wrote, and third-party code stays under its own license.
Your job is to know roughly where the line is. Look for:
- Vendored dependencies: libraries copied into folders such as vendor/, third_party/, lib/ or node_modules/ that were committed.
- Generated code: API clients, ORM models, protobuf output, build artifacts.
- Minified and bundled files: dist/, build/, *.min.js.
- Copied snippets and templates: a starter kit or admin theme you built on top of.
Do not remove license notices or files; keep them exactly as they are. Just note which folders are third-party so your size count and your description are honest. Our guide on open source inside your codebase explains permissive and copyleft licenses in plain English.
Step 4: How do you remove secrets, including from git history?
This is the step most likely to need a developer. A secret is anything that grants access: passwords, API keys, tokens, private keys, database connection strings. Old private repositories are full of them. GitGuardian found that internal repositories are about six times more likely than public ones to hold hardcoded secrets.
Work in this order:
- Rotate first. GitHub’s guidance is that as a first step you need to revoke and/or rotate the secret. A dead key cannot be abused even if a copy survives somewhere.
- Search the current files. Check every environment file (.env, .env.production), config files, docker-compose files, CI configuration, deployment scripts and mobile app config.
- Search the history. Deleting a file in a new commit does not remove it from history. Scrub it with git-filter-repo, which Git’s own documentation recommends over the old filter-branch.
- Remember copies. Old clones and forks can still hold the secret after a rewrite, which is another reason rotation comes first.
Our guide on removing API keys and passwords from old code explains each step and the tools in more detail. If you are not technical, this is the step to hand to a former developer you trust, and we help with it as part of the sale.
Step 5: How do you remove personal data?
Under GDPR, personal data is any information relating to an identified or identifiable person, so an email address or a user ID counts. Swapping names for IDs does not take data out of scope; only truly anonymous data is outside it.
Look in the places personal data hides in code:
- seed files and fixtures with real customer records
- SQL dumps and backups committed by mistake
- log files and crash reports
- test accounts using real emails or phone numbers
- CSV exports in a data/ or scripts/ folder
- screenshots in docs that show real user screens
Remove them, and replace with obviously fake data only if tests need it. Databases, user records, customer data and chat logs are never part of a sale to us, so leave production data out entirely. Our guide on personal data in old code has a fuller checklist. This is not legal advice; if you are unsure about your data protection duties, ask a qualified lawyer.
Step 6: How do you preserve history, tickets and docs?
Git history shows how and why the software changed, so keep it. Do not squash it into one commit and do not export the code as a plain zip, which drops the history. Make sure branches and pull requests still exist, and if the code lives on a platform you are about to leave, keep a full clone or a git bundle. Note that pull requests and review comments live on the hosting platform, not inside git, so a clone or bundle does not carry them: keep the hosted repository archived rather than deleted, or export them first.
Then gather what sits around the code:
| Material | Where it usually lives | How to keep it |
|---|---|---|
| Tickets and issues | Jira, Linear, GitHub Issues | Use the tool’s export (CSV or JSON) |
| Technical documentation | README, docs/ folder, wiki, Notion, Confluence | Export to Markdown or PDF |
| Test suite | tests/, spec/, tests/ | Keep it in the repository |
| Design files | Figma, Sketch | Export or note the file links |
| Runbooks and SOPs | Wiki, shared drive | Export to Markdown or PDF |
Before exporting tickets, strip out customer names and support conversations. Chat logs are not part of a sale. Our guide on why docs, tests, tickets and designs add value explains what each one shows.
Step 7: What goes in a one-page overview?
One page, plain language, written so a non-technical reader understands it:
- what the product did and who used it
- when it was built and when it stopped, and why
- the stack: languages, frameworks, databases, platforms
- size per language from cloc or tokei, with third-party folders excluded
- what is included: repositories, history, docs, tests, tickets, designs
- who owns it and who will sign
- known gaps, honestly stated
Keep the tone factual. Describe the product as it was, not as a pitch: who used it, what problem it solved, what went well and why it stopped. Buyers of code for research care about what the software did and how it was built, not about marketing claims, so a plain description reads as more credible than a polished one.
This page answers most of the questions on the first call, and it doubles as the description in your written agreement. Illustration: suppose a booking platform with three years of commits, a Django backend and a React front end, one contractor-built mobile app and a Jira export. The overview would state all of that, including that the mobile app needs a signed assignment from the contractor before it can be included.
Step 8: What should you not do while preparing?
- Do not delete repositories or accounts. Archive them instead; on GitHub, archiving makes a repository read-only and can be undone.
- Do not refactor or reformat. Real history is part of the value.
- Do not open-source it while deciding. Once public, it cannot be sold exclusively.
- Do not send code to anyone before a signed agreement. A fair buyer does not need it.
- Do not run a stranger’s script on a machine that holds your code or credentials. If any buyer asks, read our list of red flags when someone offers to buy your code.
What to do next
- Build the repository inventory today; it takes an hour and shows you what you have.
- Rotate every key you can find, then plan the history scrub.
- When the one-page overview is done, send us a few details for a free code valuation.
Frequently asked questions
Should I clean up or refactor old code before selling it?
No. Do not rewrite, reformat or modernize it. The value of real-world code includes how it was actually written and how it changed over time, and a large cleanup commit can blur that history. Remove secrets and personal data, which is required, and leave the code itself as it was. Fixing old bugs or upgrading frameworks just before a sale rarely helps.
Do I need to send the code to anyone while preparing it?
No. Everything in this guide happens on your own machine or in your own accounts, with free tools you choose. A fair buyer assesses fit from what you tell them and receives code only after a written agreement is signed. Never run a script a stranger sends you on a machine that holds your code or credentials.
What if I cannot find all the repositories?
Start with what you can find and list the gaps honestly. Check old GitHub, GitLab and Bitbucket organizations, personal accounts of former team members, CI services, backup drives and old laptops. A partial codebase can still be a fit if what remains is a coherent product. Missing pieces only become a problem if they are hidden rather than disclosed.
Can I keep a copy of the code after selling it?
That depends on the agreement. A sale usually transfers the rights to the code you wrote, so keeping a working copy for your own use would normally need to be agreed in writing. Raise it before signing. If you want to keep something, such as a portfolio description or screenshots, say so on the call.
Does open source in my codebase stop a sale?
No. Almost every commercial codebase uses open-source libraries, and that is normal. What you sell is the code your team wrote. Third-party code stays under its own license, which travels with it. What matters is knowing roughly which parts are yours and which are libraries, so the agreement can describe the sale accurately.
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 →