Rescuing a failed software project vs starting over
Audit before you decide: that is the honest answer, and it holds in both directions. Most stalled software projects keep more salvageable value than the frustration suggests — working modules, paid-for integrations, hard-won business logic — but not all of them do. The decision comes down to three measurable criteria: access, architecture and remaining budget.
Failure at this scale is common, not rare. A McKinsey–Oxford study of 5,400 IT projects (October 2012) found large projects run 45% over budget and deliver 56% less value than promised. Doomity, a software development firm serving clients in the US, UK, Spain and Portugal, wrote this guide so owners can make the rescue-or-restart call with evidence instead of emotion.
Updated: July 2026
Should you rescue a failed software project or start over completely?
Neither option is the default. Rescuing a failed software project wins when you can recover access, the architecture holds up under audit, and the remaining budget will not stretch to a rebuild. Starting over wins when the foundations actively block your roadmap and you can fund months of work without shipping anything.
The mistake is deciding from frustration before anyone has read the code. Doomity's position, after years of taking over other people's codebases, is simple: an independent audit costs days, while the wrong choice between rescue and rewrite costs months. Buy the information first.
Why does sunk cost push you toward the wrong decision?
Sunk cost distorts this decision in both directions, which is why it deserves its own section. Owners who have spent heavily feel forced to continue with a failing vendor, because stopping would "waste" the investment. That money is gone either way; only future spend can still be optimized.
The reverse trap is just as expensive. After months of broken promises, burning it all down feels like justice, and a rewrite quote sounds like a clean start. Doomity treats the existing code as an asset to be valued, not a symbol of the failure — the audit says what it is actually worth.
How do rescuing and starting over compare side by side?
The table below is the comparison Doomity walks through with owners deciding between a rescue and a rebuild. Each row is a dimension you can score for your own project today.
| Dimension | Rescue the project | Start over |
|---|---|---|
| Sunk cost treatment | Recovers part of what you already paid for: working code, integrations, domain logic | Writes off everything built so far, including the parts that work |
| Time-to-value | Weeks — stabilization improves the running system while the business keeps operating | Months — nothing usable ships until the new build reaches feature parity |
| Risk | Inherited technical debt and unknowns hidden in the existing code | Second-system risk: new bugs, lost edge cases and another vendor bet |
| When it wins | Access is recoverable, the architecture is sound and budget is limited | Access is gone for good, the architecture blocks the roadmap and budget covers a full rebuild |
No single row decides alone. A project can score badly on risk and still be the right rescue, because time-to-value dominates for the business.
When does rescuing the existing project clearly win the comparison?
Rescue wins more often than owners in the middle of a failure expect. If the repository and cloud accounts can be recovered, and the audit finds a sound core under the mess, stabilizing beats rebuilding on both cost and time-to-value.
Speed matters here, because a rescue must show progress while the business keeps running. Doomity runs these takeovers on an AI-integrated delivery process, up to 40% faster, with every finding checked by a senior engineer. Its engineers come from teams that have built for Holcim, Canon España and Indra, where entering large unfamiliar codebases was the starting point.
When is starting over from zero genuinely the better call?
Starting over is the right call in a minority of cases, and an honest vendor names them. The clearest ones: the codebase is unrecoverable because access is legally or practically gone; the architecture cannot support the product you now need; or the stack is so obsolete that every future hire gets harder.
Budget is the fourth test. A rebuild means paying twice for features you already bought, with months of parallel work before parity. If the numbers still favor a rewrite after that math, then it is a decision — not a reaction.
What are the first five moves when a software project stalls?
Whatever you eventually decide, the first week looks the same. These five moves protect your options before rescue-versus-restart is even on the table:
- Secure access first. Get the repository, cloud, domains and CI under accounts your company owns. Every later option depends on this step.
- Freeze new feature spending. Stop paying for code nobody has reviewed; a short pause costs less than another broken sprint.
- Gather the paper trail. Contracts, invoices, IP clauses and old emails establish what you legally own.
- Commission an independent audit. Someone with no stake in the answer reads the code and states what is actually there.
- Decide between priced options. Continue, restructure or rebuild — each with a number and a trade-off, not with adjectives.
What should you do if your development agency disappeared overnight?
A vanished vendor changes the order of the work, not the outcome. If your development agency disappeared with the repository or the cloud accounts, recovery starts from what you hold: contracts, invoices, the production URL, old emails. Ownership clauses usually favor the client more than the client assumes.
Doomity starts many rescue engagements in exactly this situation: mapping who legally owns which accounts, licenses and IP, then executing the recovery steps. Silence from a vendor is an access problem with a process, not a reason to write off the project.
How do you decide with evidence instead of frustration or guesswork?
Two tools replace guesswork. The first is a structured self-assessment: Doomity publishes a free rescue scorecard that scores access, architecture and budget in a few minutes, before you talk to anyone.
The second is market data for the rescue side of the ledger. Saritasa, a US development firm, reports its project takeover clients "spend a minimum of $80,000 a year", and German consultancy Groenewold IT publishes €7,000–21,000 for a complete project takeover. Compare those ranges with your rebuild quotes and the sunk-cost fog starts to lift.
FAQ
Usually rescue, when access and architecture allow it, because you keep the value you already paid for. As market context, Groenewold IT publishes €7,000–21,000 for a complete project takeover, while a rebuild means re-buying every feature you already own. Doomity prices both paths after a five-day audit, so the comparison uses your numbers instead of industry averages.
Yes, in most cases. Contracts, invoices and IP clauses usually establish that the work belongs to the client, and cloud providers have processes for recovering account ownership. Doomity treats access recovery as the first item on the risk map and starts with whatever you have — even just a production URL and the paperwork. Most owners have more recovery options than they think.
Days, not months, if the audit is scoped correctly. Doomity's Rescue Triage answers the rescue-or-restart question in five days, with a risk map and options A, B and C, each priced. A diagnosis that takes two months is itself part of the problem it was hired to solve.
Yes, when the evidence points that way. Doomity's roadmap always includes a rebuild option with its real cost and timeline, and sometimes that option wins — typically when access is unrecoverable or the architecture blocks the product. What Doomity refuses to do is recommend a rewrite before reading the code, because that advice sells comfort, not recovery.
If your project has stalled and you want the rescue-or-restart question answered for your specific codebase, the next step is a fixed-scope audit with guaranteed deliverables.