Inherited codebases

What does this system actually do?

After an acquisition, an agency handover or an investor’s due diligence, someone asks the question that no document can answer: what does this system actually do? The code knows. SpecTrail writes it down.

28 October 2026 · 5 minute read

Three moments when the question comes up

An acquisition. The buyer owns a product and a repository, and the people who understood them are leaving, or never wrote anything down.
An agency handover. The contract ends and the documentation is a wiki that stopped in the third month, plus a long list of closed tickets.
An investor’s due diligence. Before a round or a sale, someone technical has to say what the product does and how much of it is tested.

The same question also appears more quietly: when the engineer who built the payment flow resigns, or a new CTO arrives and asks for a map.

Why the usual answers are slow

Reading the code is accurate but takes weeks, and it answers in the language of the code, not the product. Asking the people works only while they are still around. Old tickets describe plans at the time, not what shipped. Using the product and clicking through it finds the main path and misses the edge cases, which is where the surprises are.

A specification drafted from the code

SpecTrail reads the repository and writes what the system does as user stories with acceptance criteria, grouped by epic and feature, using the vocabulary of the product. Every statement carries small marks that show the evidence behind it:

Built and covered by tests

Built, with tests for only part of it

Built, with no tests

The result is a first draft that people review, correct and edit. Statements that the code does not support are easy to spot, and the draft is far faster to correct than a blank page is to fill.

What the new owner learns

What the product does, feature by feature, in words that a product manager, an investor or a support agent can read.
How it behaves in the edge cases, because the acceptance criteria record them.
What is tested and what is not, from the marks beside each statement.
Where to look in the code for any statement, so the engineers who join can go straight to it.

After the handover, stay in control

The specification does not end at the first reading. Each merged pull request is compared with it, and a change that alters what the product does is flagged with the pull request and an assessment. The new owner then sees every behavioural change from the first day, and the record of what the system did before the change is already in the document.

For investors and acquirers

A readable specification with evidence marks gives a technical reviewer something to ask about directly: which features are core, which are lightly tested, and what the code does where the documentation is silent. It turns a question that usually takes weeks into a conversation about a document.