Who Can Rescue a Failed Software Project?

You are not rare. A McKinsey study with researchers from Oxford found that large IT projects run 45 percent over budget, 7 percent over schedule, and deliver 56 percent less value than predicted. Seventeen percent go badly enough to threaten the company's existence. Failure at some scale is the norm, and rescue has become a practiced craft. Plenty of failed projects can be saved. Finding the team qualified to save this particular one is the hard part.

Secure what you own before anything else

Week one of a rescue has nothing to do with code. It's inventory.

Before you announce a breakup, before you post the bad review, before you even reply to that last defensive email, get the assets into your name:

• Repository access, or the source code itself if there is no repo
• Hosting and server accounts
• The domain registrar login
• Third-party services: payment processor, email sender, SMS, maps, whatever the app touches
• Database backups, and the credentials to reach them
• Environment variables and API keys, the unglamorous strings that make the whole thing run
• The last version anyone demonstrated successfully

We have taken over projects where the only copy of the code lived on a departed developer's laptop. We have taken over projects where the client controlled everything within an hour of asking. Same software on paper. Completely different rescue.

If the relationship is hostile, change the passwords on hosting and the registrar the same day, before the argument starts.

Nobody regrets rotating credentials too early.

Dead, stalled, or mislabeled

Failed projects come in three shapes, and the economics differ for each.

The first works but is incomplete. It handles real customers, it's missing the two features everyone was promised, and the last 20 percent is the hardest part to build. The second doesn't work and nobody can say why: it crashes, data goes missing, every fix introduces two new problems. The third never really started. You have invoices, mockups, and a codebase with the density of a pamphlet. Yes, that happens. More often than anyone admits out loud.

Triage tells you which one you have, and it redefines what rescue means. A stalled project usually needs stabilization and a plan, not a rebuild. A mislabeled one needs someone honest enough to tell you the emperor has no code, so you stop paying to store a ghost.

The question worth money: what fraction of the current system actually runs? Sometimes it's 10 percent and the code deserves its funeral. More often it's 70 percent, and the cheapest path to a working product runs straight through the thing you were told to write off.

Who actually takes over

Four realistic options, with the trade-offs nobody puts in a proposal.

The original team, sometimes. If the failure was communication, scope creep, or a vanished product owner on your side, a reset conversation is cheaper than a takeover. Write down what done means, cut the feature list in half, and see if they can hit one small date. If the failure was capability, no process will fix that. One honest conversation is worth having before you pay anyone else to have it.

A new solo freelancer. Priced right, and sometimes correct for a small repair. But rescue is a different skill from building. You're asking someone to diagnose a stranger's decisions with no documentation and no tests, which is senior work at whatever rate the marketplace suggests is junior. The freelancers who do this well exist. They're booked, and they ask audit questions before they quote.

A large consultancy. They will accept the project, staff it, and run a disciplined process. That process is built for enterprises and priced accordingly, usually heavier than a stalled internal tool needs. If you have a compliance department and seven stakeholders, this can be the right lane.

A specialist rescue shop. Firms that do takeovers and legacy modernization as a primary service, not a side job. They arrive with an audit checklist instead of a sales deck, they've read orphaned codebases before, and their business model depends on telling you the truth about what's salvageable, because their reputation is built on rescues, not on landing new builds.

What a real rescue looks like, week to week

There's a shape to a serious takeover, and you should hold any candidate to it.

Week one is the audit, and it should be fixed-price. Repository, infrastructure, data, third-party dependencies, and the contract you signed with the previous team. The deliverable is a written triage report: what runs, what's broken, what's missing, what it will take in hours to stabilize, and a repair-versus-rebuild recommendation with numbers behind it. You should be able to take that report to a different firm and act on it. If the audit isn't portable, it isn't an audit.

Then stabilization. No new features. Get the current system deployable again, backed up somewhere safe, and watched closely enough that the next crash pages a person instead of surprising everyone at the Monday meeting. This usually takes days to weeks, not months, and it buys calm. Big decisions made calm are cheaper than big decisions made angry.

Then the smallest useful release: one improvement the business can feel. A rescue that goes quiet for four months while it rebuilds the foundation is failing the same way the original project did, just with better intentions.

The rebuild-or-repair decision comes last, with evidence, never in the first sales call. We've been building and taking over software for fifteen years, and the projects where a full rewrite was genuinely the right call are a minority. Most failed systems have a load-bearing core that works. The craft is finding that core before you bulldoze it.

How to tell a rescuer from a rewriter

The rewriter's first sentence is some version of "this codebase is a mess, we should start fresh." Sometimes that's true. It cannot be true before anyone has read the code, and it is suspiciously always the option that bills the most hours.

Signs you're talking to a rescuer:

• They want the repository, the ticket history, and the old contract before they'll quote anything.
• They can name, unprompted, what they'll look at during discovery.
• They have references from takeovers specifically, not from projects that started clean.
• They'll tell you when the code is fine and the process was the problem. We've finished audits and told clients their system was healthy, their vendor was fine, and what they actually needed was a product owner on their own side. That answer cost us the engagement. It was still the right answer.
• The engagement is phased so you can stop at each gate without a lawyer.

Signs you're not:

• A full-scope quote produced within 48 hours of a single call.
• "We'll figure out the team once you sign."
• Discovery priced as a percentage of the project instead of a fixed fee.
• No mention of what happens if the audit says the thing should be turned off.

That last one matters most. A team that can't describe the kill scenario has never delivered one, which means they've never been honest at exactly the moment honesty was expensive.

What it costs and how long it takes

Anyone who answers that question without an audit is guessing with your money. The honest structure has three moving parts. A fixed-price audit measured in weeks. Then stabilization as its own small engagement, so the bleeding stops while you decide. Then the main work, estimated against evidence instead of hope, with each phase ending in something you can evaluate.

If the news after the audit is that the project should die, a good firm says so and sends the report anyway. Killing a doomed project early is a return on investment, just an unglamorous one. And sometimes the rescue turns out small. We've had audits end with "move this to managed hosting, delete three features nobody uses, and you're done." A rescue that ends in three weeks is still a rescue.

Make the first call useful

When you contact anyone, including us, have this ready: repository or code access, hosting and registrar logins, a list of what currently works, a list of what doesn't, and the budget ceiling you can defend out loud. A rescuer with that list can tell you something real in the first conversation. Without it, everyone is guessing.

If there's a stalled or half-finished project on your books, our legacy rescue and modernization service starts with a fixed-price audit of exactly what you're sitting on, so the next decision gets made on evidence. Worst case, you learn the thing should be turned off, cheaply and on purpose. Best case, most of what you paid for is still in there, waiting for the right team to switch it on.