Rescuing stalled projects

A stalled project is rarely stalled for the reason it is described. "The developer left" and "it is too slow" and "we cannot add anything without breaking something" are symptoms; the cause is usually that nobody can predict what a change will do, so every change becomes a negotiation.

The first step is an audit that produces facts rather than opinions: what runs in production today, what the deployment actually consists of, which parts have tests and which have none, where the data really lives, and which behaviour customers depend on that nobody wrote down. It is deliberately cheap and time-boxed, and it ends with a list of risks ordered by what they would cost if they happened.

Then behaviour is frozen. Before refactoring anything, the current behaviour is pinned down with tests — including the parts that are wrong, because customers have already built habits around them. Only then does the work proceed area by area, each one shippable on its own, so the project keeps delivering while it is being repaired.

A full rewrite is the last option, not the first. It is the right call when the platform can no longer be deployed, when the language or framework is out of support with no upgrade path, or when the cost of keeping it clearly exceeds the cost of replacing it. Rewrites started for any other reason tend to ship late and arrive missing the details that made the old system work.