Insights · 11 min read
How to recover a failed software project: the salvage-or-rebuild decision, a clean code handover, what a rescue actually costs, and how to choose the team that takes it over.
By GGP Editorial
Most software projects do not fail all at once. They drift. A deadline slips a few weeks, then a few more. The demo only works with one specific set of data. The lead developer stops answering questions directly. By the time someone says the word "failed" out loud, the project has usually been failing for months.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, serving clients across Brazil, South Africa, Singapore and the US. A steady share of our work starts with a project someone else could not finish. We take over codebases, read what the previous team left behind, and either pull the project back on track or rebuild the broken parts. This guide is what that process looks like from the inside.
It is written for the founder, CTO or project owner who has already spent money, has a half-built product, and needs to make a decision. Not for developers debating frameworks.
The first job is an honest assessment. These are the signs that show up again and again in projects we take over.
Missed milestones that keep moving. The team misses a deadline and gives a new date, then misses that one too. After two or three rounds, the plan means nothing.
A demo that only works in one scenario. The happy path works and everything else has never been tried. No tests, no error handling, no edge cases.
One person holds the whole thing together. If the lead developer left tomorrow, nobody could run or explain the system. That is a staffing risk, not just a technical one.
No code has shipped recently. Months of "refactoring" and "architecture work" with nothing a user can actually touch.
The team avoids showing you the repository. You ask for access or a code review and get delays, excuses, or a cleaned-up snapshot instead of the real history.
Scope has grown without a matching plan. The product keeps absorbing new features while the core stops working.
Any one of these is worth investigating. Three of them together means the project is in trouble, and the sooner you act the more of your budget survives.
It helps to know how a project gets into this state, because the rescue usually fails for the same reasons the original build did.
The most common cause we see is a fixed scope built on a guess. Someone estimated the work before the requirements were understood, locked a price, and then the team spent months negotiating scope instead of building. The second is a team that outgrew its skills. A project starts small, the architecture gets bigger than the team can hold, and quality collapses quietly. The third is ownership that never transferred. The client never had the repository, the credentials or the knowledge, so there was nobody on their side who could see the drift early.
None of these are about the technology. They are about process, skill and control. That is why the rescue has to fix all three, not just the code.
This is the choice every rescue comes down to, and it should be made on evidence, not hope.
Run a code audit first. A senior engineer with no history on the project reads the repository for a few days and reports what is actually there. Is the code testable? Is it secure? Does the architecture match what the product needs? Can a new team pick it up? Our guide to software technical due diligence explains what a code audit covers and what it should cost.
The audit gives you a salvage score. I think of it as three buckets.
| Audit finding | Usual outcome |
|---|---|
| Code is structured, tested and documented; the team stalled on process or scope | Salvage and finish |
| Code works but is undocumented and brittle; core logic is sound | Partial salvage, targeted rewrite of the risky parts |
| Code is tangled, untested, insecure; the architecture fights the product | Restart the affected modules, keep the requirements |
A rough rule we use: if the audit says more than half the codebase has to change to become stable, you are paying for a rebuild either way. The only question is whether you pay for it once, cleanly, or keep paying to patch a foundation that keeps breaking.
Two things make salvage cheaper than people expect. The requirements work is never wasted. Whatever the previous team learned about the product, the market and the users still counts. And the existing data and domain logic, even inside messy code, tell the new team exactly what the system must do. Rebuilding is faster when the old system exists as a working specification.
Most failed handovers fail at the handover itself. The previous team is demotivated or defensive, and the new team starts coding before it has the keys. That is how you pay twice.
Get these in hand, in writing, before a single line is written.
Full repository access. Not a zip file. Access to the real git history, branches and the CI/CD pipeline if one exists.
All credentials and environments. Servers, databases, third-party accounts, DNS, app store accounts, analytics. Missing credentials are the most common reason a "finished" product cannot be relaunched.
Documentation, or an honest statement that none exists. Either is fine as long as it is stated up front.
Intellectual property and contract status. Who owns the code? Is there source code escrow? Did the previous team use third-party code with licenses that restrict you? Our guide to protecting IP when outsourcing software development covers the ownership questions, and the software development contract checklist lists what should have been in the agreement.
A list of known issues. Ask the previous team, on the record, what they know is broken. People leaving a project will often tell you more in the exit interview than they ever said during the build.
If the previous vendor refuses to hand over the code or credentials, that is a separate problem with its own solution, usually legal. Do not let it block the technical work. Run the two tracks in parallel.
People assume a failed project means everything was wasted. That is rarely true.
What usually survives: the requirements and the domain knowledge, the data model and the data itself, the product decisions and user feedback, and the third-party integrations that already work.
What is usually thrown away: the parts the previous team built while it was still figuring out the architecture. Early prototypes that made it into production. The code written in the final rush. Anything with no tests that touches money, identity or security.
The painful truth is that the second list is often half the codebase. That is why a rescue can cost as much as a new build. You are not paying for the code that worked. You are paying to remove the code that did not, and to rebuild it properly.
If the codebase is genuinely old rather than broken, this overlaps with a different kind of project. Our guide to legacy system modernization covers that case.
There is no clean number here, and any vendor who quotes one before reading the code is guessing. What I can give you is the shape of the cost.
A rescue has three phases, each with its own price.
Assessment. A code audit plus a short discovery pass. Usually one to three weeks. This is the cheapest part and the part most people skip, which is a mistake, because every later number depends on it.
Stabilization. Get the system running, secure, backed up and under version control so it stops bleeding. The scope depends on what the audit found.
Rebuild or finish. Either finish the salvageable parts or rebuild the broken modules. This is the largest line item, and it behaves like a normal development project from here on.
As a planning range, a modest rescue where the core is sound often lands in the same range as the original remaining budget, sometimes less. A full rebuild of a badly broken product costs about what building it properly would have cost in the first place, minus the requirements work you already paid for.
The expensive path is the middle one: paying a team to keep patching broken foundations while the product limps along. That is how a six-month fix becomes a two-year problem. Our guide to estimating a custom software project shows how to turn a scope into a number you can hold someone to.
The team that takes over a failing project needs different skills from the team that starts one fresh.
They need to read other people's code quickly. This is a specific skill, and it is not the same as writing new code fast.
They need to be blunt about what is broken. You do not want a vendor who tells you everything is fine to keep the deal alive. You want the one who tells you on day five that two modules have to be rebuilt.
They need a track record of takeovers. Ask directly: how many projects have you taken over from another team, and can I talk to one of those clients? A vendor who has never rescued a project will learn on your budget.
They need to be comfortable with a phased plan. Rescue work does not fit a single fixed-price contract for the whole thing, because the first phase changes the scope of the rest. The pattern that works is a short paid assessment, then a fixed scope for stabilization, then time-and-materials or a new fixed scope for the rebuild. Our guide to fixed price vs time and materials covers how to pick, and how to choose an offshore development partner covers the vetting questions.
For many clients a dedicated development team is the right shape for a rescue. You want the same people who did the audit to do the rebuild, without a handoff in between.
A rescue fails twice when the client repeats the mistakes that broke the first project. The three that matter most.
Insist on working software every sprint. If the new team cannot show you something running every week or two, stop and ask why. This single rule catches most failures early.
Put ownership of the repository with you from day one. Your git account, your servers, your credentials. If the next team leaves, you still have the product. If the previous team had held the keys, the rescue would not have been necessary in the first place.
Agree on a definition of done before you pay for more than the assessment. What does "rescued" mean? The product deploys? Passes a security review? Handles a specific load? Write it down. It is the only way to know when the rescue is over.
How do I know if my project is worth saving?
Run a code audit. If the core logic and data model are sound and the code is mostly testable, salvage it. If more than half has to change to become stable, you are rebuilding anyway. Make the call on evidence, not sunk cost.
How long does a rescue take?
An assessment runs one to three weeks. Stabilization usually runs four to eight. The rebuild is a normal project and follows its own timeline. The quickest rescues are the ones where the client lets the audit finish before demanding a full plan.
Why does a rescue sometimes cost more than starting over?
Because you are paying to remove the code that did not work before you build the code that does. The requirements work carries over, but broken foundations have to come out first.
What if the previous vendor will not hand over the code?
That is a contract and IP problem, handled separately from the technical work. Check your agreement, then get legal help. Meanwhile a new team can still start on requirements and architecture so the project does not stall entirely.
Can we keep the old team and just add a senior engineer?
Sometimes, if the problem is one missing skill. If the problem is the team itself, adding a person to a broken process gives you a faster broken process. The audit should tell you which situation you are in.
---
If your software project is stuck, half-finished or quietly failing, tell us what it was supposed to do, where it stopped, and whether you still control the code. We can audit what exists, tell you honestly what is worth saving, and put a phased plan and a real budget against the recovery.
Tell us what you are building and where you are today. We typically reply within 24 hours.
