How we rescue a codebase nobody can compile

The call is always some version of the same story. The software runs the business. The person who built it left, or the agency folded, or the founder and the dev stopped talking. Nobody has deployed in months because nobody knows how. Sometimes nobody can even build it.

Legacy rescue is on our services list, and this is what it looks like in practice, with the LIÉNA rescue as the running example.

First: make it build

Nothing else matters until the code compiles and runs somewhere that is not production. This step alone can take days. Dependencies have rotted or disappeared from registries, the build needs an environment variable that exists only on the old developer's laptop, and the README was last true two years ago. We write down every step as we fight through it, because that document is the first deliverable: from now on, anyone can build this thing.

The floor of this category is lower than most founders imagine. On LIÉNA there was no source code to fight with at all. What existed was a running .NET Core 3.1 application on a VPS, years past the runtime's end of life, and no way to change anything. "Make it build" meant decompiling the production binaries and getting the result to compile on .NET 10 before any real work could start.

Along the way you collect the keys. Domain registrar, hosting, database, email provider, Stripe. Half of rescue work is an inventory problem, and it is amazing how often the business does not own its own accounts.

Second: read it before judging it

Every developer's instinct on inherited code is "this is terrible, rewrite it". The instinct is usually wrong. The ugly code has years of bug fixes baked in that a rewrite would have to rediscover the hard way, one angry customer at a time. LIÉNA's backend carried rules like commissioned private-collection pieces that render differently in listings and related products, the kind of thing a fresh rewrite quietly drops because nobody remembers it is there.

So we read. What are the load-bearing parts? Where does the money flow? Which ugly corners are actually stable, and which are the source of the weekly fire? The output is a short map of the system with a verdict per area: leave alone, refactor, or replace. On most rescues the "replace" list is much shorter than the founder feared.

Third: put a floor under it

Before changing anything of substance, three things go in: version control if it is somehow missing, a deploy that one command can run, and error tracking. Then tests, but only around the parts that make money. A rescued codebase does not need 80% coverage; it needs the checkout flow to be provably hard to break.

On LIÉNA the floor was snapshot tests. Decompiled Blazor components are not editable, because the markup is gone, replaced by machine-generated render calls. We built a Roslyn tool that converted all 105 components back to authorable code, and every conversion is backed by a snapshot test proving the rewritten component renders the same DOM as the recovered one. "It still behaves the same" became a test result instead of an opinion.

This is the point where the panic ends. The system builds, deploys, and reports its own errors. Everything after this is normal software work, done at a normal pace.

Then: earn the rewrite, piece by piece

Some parts do deserve replacement, and now they can be replaced safely: one bounded piece at a time, behind the tests, while the rest keeps running. On LIÉNA the storefront got rebuilt in front of the recovered backend only after that backend was editable and pinned by tests. The shop kept selling the whole time.

The pattern that fails is the other one: a ground-up rewrite running alongside the old system for a year while the business pays for both and gets neither.

One honest exception. If the system is small, has no accumulated domain rules, and you can read all of it in a day, a rewrite really is faster. Rescue economics favor systems that have been quietly absorbing business rules for years.

If you're sitting on one of these

Two things before you hire anyone, including us. Get the accounts into the company's name this week; access is the thing that becomes a crisis fastest. And do not let anyone start with a rewrite pitch. Whoever you bring in should be able to tell you what your system does before proposing to replace it.

If the build is broken and the business is on it, that first conversation is what we are for.