Do not delete code because you want to be rid of the risk. Delete the data. Most of the danger in an old product sits in databases, user records, logs and live credentials, not in the application code. Once those are gone, the code is usually harmless, and if it is a complete product your team wrote, it can be sold. Delete the code itself only when you have no right to keep it, or when it has no value to anyone.
Deleting is final, and it pays nothing
Deleting means removing the repositories, the backups and your local copies. It is final and it costs only time. It also pays nothing, and it removes the record of years of work.
Selling hands the code to a buyer for cash. Here the buyer is Odys AI Labs, the research and development arm of Odys, which uses it for AI training and R&D; we may also work on it with research partners, and the written agreement sets out exactly what rights transfer. We never take databases, user records, customer data or chat logs, so the part of the product most owners worry about stays with you, to keep or delete as you decide.
Delete or sell: what each one really removes
| Consideration | Delete it | Sell it |
|---|---|---|
| Money | None | One agreed cash price, paid on transfer |
| Reversible | Never | Not after signing, but no obligation before |
| Removes every copy | No: clones, forks and backups survive | Not the goal; the buyer holds the code under a written agreement |
| Risk from secrets | Gone with your copy, still live in any other copy until rotated | Secrets, keys and personal data removed before transfer, with help |
| Risk from customer data | Only if you delete the databases too | Databases are never taken; they stay with you to delete under your own policies |
| Proof of ownership later | Lost with the code | Settled in a signed agreement |
| Time needed | An afternoon | A form, a call, a review and a written agreement |
| Leaves your work on record | No | Yes, used for research, never under your name |
Why deleting is less complete than it looks
People delete code expecting a clean slate, and rarely get one. GitHub’s documentation says that if you delete a file that contains sensitive data, “the data will still be available in the repository’s Git history” (GitHub Docs). Deleting the whole repository removes your copy, but GitHub also notes that you “cannot remove sensitive data from other users’ clones of your repository,” and that commits in forks stay accessible there.
Think about where a product’s code has lived over the years: every developer’s laptop, the CI server, deployment images, a contractor’s machine, an old backup drive. Deleting the main repository does not reach any of them.
So deletion does not deliver what most people want from it. If the worry is a leaked key, GitGuardian found that 64% of valid secrets leaked in 2022 were still not revoked in 2026. The fix is to rotate or revoke the key, which works whether or not the code still exists. GitHub’s own advice is that “as a first step you need to revoke and/or rotate that secret.” Our guide to removing API keys and passwords from old code shows the order of work.
Delete the data, not necessarily the code
Under the EU GDPR, personal data is “any information relating to an identified or identifiable natural person,” and its data minimization principle says personal data must be “limited to what is necessary” (Regulation (EU) 2016/679). Once a product has ended, that usually means the production database, user exports, support logs and analytics. Those are the things to delete or anonymize, on your own schedule and with advice.
Application code is different. It may contain some personal data by accident: a seed file with real customer emails, a fixture copied from production, a log file committed by mistake. That needs finding and removing, which our guide to personal data in old code covers file type by file type. The rest of the code is logic, not people. This is general information, not legal advice; ask a qualified lawyer about your obligations.
When deleting wins
Deleting is the right choice in a handful of cases:
- You have no right to keep it. Client work under a contract that requires you to return or destroy it should be dealt with as the contract says. We pass on client work the seller has no rights to.
- It is mostly not yours. A repository of copied libraries, generated code, a tutorial project or a template has little value to anyone and is not something we buy.
- It is fragments. Snippets and experiments that never formed a working product are not a complete product.
- You are legally required to. A court order, a settlement or a regulator can require deletion. Follow it.
When selling wins
Selling wins whenever the code is a complete product written by your own team, it makes no money today, and you own the rights or can sign for the company that does. That covers most shut-down apps, SaaS products and old side businesses.
In those cases, deleting destroys something with value in exchange for a sense of closure that a sale also gives you. After a sale, the code is gone from your list of responsibilities, your name is never used, and the deal is confidential.
An illustration: the agency that nearly wiped a drive
Suppose a small agency built its own scheduling product, ran it for three years and closed it. Clearing out an old server, a partner proposes deleting everything: the repository, the backups and the production database, to be safe.
Look at what is actually on that server. The production database holds names, emails and booking histories of former users: genuine personal data with no reason to keep it once any legal retention period has passed. The repository holds 50,000 lines the agency’s own developers wrote, three years of history, a working test suite and some fixtures with copied customer emails.
The sensible split is clear. The database goes, after checking any retention obligations. The fixtures are cleaned. The secrets in old config files are rotated. The code itself, a complete original product, is archived and offered for sale. Deleting all of it would have removed the asset and kept none of the safety, since copies of the code were still on two former developers’ laptops anyway.
Can you do both?
Yes, and for most owners this is the best answer. Delete the data and sell the code. In practice:
- Rotate every credential the product ever used.
- Delete or anonymize the production databases, user exports and logs you no longer need.
- Archive the repositories so nothing changes while you decide.
- Ask for an offer on the code. If it does not qualify or you decline, delete it then.
The order matters. Deleting the code first closes the sale option for good, while deleting the data first loses nothing.
Which to choose
- If you have no rights to the code, or it is mostly someone else’s, delete it as your contracts require.
- If it is a complete product your team wrote, delete the data, keep the code, and get an offer.
- If you are unsure, do nothing irreversible this week. Archive, rotate keys, and decide next month.
What to do next
- Find every copy you control: repositories, backups, laptops, CI caches.
- Rotate keys and delete customer data you no longer need.
- Before you delete anything you cannot get back, ask for a free code valuation; it takes a few details and no code.
Frequently asked questions
If I delete my GitHub repository, is the code gone?
Your copy on GitHub is gone, but not necessarily every copy. Anyone who cloned the repository keeps their clone, and forks can keep commits accessible. Laptops, build servers, backups and old contractor machines may hold copies too. Deletion removes the copy you control, so it is not a reliable way to make sure code no longer exists anywhere.
Do I have to delete old code for GDPR?
GDPR is about personal data, not code as such. Its data minimization principle says to keep only the personal data you need. That usually points at databases, user records, logs and fixtures with real customer details, not at the application code. This is general information, not legal advice, so ask a data protection lawyer about your specific case.
I deleted the repository but still have a zip. Can I sell that?
Often, yes. A zip of the code without its git history is still the code of a real product, and it can still qualify if it is complete and your team wrote it. History adds value, so look for any surviving clone first: an old laptop, a backup drive, a former developer's machine or a mirror on another host.
Should I delete the code after I sell it?
That depends on what your written agreement says about copies, so read that clause before signing. Whatever the agreement says, you should always delete the personal data and secrets you no longer need. After a sale the rights belong to the buyer, so using the code yourself is no longer an option either way.
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 →