A codebase on its own shows what a program does. Everything around it shows why: the documents that explain the design, the tests that prove what the team expected, the tickets that record each bug and request, and the design files that show what users were meant to see. Together they turn a folder of files into the full record of how a real product was built and maintained. That is why they usually make old code worth more, and why exporting them before tools are cancelled is one of the most useful things an owner can do.
What does each artifact add?
Each type of material answers a different question about the code.
| Artifact | What it shows | Common sources |
|---|---|---|
| Technical documentation | How the system is meant to work and why it was designed that way | README files, wikis, Confluence, Notion, architecture diagrams |
| Test suite | What the team expected the code to do, case by case | Unit, integration and end-to-end test folders |
| Ticket export | The problems, requests and decisions that drove each change | GitHub Issues, Jira, Linear |
| Design files | The intended interface and user flows | Figma, Sketch, exported images |
| Runbooks and SOPs | How the software was deployed, monitored and fixed | Wikis, docs folders, ops notes |
| Git history | When and how every change happened | The repository itself |
Suppose two codebases are the same size and written in the same language. One is just the latest files. The other has eight years of commits, 3,000 tickets linked to them, a test folder and an architecture document. The second tells a much fuller story about how real software changes over time, which is exactly what makes it more useful for research. Our guide on how codebase value is measured explains how docs and tests sit alongside size, originality, history and rights.
Why do these materials matter for AI training and R&D?
Odys AI Labs, the research and development arm of Odys, uses the code it buys for AI training and R&D, so models learn to read, write and fix real software; we may also work on it with research partners. Code alone teaches what a solution looks like. A ticket that describes a bug, the commit that fixed it and the test that now covers it teach the whole loop: the problem, the change and the proof. Design files and docs add the intent behind the code. That connected record is hard to find in public tutorials and sample projects, which tend to show finished code with none of the work around it.
How we value a codebase is explained on the call. In general, completeness helps: value typically depends on size, originality, languages, quality, history, docs and tests.
How do you export tickets from GitHub Issues, Jira and Linear?
Export before you cancel any subscription. Issue trackers are often among the first tools to go in a shutdown.
- GitHub Issues and pull requests live with the repository on GitHub. If you plan to keep the repository, they stay with it, and a repository transfer moves issues and pull requests along with the code. If you are leaving GitHub, export them through GitHub’s API or official command-line tool, or ask a developer to do it, so titles, bodies, labels and comments are saved as structured files.
- Jira can export issues from a search to CSV, and admins can create a full backup of the site. Include issue keys, so tickets can be matched to commit messages that mention them.
- Linear offers a workspace export from its settings, which produces structured files of issues and projects.
Keep the links between tickets and code. Commit messages that say “fixes PROJ-412” are only useful if the ticket PROJ-412 is in the export too.
How do you save docs, tests and design files?
Docs. Wikis in Confluence or Notion can usually be exported as HTML, Markdown or PDF. Copy any docs folder from the repository as it is. Include architecture diagrams, API specifications, onboarding guides and decision records.
Tests. Tests normally live inside the repository, so a full backup keeps them. Note roughly how much of the test suite passed when the product was last maintained. Do not spend days fixing old tests. If the suite needs special setup, such as a test database or mock services, describe it in a few lines so a reader knows how it was meant to run.
Design files. In Figma, save local copies of the main files, or export key frames as images and PDFs. Include the design system or component library if the product had one.
Runbooks and SOPs. Deployment notes, incident playbooks and standard procedures show how the software was operated. Gather them into one folder.
Then write a one-page overview: what the product did, who used it, when it ran, the main languages and frameworks, and what material exists. Add a short folder map that says where the docs, tests, ticket exports and designs sit, and which version of the product each one describes. If the docs describe an older version than the final code, say so plainly; an honest note is more useful than a polished but misleading one. Our step-by-step preparation guide shows where this fits in the wider process.
What should you leave out?
Some material around the code should never travel with it. The Blue Ocean Code never takes databases, user records, customer data or chat logs.
- Chat logs. Slack, Teams and Discord history is full of personal data and private conversations. Summarize key technical decisions in your own words instead.
- Customer data in tickets. Support tickets often include names, emails, screenshots and pasted logs. Remove or redact them.
- Database dumps and seed files with real records. Keep only synthetic sample data. Our guide to personal data in old code lists where real records usually hide.
- Secrets in docs and wikis. Passwords and API keys often sit in runbooks and wiki pages, not just in code. GitGuardian’s 2026 report found that about 28% of secret leak incidents originate from collaboration and productivity tools. Search exports for keys and rotate anything you find.
Under GDPR, personal data means any information relating to an identified or identifiable person, so an email address or user ID in a ticket counts. This is general information, not legal advice; for data protection questions specific to your company, ask a qualified lawyer.
With us, secrets, keys and personal data are removed before transfer, and we help. No code or material changes hands before a signed written agreement, and we never ask anyone to install or run anything.
What to do next
- List every tool that holds docs, tickets or designs, and note which subscriptions end soonest.
- Export tickets, wikis and design files this week, keeping ticket keys intact.
- Write a one-page overview, then send us a few details for a free code valuation; the form asks for no code.
Frequently asked questions
Do I need documentation to sell old code?
No. Plenty of codebases have little formal documentation, and they can still qualify if the product is complete and original. Docs, tests and tickets typically add value because they explain the code, but their absence is not a reason to stop. A one-page overview you write today, describing what the product did and how it was built, already helps a buyer understand it.
Should I include Slack or Teams messages with the code?
No. Chat logs are full of personal data, private conversations and often pasted passwords, and The Blue Ocean Code never takes chat logs. If an important technical decision only lives in chat, summarize it in your own words in a short document instead. That keeps the useful context and leaves the conversations, and the people in them, out of the sale.
What if our tickets mention customers by name?
That is common, and it needs cleaning before anything leaves your hands. Remove customer names, email addresses, account IDs, attachments with customer data and any pasted logs. If the volume is large, export only the fields that matter, such as titles, descriptions, labels and status, and redact the rest. A fair buyer will help you plan this before transfer.
Are failing or outdated tests still worth including?
Usually yes. A test suite shows what the team expected the software to do, even if some tests broke as dependencies aged. Include it as it is and mention roughly how much of it passed when the product was last maintained. Do not spend days fixing old tests; the record of what was tested is what carries the value.
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 →