Your software project failed. Here's what to do next

TL;DR: A software project rescue starts with three moves: secure your code, accounts, and IP; stop paying for new features; and get an independent read of what actually exists. In my experience, once a delivery team stops explaining what went wrong, the project won't recover with that team — nine times out of ten, the fastest and cheapest path is a structured takeover.

Bad code rarely kills a software project on its own. The weeks of denial that follow the bad code do. If you're reading this, the denial phase is probably over — which means you're already ahead of most founders in this situation. Here's what to do with that head start.

I run GrownApps, a development company that has been taking over broken, stalled, and abandoned software projects for years. This is the playbook I walk founders through on the first call, written down.

Why waiting makes it worse

It's in human nature to believe things will get better. Especially when the alternative means real pain, tough decisions, and blame landing on your head. I understand every founder who waits — I've watched many do it.

But I've also watched how the waiting actually goes. The usual repair attempts are always the same: more meetings, more pressure, more promises. Sometimes threats. None of it changes the trajectory, because none of it changes the people or the code.

Here's the test I trust after years of takeovers: does your delivery team transparently explain what went wrong — ideally before you ask? A serious vendor doesn't let a project fall this far if there's even a small chance to fix it. So if the explanations stopped and the promises multiplied, the project is already past the point where patience helps. In my experience, nine times out of ten it doesn't get better. The sooner you start looking for a replacement, the cheaper and faster the recovery gets.

You're also in bigger company than you think. McKinsey and Oxford analyzed 5,400+ IT projects and found that half of large IT projects massively blow their budgets, and 17% go so badly they threaten the existence of the company. Project failure is a normal industry event. Treating it like a shameful anomaly is what burns the extra months.

Late, broken, or doomed — figure out which one you have

Three different situations hide behind "my project is failing," and they need three different responses.

Late. The team communicates openly, the demos work, the codebase is honest — the schedule just slipped. This happens on healthy projects. If your team proactively explains the delay and the explanation holds up, you don't need a rescue. You need a scope cut and a realistic plan.

Broken. The demos look fine but nothing works underneath. Deadlines pass silently. Questions get vague answers. This is the product-shaped shell — screens polished exactly as deep as a demo click, because a failing team optimizes for the next status meeting. Broken projects don't self-heal, but they can usually be rescued: audited, stabilized, and finished by a different team.

Doomed. The honest question here has nothing to do with code: if the product worked perfectly tomorrow, would the business case still hold? If the market moved, the champion left, or the idea was never validated, finishing the build won't save it. Some projects deserve a dignified funeral, and I tell founders that to their face. More on that decision below.

The transparency test sorts late from broken fast. Sorting broken from doomed usually takes an audit — a few days of someone independent reading the code and the business case side by side.

The first 48 hours: stop the bleeding

Before any talk of rescue plans, do three unglamorous things.

Secure everything. Get owner-level access to the code repository, the servers and cloud accounts, the domain, the app store listings, and every third-party service the product depends on. Confirm in your contract who owns the IP. Founders skip this step because it feels adversarial — then the vendor relationship ends abruptly and they're locked out of their own product. I've seen clients get ghosted by their vendor mid-project. If that happens after you've secured access, it's painful. If it happens before, it's existential.

Stop paying for new features. Every euro spent building on a broken foundation is a euro spent twice — once now, once when the foundation gets fixed. Freeze scope. Keep the lights on, nothing more.

Get an independent read. You need someone with no stake in the previous narrative to tell you what actually exists versus what was paid for. Cross-referencing those two lists is the single most clarifying (and most painful) exercise in any takeover.

One thing I tell every founder at this stage, because it matters for how you interpret what the audit finds: missing documentation and hardcoded values scattered across the code are completely normal. That's the ordinary state of work in progress, and I wouldn't blame a previous vendor for it. Every real codebase is messy — the audit looks past the mess, at whether the architecture holds weight and whether the invisible 80% of the product exists at all.

The rescue playbook we run

Every takeover we do follows the same five steps — we call it the Turnaround Method. It exists because rescue projects fail when teams skip straight to "just fix it."

1. Triage. Decide what's on fire. Which parts of the system block the business right now — a customer deadline, a demo, a security hole? Rescue work starts from business survival, and everything else queues behind it.

2. Understand. Read the code before judging it. What's salvageable, what's rotten, what's missing entirely. This is where the audit happens, and it's where we decide what to keep. Maximum reuse of whatever holds weight, so new effort goes only where it's forced to go.

3. Restructure. Make the hard calls: which components stay, which get rebuilt, which technologies get swapped. These decisions carry the whole outcome, and they're bets — placed under time pressure, with incomplete information. This is the step where experience pays for itself.

4. Normalize. Boring on purpose: tests, CI/CD, monitoring, documentation of the parts that matter. The difference between a rescue that holds and a rescue you'll repeat in 18 months lives here.

5. Accelerate. Once the platform is stable, shift from survival mode back to roadmap mode — new features, on a foundation that can carry them.

The five steps look obvious written down. The discipline is in the order. Founders in crisis want step 5 immediately; vendors hungry for the deal promise it. Steps 1–4 are why the promise gets kept.

##Rescue, rebuild, or walk away — and how AI changed this math

For most of my career, this decision had a default answer. Senior development time was expensive, so it was usually wiser to fix the worst parts of the code and continue. Even when we recommended a complete rewrite, clients often didn't agree — so we made the bare essential fixes and kept their projects alive. Reasonable people, reasonable math.

That math broke around two years ago, from both sides at once.

On one side, AI-assisted building flooded the market with vibecoded apps — products assembled in tools like Lovable by founders who got a working-looking prototype and mistook it for a product. We now regularly get calls about apps that no professional team ever touched. On the other side, AI changed our own cost structure: we run an agentic delivery pipeline, under senior engineers' judgment, that can scan an app and its codebase and rebuild it test-first from the ground up.

The team behind Gauge, who study exactly this dynamic, put it precisely in their analysis of AI coding tools and legacy code: "the penalty for having a 'high-debt' codebase is now larger than ever." AI multiplies the speed of teams working in clean code and stumbles in messy code — which stretches the gap between patching and rebuilding wider every quarter.

So the decision tree I walk founders through today has three branches:

Rescue when the codebase has salvageable bones and the business has momentum a rebuild would stall — customers waiting, a deadline attached to revenue. This is still the right call for most professionally built systems, even badly built ones.

Rebuild when the foundation is unsalvageable — which describes most vibecoded apps we see. For those, letting the pipeline scan what exists and rebuild it properly is faster, cheaper, and safer than patching. Sound extreme? 81% of executives say tech debt already constrains what they can do with AI — dragging a broken foundation forward costs more every year, and the cost of a clean rebuild has never been lower.

Walk away when the business case is gone. I say this to founders more often than I used to, and it surprises them every time coming from someone who'd profit from the opposite advice: if there's no strong business case keeping this product alive, abandon it and put your money into something validated. Building today is the cheapest part of most projects. Burning another €50k to resurrect an unvalidated idea is the expensive part.

What a real rescue looks like: Tentacles IoT

In 2019, the founder of a Dutch IoT startup answered our cold outreach faster than anyone ever had. Call within two days, contract within two weeks. I took it as a compliment to our messaging. It took me embarrassingly long to understand what that speed actually meant: nobody moves that fast unless something is on fire.

Tentacles built wireless soil sensors for professional growers. Good hardware, real customers waiting — and a software supplier who had burned through most of the budget without shipping anything that worked. The web app had a few genuinely nice screens with nothing behind them; most buttons led nowhere, and the ones that did anything threw errors. The mobile app was an Ionic boilerplate wearing a nice skin. The runway was a few weeks, and a key customer needed a working prototype in three.

The rescue followed the playbook above. Triage said: the demo-critical path only, everything else waits. The audit said: keep the Symfony backend — the bones held weight — and scaffold the admin screens fast. Restructure meant one aggressive bet: rebuilding the mobile app in Flutter, in 2019, when Flutter had barely reached production status and most agencies wouldn't touch it. React Native was the safe-looking option, but it had serious problems with Bluetooth connectivity — disqualifying for a product whose entire job is pairing with physical sensors.

Three weeks later the founder had a working demo, and the customer who was ready to walk away stayed. Full production followed within months. Development costs came out 50% lower than under the previous supplier, operating profit returned, and thousands of sensors shipped. Seven years on, Tentacles is an established supplier in its market, including for Klasmann-Deilmann, the global leader in growing substrates.

I published the full Tentacles story, including the parts the founder hid from us until after signing, in my newsletter — it's worth reading if you want the unpolished version.

Switching development partners without losing months

The calls we get rarely open with "our project failed." Founders say their project is delayed, or that their vendor left, and then comes the real question: "Are you open to taking over someone else's work?" (Yes. It's most of what we do.)

Here's what to actually expect from the transition, from someone who's been on both sides of it.

Don't count on the old vendor's cooperation. I can't remember a single genuinely cooperative handover from a vendor who failed the project. Usually the client prefers to close out the relationship personally and hand everything to us themselves — and sometimes there's no one to close out with, because the vendor ghosted. Plan the handover as if the previous team won't answer a single email. If they do, treat it as a bonus.

The handover checklist is short: repository access, infrastructure and cloud credentials, domain ownership, app store accounts, third-party service logins, whatever documentation exists (accept that it's incomplete), and a written confirmation of IP ownership. If you did the first-48-hours step above, you already have most of it.

**A fair test for the new partner: **watch how they react to your worst news. Tell them the real state — the depleted budget, the hard deadline, the angry customer. A partner worth having hears the truth and responds with a triage plan. Anyone scared off by honesty would have failed you later, at a point where their failure costs more.

And for what it's worth: we've been the outgoing vendor too. Two or three times, clients moved their development elsewhere for their own reasons, and we handed everything over as cleanly as we could. The relationship stands above any commercial interest. Vendors who behave otherwise during handovers tell you exactly who they were during the project.

What a rescue actually costs

Most agencies answer this with "it depends" and a contact form. Here are our real numbers.

A rescue starts with a Tech Health Audit at €5,000 — codebase assessment, architecture review, tech debt quantification, and a recovery plan. It takes days to a couple of weeks depending on codebase size, and it's deliberately a small commitment: you get an independent diagnosis and a plan you can execute with us or with anyone else.

The rescue itself typically lands between €25,000 and €75,000 depending on scope and urgency, with ongoing partnerships at €10,000–15,000 per month after stabilization. McKinsey pegs tech debt at 20–40% of the value of a company's entire technology estate — against that baseline, a structured rescue is usually the cheapest thing on the menu. The most expensive option, in every failed project I've seen, was the extra six months of hoping.

FAQ

How do you rescue a failing software project? Secure code, accounts, and IP first; freeze new feature spend; then run an independent audit of what exists versus what was paid for. From there, a structured takeover follows five steps: triage what blocks the business, understand the codebase, restructure what can't hold weight, normalize with tests and CI/CD, then accelerate back to roadmap work.

How do I know if my project can still be saved? Separate the code question from the business question. Code is almost always salvageable or rebuildable — the real filter is whether the business case still holds. If the product worked perfectly tomorrow, would customers pay? If yes, rescue or rebuild. If no, walking away is the honest answer.

How long does a software project rescue take? The audit takes days to a couple of weeks. Emergency stabilization — getting something demonstrably working — took three weeks on our fastest rescue (Tentacles IoT). Full production readiness typically takes a few months, depending on how much of the original system holds weight.

Will my previous development team cooperate with the handover? Plan as if they won't. In our experience, vendors who failed a project rarely cooperate, and some disappear entirely. Secure repository access, infrastructure credentials, domains, and IP confirmation while the relationship still exists — before announcing the switch.

Should I rescue or rebuild my app? Rescue when the architecture has salvageable bones and business momentum makes a rebuild too slow. Rebuild when the foundation can't hold weight — which describes most AI-generated and vibecoded apps we audit. AI-accelerated delivery has made rebuilding dramatically cheaper, so the threshold for "just rebuild it" is lower than it was even two years ago.

Can a vibecoded app be rescued? Usually the honest answer is a rebuild rather than a rescue. Vibecoded prototypes prove the idea, but they typically lack the architecture, security, and test coverage a production system needs. We scan what exists, keep the validated product decisions, and rebuild test-first — faster and safer than patching a foundation that was never designed to carry load.

What does a software project rescue cost? Our audits cost €5,000 flat. Rescue projects typically run €25,000–75,000 depending on scope and urgency, with ongoing partnerships at €10,000–15,000/month after stabilization. The dominant cost in most failed projects is delay — every month of waiting adds spend without adding progress.

Whose fault is a failed software project? Less relevant than founders think, and the blame hunt burns time you don't have. Messy code, missing docs, and hardcoded values are the normal state of work in progress — the meaningful failure signal is a team that stopped transparently explaining what's going wrong. Fix the situation first; do the postmortem after the product ships.

If your project is the one this article describes

You don't need to decide between rescue, rebuild, and walk-away today. You need the facts those decisions depend on — and after the denial weeks, facts are a relief. That's what the €5,000 Tech Health Audit is: an independent read of your codebase, what it would take to save it, and an honest recommendation even when the recommendation is "don't save it."

If your product is stuck and you want a straight answer about what you're actually sitting on, talk to us. The first conversation costs nothing, and I'll tell you the truth about what I see. As this whole article argues — the truth, early, is the cheapest thing you can buy.

Sources

• McKinsey & Company / University of Oxford. Delivering large-scale IT projects on time, on budget, and on value. 2012.
• IBM Institute for Business Value. The tech debt reckoning. 2025.
• McKinsey & Company. Tech debt: Reclaiming tech equity. 2020.
• Gauge. AI Makes Tech Debt More Expensive. 2024.
• David Melich. A few weeks of runway, no working app: the Tentacles IoT story, in full. The Hard Ship, 2026.