Rescue or rewrite: how we decide what a stalled codebase deserves

By the time someone calls us about a stalled project, they have usually been staring at it for months. The developer has gone quiet, the demo still sort of works, and every conversation about finishing it ends with "it depends." This article is the long version of it depends: the same four questions we ask when we take over a codebase, written down so you can run them without us.

The instinct to burn it down

Nearly every engineer who inherits someone else's work has the same first reaction: start over. Sometimes that instinct is right. It is also the most expensive sentence in software, because a rewrite quietly restarts the clock on everything that already works, and the clock is usually the thing your business can least afford. Before anyone commits to months of rebuilding, the existing system deserves a fair trial.

Question one: does it run?

Not "does it compile," and not "does the demo look fine." Can a new engineer, using only what is in the repository, install the system from scratch and reach the main workflows? Try it literally. If the answer is yes, a surprising amount of value is intact, whatever the code looks like inside. If the system only runs on the original developer's machine, the code may be fine, but the knowledge around it is gone, and recovering knowledge is often the larger job.

Question two: can anyone explain it?

We read before we judge. Structure matters less than intent: after an afternoon in the code, can a competent engineer say what each major part is for? Messy but explainable is workable. Clean-looking but unexplainable is riskier than it looks.

When we took over a fleet-compliance platform, there was no reliable documentation. We recovered the requirements from old emails, from the client's memory, and from the behavior of the product itself. That work was slow. It was still far cheaper than rebuilding months of working business logic from nothing.

Question three: what happens when you change something?

Pick a small, safe change and carry it all the way to a deployed environment. This one exercise X-rays the delivery process: whether tests exist and pass, whether deployment is scripted or folklore, whether anyone can tell that the change worked. A one-line change that takes a week is telling you the process is broken, and process is cheaper to fix than product. We treat that as good news.

Question four: how far is it from what was promised?

Write down what was promised. Mark what exists, what half-exists, and what was never started. Rescue against rewrite is, at heart, a percentage question. A system that is 70% delivered, with the hard problems already solved, is almost always worth finishing. You cannot get the honest percentage without the first three questions, which is why this one comes last.

When a rewrite wins

A rewrite earns its cost in a few specific situations. The foundation fights the actual requirement: the platform cannot do what the business needs, no matter how much is stacked on top. Security is broken at the design level, so patching means repainting a cracked wall. Or the missing part of the scope is the majority, and it includes all of the genuinely hard problems, so "finishing" would mean building the product anyway while also carrying the old code. There is no shame in any of these. The expensive mistake is paying rescue prices for rewrite work, a month at a time, for a year.

When a rescue wins

Rescue wins more often than wounded pride suggests. If the system runs, if half or more of the promised scope genuinely exists, and if someone can explain it (or the requirements can be recovered), finishing is usually faster, cheaper, and kinder to the people already using the product. Every month spent rewriting is a month users get no fixes and the business gets no progress, paid at full price. Working software, even ugly working software, is evidence: the problems it solves are real and already solved.

Either way, the first week looks the same

Whichever way the decision goes, we start identically. First: read everything. Code, old emails, tickets, the lot. Second: write the requirements down and get them agreed, because the stalled project almost never had that document, and its absence is usually how it stalled. Third: put automated tests around the riskiest paths before changing them. Fourth: plan the rest in milestones you can see and touch.

None of this is secret. It is also exactly what our paid discovery produces, and the documents are yours to keep, regardless of who ends up building.

Software project rescue and takeover →

The EvitaAmenda rescue, as a case study →

If your developer disappeared: what to do this week →