Most companies have one. Critical to the business, running on a frontend that aged badly, and documented nowhere. Replacing it gets discussed every year and never scoped, because nobody can say what it would take.
I ran an experiment on one of them with Claude, to find out whether that question was actually hard or just unasked.
The constraint that shaped everything
The rule I set was that the backend stays untouched. That matters more than it sounds. Rebuilding both halves is a different order of investment and a different conversation. Replacing only the part users touch is a frontend project — as long as you know exactly what the backend expects.
Nobody knew, so that became the first job.
Reading a system that can’t tell you anything
I didn’t read the source code. Three techniques did the work instead:
Runtime inspection. The old app builds a registry of its data connections when it loads. Reading that live, in the browser, gave up the endpoints and how each one’s response is shaped.
Static scanning. The application ships as one large bundle. Scanning it for URL literals and validation rules filled in everything the runtime registry missed.
Request interception. The interesting one. I had Claude patch the app’s own network layer so that outgoing requests were captured and then blocked before reaching the server. Clicking Save in the old UI revealed exactly what it would have sent, without writing anything.
That last technique is what made the write side knowable. You can’t learn a save contract by reading — you have to watch one happen.
The findings were more interesting than I expected, and a few would have caused real damage if discovered mid-build.
None of this is in any document, because there are no documents. It lives in the old frontend, and it would have left with it.
Why the surface first
The argument I ended up making is about sequencing, not technology – I wanted to explore some quick-wins.
Users feel the interface, not the engine. Replacing it delivers something visible in a short time rather than after a multi-year programme. The frontend is also where the technical debt is most acute and hardest to hire for — and it can be retired on its own.
And if the business process hasn’t changed, the backend is doing its job. Its stack was current. Security patching there is routine upkeep, not a rebuild driver. That work can follow later, on its own business case, and it gets easier once one translation layer sits between the interface and the engine.
The part I want to be honest about
What came out of the day was a working prototype over real data and a full written specification — contract, architecture, task breakdown.
That specification was recovered by observation, not handed over by the people who built the system. Parts of it will be slightly wrong. Something will be missing. Before anyone builds on it, someone with domain knowledge has to read it end to end and correct the details.
But that is reading and editing, not writing from scratch. Which is the difference between a few days and a few months.
What it changes afterwards
The lasting value isn’t the prototype. It’s that a change now starts in the documentation rather than the code. You describe what should change and why, update the spec, and let Claude Code implement against it. Reviewing replaces hand-writing. Onboarding becomes reading rather than reverse-engineering. Nobody reconstructs context from a trail of tickets.
The point isn’t just this rebuild. It’s that the one after it should be far cheaper.
If I got this far in a day, it’s worth asking what someone who actually knows what they’re doing could do with the same approach 🙂
Feel free to download this research as a playbook style book:
Leave a Reply