Rescuing a Stalled Software Project
Last updated:
The shape of a stalled project
The pattern is consistent. Twelve months in, most features are “nearly done”, nothing is in production, the budget is spent and the relationship with the supplier has deteriorated. Everyone is exhausted and nobody can say how far from finished it is.
The cause is almost always the same: no phase ever shipped. Without a production release there is no feedback, no proof and no forcing function — so scope grew and completion stayed six weeks away for a year.
“Nearly done” is the most expensive phrase in software. It has no definition and it can be repeated indefinitely.
First: stop building
The instinct is to push through the remaining 20%. It is wrong, because nobody knows whether it is 20%. The first action is to stop adding and establish what actually exists.
- What runs, in what environment, right now?
- Which features work end to end, verified by using them?
- Which are half-built and which are stubs?
- What has been tested by anyone other than the developer?
- What would have to be true to put something in front of a real user next month?
Get one thing into production
The highest-value action in a rescue is almost always to get one narrow slice live, even a small one. It changes everything: it proves the system can be deployed, it produces feedback, and it restores the belief that this project can ship.
We would rather launch one workflow to ten users in six weeks than complete three more features in the same time. The launch tells you what the remaining work is actually worth.
Working out what is salvageable
| What we find | Usual answer |
|---|---|
| Good data model, messy code | Keep everything. It is recoverable |
| Good code, wrong data model | Keep the edges, rebuild the core |
| Working code, no deployment | Keep. Fix deployment first |
| Features nobody validated | Cut them. They were never proven necessary |
| Third-party integration never completed | Usually the hard part nobody scoped |
That last row is the most common cause of a stall. The integration was assumed to be simple, turned out not to be, and the project worked around it for months rather than confronting it.
Deciding whether to finish at all
Sometimes the right answer is to stop. The business case has changed, the market moved, or the cost to complete exceeds the value.
We assess that honestly, including when it costs us the work. Two rescue assessments we have done ended with a recommendation to stop and buy an off-the-shelf product instead, and both clients thanked us for it. Finishing a project that should not be finished is the most expensive outcome available.
What a rescue costs
- Assessment: £4,000–£10,000, one to two weeks, written report
- Stabilise and ship one slice: typically six to ten weeks
- Completion: priced properly once the first two are done, not before
We will not quote a completion price before the assessment. Anyone who does is guessing at a system they have not opened, which is how the project got here in the first place.
Frequently asked questions
Can you work with our existing developer?
How do we know your assessment is honest?
What if the previous supplier holds the code?
Is a rescue more expensive than starting again?
Inherited a system, or a project that stalled?
We start with an audit and a written verdict — including when the verdict is that you should keep what you have.
Related services
What we build for problems like this one