Your project isn’t dead. It’s undiagnosed.
You raised the round, hired a team or an outside shop, and signed off on a roadmap. Now the release date has slipped twice, the original developer has moved on, and nobody can explain why a simple feature takes three weeks.
At this point, most technical leaders hear two pieces of advice. One camp says keep patching and push through. The other says the codebase is a mess and you should rebuild from scratch. Both can be expensive mistakes, and both are usually offered before anyone has properly looked at what you have.
This guide is for CTOs, VPs of Technology, and founders at funded startups whose build is at risk. It covers why projects stall, how to tell whether yours needs a rescue, how to decide between rescuing and rewriting, and what a disciplined recovery actually looks like. The aim is simple: get control back before you commit another dollar.
Why software projects stall
If your build is in trouble, you are in a large company. The Standish Group’s CHAOS research, drawn from over 50,000 project records, puts the share of fully successful software projects at about 31%. Roughly half finish late, over budget or short on scope, and around 19% fail outright (Rockstar Developer University summary of CHAOS 2020).
Money follows the same pattern. A McKinsey and University of Oxford study of more than 5,400 IT projects found large projects ran 45% over budget and 7% over time on average, while delivering 56% less value than predicted. Software carried the highest risk of overruns of any project type (McKinsey).
The causes are rarely exotic. In the rescues we see, three patterns account for most of the damage.
The handoff that lost the knowledge
A freelancer finishes a contract, an agency rotates its team, or your lead engineer takes another offer. The code stays behind, but the reasoning leaves with them. Why does checkout call that service twice? Why is this table denormalized? Nobody knows, so every change becomes a guess.
Scope that drifted away from the brief
The original spec described one product. Six months of investor feedback, sales requests, and pivots produced another. Each change made sense alone, yet nobody updated the architecture or the plan to match. The team is now building on foundations designed for a different product.
Decisions nobody wrote down
Shortcuts taken to hit a demo, a vendor chosen in a hurry, a security trade-off agreed on a call. These hidden decisions pile up quietly. They only surface when something breaks, and by then the people who made them may be gone.
Warning signs your project needs a rescue
Most stalled projects send signals for months before anyone calls them stalled. If several of these sound familiar, the problem has moved past normal delivery friction.
Estimates keep growing, and nobody can explain why. A two-day task becomes two weeks, and the answer is always “it’s complicated.” That usually means the team no longer understands the system well enough to predict it.
Every fix breaks something else. When a bug fix in billing causes a failure in notifications, the codebase has hidden coupling and probably very few automated tests.
Only one person can deploy. If releases depend on a single developer’s laptop, memory or goodwill, you don’t fully own your product.
The demo works, but production doesn’t. Features look finished in staging, then fall over under real users, real data or real load.
You can’t get a straight answer on progress. Status reports say “80% done” for weeks. Joel Spolsky made the point years ago that this number means almost nothing without small, verifiable tasks behind it.
Your board is asking questions you can’t answer. When investors ask about the launch date and you’re relaying guesses from the dev team, the project has become a business risk, not just a technical one.
One or two of these is normal. Three or more, sustained over a quarter, is the point where an outside diagnosis pays for itself.
Rescue or rewrite: how to decide
When a codebase feels unworkable, a full rewrite is tempting. It promises a clean slate, modern tools, and no inherited mess. It also resets your timeline to zero at the moment your runway is shrinking.
The classic warning comes from Joel Spolsky’s essay on Netscape, which rewrote its browser from scratch and went almost three years between major releases while competitors moved ahead (BSSw summary). Ugly code often carries years of bug fixes and edge cases that nobody documented. A rewrite throws that away quietly, and the new team rediscovers each problem the hard way.
That doesn’t mean rewrites are always wrong. Sometimes the stack is truly obsolete, or the product has changed so much that little of the old code applies. The point is that the call should come from evidence, not from frustration or from whoever stands to bill for the rebuild.
These are the questions we use to make that call:
| Question | Points toward rescue | Points toward rewrite |
| Does the core work for real users today? | Yes, with bugs and gaps | No, core flows fail |
| Is the stack still supported and hireable? | Yes | No, or near end of life |
| How close is the product to the current brief? | Mostly aligned | A different product now |
| Can modules be fixed or replaced one at a time? | Yes | Everything is tangled together |
| Can you survive 6 to 12 months with no new releases? | No | Possibly |
In our experience, most stalled startup builds land in the rescue column. The code is rarely as hopeless as it feels. What’s missing is documentation, tests, and a clear plan, and those can be added without throwing away the parts that work.
How a disciplined project rescue works
A good rescue gives you clarity before it asks for commitment. At AvyaTech, we run every recovery in four stages, and you decide whether to continue after each of the first three.
AvyaTech Project Rescue · 4 stages, 3 decision points
Stage 1: A fixed-fee audit
The audit is priced up front, so the diagnosis can’t turn into an open-ended bill. Engineers review the repository, the infrastructure, the deployment process, and the original brief. They also talk to whoever is still around: your team, previous developers if reachable, and the people who use the product.
The output answers the questions you actually need answered. What works, what’s broken, what’s risky, and how far the build has drifted from what you paid for.
Stage 2: Documenting every hidden decision
This is the step most teams skip, and it’s the one that stops the next handoff from repeating the last. We trace why the system is built the way it is: the shortcuts, the vendor choices, the workarounds, the security trade-offs.
Each decision gets written down with its consequence and a recommendation. You end up with something most stalled projects never had, a map of the system that any competent engineer can pick up.
Stage 3: A written recovery plan
The plan sets out what to keep, what to fix, what to replace and in what order. It includes effort estimates, milestones and the risks that remain. Because it is written, you can take it to your board, compare it against other vendors, or hand it to your own team.
This is the point where you regain control. You know what you have and what finishing it will cost, before you commit to more spend.
Stage 4: Finishing the build
If you choose to continue with us, we work through the plan in small, verifiable increments. Tests go in before risky changes. Releases become routine instead of events. You get progress you can see in working software, not percentages in a status report.
The goal is a finished product that your team can own and extend, without depending on us or anyone else to explain it.
Why freelancers patch, and agencies rewrite
When a project stalls, the first people you call tend to see the problem through the lens of what they sell.
A freelancer is usually hired for a ticket or a sprint. They fix the bug in front of them, often well, and move on. Nobody is paid to step back and ask why the bugs keep coming, so the symptoms get treated while the cause stays put.
A large agency faces the opposite pull. A rewrite is a bigger, longer, more predictable engagement than untangling someone else’s code. It is also easier to staff with their own standard team and stack. That doesn’t make every agency recommendation dishonest, but the incentive leans one way.
A rescue partner should be paid to find the cheapest credible path to a finished product, whatever that turns out to be.
What to look for in a rescue partner
A fixed price for the diagnosis. If the audit is billed by the hour with no cap, the diagnosis itself can become the next overrun.
A written deliverable you own. You should be able to take the audit and plan elsewhere if you choose. A partner who won’t put findings in writing wants you dependent on them.
Willingness to recommend against themselves. Ask directly: “If you found that a rewrite was right, or that our current team could finish this, would you tell us?” Watch how they answer.
Experience with inherited code. Building from scratch and recovering someone else’s build are different skills. Ask for examples of the second.
Small increments after the plan. Recovery work should ship in pieces you can verify, not disappear for three months before a big reveal.
What to secure before you call a rescue team
The faster a rescue team can see the real state of your project, the cheaper and more accurate the audit. Before the first call, make sure you control the essentials.
Repository access. Confirm the code lives in an account your company owns, with admin rights held by someone on your side. If it sits in a former developer’s personal GitHub, move it now.
Infrastructure and credentials. Cloud accounts, domains, app store listings, payment providers and third party APIs should all be registered to the company. List every service you pay for, because each one is a dependency.
The original brief and what changed. Gather the first spec, the contract, and any documents or messages where scope shifted. This is how the audit measures drift.
A list of known problems. Write down the bugs, slowdowns and missing features that worry you most, in plain language. Your view of the business impact matters as much as the engineers’ view of the code.
Contact with previous developers, if possible. Even a one hour conversation with someone who built the system can save days of reverse engineering.
Protecting yourself in the next handoff
Whatever happens with this project, the same rules prevent a repeat. Own every account from day one. Require written handover notes at the end of each engagement. Keep architecture decisions in a shared document, not in someone’s head. And treat automated tests and a repeatable deployment process as part of done, not extras for later.
Software project rescue is the work of diagnosing a stalled or failing build, documenting how it really works, and finishing it without starting over. It suits projects that have broken down after a developer handoff, drifted from the original brief, or stopped making visible progress.
It depends on the size of the codebase and how much access is available, but a focused audit for a typical startup product runs in weeks, not months. Fast access to the repository, infrastructure and previous developers shortens it considerably.
For most startup builds, rescue costs less because it keeps the parts that already work and avoids a long period with no releases. A rebuild can make sense when the stack is obsolete or the product has changed beyond recognition. An audit tells you which case you are in.
First check your contract and who owns the accounts involved. If the code was written for your company under a proper agreement, you likely have a strong claim to it, and a lawyer can advise on recovering it. This is also why securing repository access early matters so much.
Yes. The audit and recovery plan are yours to keep. Some clients hand the plan to their own engineers, some bring in another vendor, and some continue with us. A good plan should work in any of those scenarios.
AvyaTech works with US founders and technology leaders, with overlap hours for calls, written documentation at every stage, and fixed pricing for the audit so there are no surprises across time zones.
Sources
Better Scientific Software: Things You Should Never Do, Part I (summary of Joel Spolsky’s essay)
