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.

A stalled project is rarely a purely technical problem, and treating it as one is how the second attempt fails the same way as the first. Usually part of the knowledge left with someone, part of the scope was never written down, and the remaining team is reluctant to touch anything because nobody can predict what a change will break. Restoring the ability to deploy safely comes before any feature work, because until that exists every estimate is a guess.