You Already Paid to Build That Knowledge. Why Are You Paying Again?

Here is a pattern that plays out in almost every large organisation, so quietly and so routinely that nobody has thought to put a cost on it. Once you see it, it's hard to unsee, because you are almost certainly paying it right now.

A company commissions a piece of software. Call it a €200,000 application, built by a supplier over several months. It ships, it works, everyone moves on. Two years later, the business needs to change it substantially: a new regulation, a new integration, a new market. And this is where the second bill arrives, the one nobody budgeted for.

The archaeology tax

By the time the change is needed, most of the people who built the original system are gone: moved teams, left the supplier, left the industry. The specification, if it exists, is stale; it described the software as imagined, not as it ended up. The architecture diagrams are out of date. The documentation, if anyone wrote it, is the kind nobody trusts six months later. And the reasoning behind the important decisions — why this approach and not that one, what constraint forced this awkward design, what was deliberately ruled out — lived in people's heads, and those heads are elsewhere now.

So the new supplier, or the new internal team, does the only thing they can. They spend weeks doing archaeology: reading code, guessing at intent, reconstructing the decisions, rediscovering the constraints, slowly rebuilding an understanding of a system the organisation already paid, once, to have fully understood. That rediscovery is billed by the hour, at European supplier rates, before a single line of the change is written. It is pure waste, and it is enormous, and it appears on no one's dashboard as what it is: paying twice for the same knowledge.

The knowledge was the asset, and it walked out the door

The deep problem here is a confusion about what the organisation was buying. Everyone assumes they bought the software: the running code. But the code was only ever half of it. The other half, the more valuable half, was the knowledge: why this was built, what was agreed, which requirements it satisfies, which constraints shaped it, which architecture was chosen and for what reason, what was delivered against what was requested.

That knowledge is what you need in order to change, govern, or rebuild the software later. And in the standard supplier model, it is precisely the part you don't keep. The supplier accumulates it over the course of the project — they have to, to do the work — and when the engagement ends, it leaves with them. You are left with the code, which is the regenerable part, and stripped of the knowledge, which is the irreplaceable part. You paid to create an asset and then let the most valuable component of it walk out of the building. The next change forces you to buy it back, from scratch, at full price.

Own the knowledge, not just the output

The fix is not to write more documentation. Documentation is what everyone already fails at, because it's a separate artifact that rots the moment the work moves on. The fix is structural: to keep the knowledge connected to the work as it happens, as a living record the organisation owns rather than a document the supplier produces at the end. Why we're building this. What was approved. Which requirements apply. Which constraints bind it. Which architecture was chosen, and why. What was built. What changed since. Who approved it. Whether it still satisfies what was asked.

When that record belongs to the company and stays current, the archaeology tax disappears. The next change doesn't start with weeks of rediscovery, because the understanding was never lost. And the power relationship shifts in a way that matters at board level: the organisation, not the supplier, becomes the keeper of its own systems. You can still have a supplier build the next change. But now they build from your knowledge, cheaply, instead of reconstructing it, expensively. You can move work between suppliers, bring it in-house, or hand a component to an AI agent, because the thing that used to lock you to one vendor — their exclusive understanding of your system — is now yours.

The number is bigger than it looks

For a company spending hundreds of thousands or millions a year on software suppliers, the archaeology tax is not a rounding error. It's a recurring, invisible surcharge on every significant change, paid on every system, forever, for as long as the knowledge keeps leaving. And unlike most costs, it compounds: the more systems you've built and the older they get, the more archaeology every change requires.

You already paid to build that knowledge. The only question is whether you keep it, or keep buying it back one change at a time.