Skip to content
Operating model

Inheriting a system nobody understands any more

·4 min read

The person who wrote it has left. The documentation describes a version that no longer exists. Every change carries a risk nobody can size, so changes stop, and the system calcifies into something the business plans around rather than uses.

This is more common than greenfield work, and it is much less written about, because nobody wants to present a case study about a system they were afraid of.

Start by reading, not rewriting

The instinct is to propose a rewrite. It is almost always wrong: a rewrite trades a system you do not understand for a system that does not exist yet, and pays for the privilege.

The first step is a map — what the system is, what depends on what, and where the gaps are. Pointed at a system nobody fully understands, the factory produces that in about ten minutes, without overwriting a single existing document. Your prior work is input, not something we replace.

Then change one thing, with the checks on

Once there is a map, the question becomes tractable: pick one piece of work, take it through the full six checks, and see what the system does. You learn more from one change that clears every gate than from three weeks of reading code.

A rewrite trades a system you do not understand for a system that does not exist yet, and pays for the privilege.

That is also why our first engagement is deliberately small. One piece of work and read access to one system tells both sides more than any proposal document.

Also worth reading

Start with one piece of work.

Give us one piece of work and read access to one system. We map it and come back with what we found, what we would build and what it would take — before any commitment. You decide using our output, not our pitch.

Talk to us