A project rarely fails on a particular day. It slows, the explanations get longer, the demos get narrower, and at some point everyone privately knows while nobody has said it.
The instinct at that moment is to change something dramatic: replace the team, rewrite the codebase, restart the plan. Sometimes one of those is right. It is almost never right before you understand what actually went wrong.
Reading the Symptoms
Estimates stop meaning anything. Not because they are large, but because they no longer correlate with outcomes. Two days becomes two weeks with no one able to say why.
Small changes cost as much as large ones. This is the clearest signal of structural trouble: the shape of the code no longer matches the shape of the requests.
Nobody wants to touch a particular area. There is a module everyone works around. That is where the real problem lives.
The demo narrows. Increasingly the same happy path is shown, and questions get deferred to next time.
Releases become events. When shipping requires a weekend and a rollback plan, the team will ship less often, and each release grows riskier. The cycle tightens on itself.
Diagnose Before Deciding
Spend a defined, short period establishing what is actually true before committing to any course of action. One to two weeks is usually enough, and it should produce a written answer rather than a feeling.
Read the code, but read the history too. Commit patterns show where the churn is and which areas are repeatedly reworked. Those are the places the design is fighting the requirements.
Talk to the engineers individually. People who will not raise a problem in a status meeting will usually tell you plainly one to one. In most stalled projects at least one person has known the real cause for months.
Establish whether the problem is technical, organisational, or about the requirements. All three present as slow delivery, and they need completely different responses. A rewrite fixes none of the second and third.
The Rewrite Trap
A rewrite is appealing because the existing code is visibly bad and the new code is imaginary, and imaginary code is always clean.
What it discards along with the mess is everything the current system knows. The accumulated handling of real-world cases that looks like clutter and is usually hard-won. Those conditions do not disappear with the code; they resurface one production incident at a time.
A rewrite also means a long period during which you are maintaining the old system and building the new one, delivering nothing new to users, and the original pressure that caused the problem has not gone away.
Rewriting is sometimes correct: an unsupported platform, a dead framework, a security position that cannot be remediated, a system so small the rewrite is genuinely short. The test is whether you can articulate what will be structurally different next time. If the answer is "we will be more careful", nothing has been learned and the second system will arrive in the same state.
Stabilise Before Improving
Whatever the eventual plan, the first job is to stop the bleeding and restore the ability to make a change safely.
Get a reliable build and a repeatable deployment. If shipping is frightening, nothing else can be fixed, because every improvement requires shipping.
Put tests around the areas you are about to change. Not the whole codebase. Enough to work in that area without fear.
Fix the loudest operational problems first, even the unglamorous ones. A team that spends its week on incidents has no capacity to improve anything.
Then deliver something small and visible. Restoring confidence, in the team and in the people funding it, is a real objective and not a soft one. Projects are cancelled for loss of confidence more often than for technical reasons.
Replace Gradually Where You Can
Where a component genuinely must be replaced, it is usually possible to do it incrementally: put a boundary in front of the old system, build the replacement behind it, and move traffic across piece by piece.
This is slower in total than a clean rewrite would be if the rewrite went perfectly, and much faster than a rewrite that does not. It keeps the system live throughout, and every step is individually reversible.
It also forces the team to understand the existing behaviour before replacing it, which is exactly the work a rewrite lets you skip and then punishes you for skipping.
The Conversation Nobody Wants
Sometimes the diagnosis is that the project should not continue in its current form. The market moved, the assumption did not hold, or the budget required is several times what remains.
Saying so is more useful than continuing. The sunk cost is gone either way, and the only live question is whether the next euro is better spent here or elsewhere.
If you are engaging outside help to assess a struggling project, make it explicit that "stop" is an acceptable conclusion. A reviewer whose next contract depends on the answer being "continue, with us" is not a reviewer.
Has your project stalled?
Tell us what you are trying to do and we will tell you honestly whether we are the right people for it.
Get in touch