Most failing software projects don’t die from one catastrophic decision. They bleed out. A missed milestone here, a scope addition there, a two-week delay that somehow compounds into three months, and suddenly you’re sitting on $80,000 spent with nothing shippable. The founder’s instinct at that point is almost always to cut the agency, find someone new, and start fresh. Nine times out of ten, that instinct is wrong – and acting on it will cost you another $60,000 to $100,000 to rebuild context and momentum that already exists in the codebase you’re walking away from.
We’ve been brought in to rescue builds at various stages of distress. The patterns are consistent enough that we can usually tell within a day of reviewing the repo and the delivery history whether the project is salvageable, how long recovery will realistically take, and what it will cost. What follows is that diagnostic framework – the same one we run internally when we inherit a struggling build.
First, Separate the Code Problem from the Process Problem
This is the most important distinction you can make, and most founders skip it entirely because they’re frustrated and want someone to blame. But they’re different problems with different fixes.
A code problem means the technical decisions made so far are genuinely bad – brittle architecture, no test coverage, a database schema that makes the core feature impossible to build cleanly, security holes that would take weeks to address. These are real, they’re costly, and sometimes they do mean you need to scrap significant portions of the build.
A process problem means the underlying code is actually fine, but the delivery has been chaotic – no clear acceptance criteria, requirements changing mid-sprint, poor communication about blockers, no one owning scope decisions. In this case, the code can be saved. You just need to change how the project is being run.
In our experience, the majority of distressed builds we inherit are process problems wearing the costume of code problems. The developer has been responding rationally to unclear direction. The founder has been adding features without understanding what that does to the sprint. Nobody has been the adult in the room about trade-offs.
Before you do anything else, pull a developer you trust – not the one currently on the project – and spend two to three hours doing a code review. Not to nitpick style choices, but to answer one question: is the foundation structurally sound? If it is, you have more options than you think.
The Distress Audit: What to Actually Look At
When we take over a struggling project, we run a structured review across four areas. You can do a version of this yourself before you make any decisions.
- Delivery artefacts: Do tickets have clear acceptance criteria? Is there a changelog? Can you trace what was built in the last four weeks and whether it matches what was agreed? If the answer is “it’s mostly in Slack threads,” that’s a process problem – but an honest one to work with.
- Codebase health: Run a static analysis tool. Look at test coverage. Check whether there’s any documentation for the non-obvious parts. Look at the git commit history – is it coherent or a mess of “fix fix fix” commits with no context?
- Architecture against requirements: Take the three most important features that still need to be built and ask: does the current architecture support them without major surgery? If building feature B requires dismantling what was built for feature A, you have a sequencing problem that will compound the longer you ignore it.
- Scope creep forensics: Go back to the original brief and compare it to what’s actually been built or added to the backlog. Calculate the percentage of current scope that wasn’t in the original agreement. In most distressed projects we see, this sits between 30% and 60%. That number explains a significant portion of why the budget is gone.
This audit typically takes one to two days if you have access to the repo, the project management tool, and someone technical who can read code honestly. Don’t skip it. Every hour you spend here saves you from making a decision based on emotion rather than evidence.
The Recovery Decision: Three Paths, Not Two
The binary “keep going vs. start over” framing is a false choice. There’s actually a third option that most founders never consider, and it’s often the right one.
Path 1: Stabilise and continue. If the code is fundamentally sound and the problem is process, you stabilise what exists, introduce proper delivery discipline, freeze scope, and finish the original build. Cost to recover: usually 20-40% of the original budget in additional work and handover time. Timeline: a reset sprint of two weeks, then normal velocity resumes.
Path 2: Selective rebuild. You keep the parts that work – often authentication, data models, third-party integrations – and rebuild the parts that don’t. This is almost always cheaper than a full restart because you’re not rebuilding solved problems. Cost varies enormously depending on what’s salvageable, but budget for 40-70% of the original build cost. This is the path we take most often on distressed projects.
Path 3: Full restart with a tight MVP scope. This is the right call only when the architecture is genuinely broken at the foundation – usually when the original brief was poorly scoped and the developer made early decisions that locked in the wrong technical direction. It’s also the right call if the codebase has no test coverage, no documentation, and the person who built it is unavailable to explain decisions. Budget for a full rebuild, but scope it aggressively. The thing that broke your first build was probably over-scope, not under-capability.
Here’s the honest question to ask yourself: what, specifically, do you have that works right now? If the answer is “nothing,” the path is clearer. If the answer is “the auth system, the data pipeline, and two of the five core features,” Path 1 or 2 is almost certainly faster and cheaper.
How to Manage the Transition Without Losing More Time
The transition period – between the old arrangement ending and the new one gaining momentum – is where projects die for a second time. The knowledge transfer is underestimated every single time.
If you’re changing agencies or developers, budget two to three weeks for nothing but handover and orientation. That means the incoming team is reading code, running the app locally, asking questions, and building a picture of what exists – before they write a single new line. Any agency that tells you they can start shipping new features in week one of a takeover is either lying or about to make expensive assumptions.
The things that always get underestimated in a handover:
- Why certain decisions were made. The code shows what was built; it rarely shows why. This matters enormously for understanding constraints.
- What’s currently broken vs. not yet built. These look the same from the outside but require completely different approaches.
- Third-party integrations and their quirks. Every integration has undocumented edge cases. You only find them by talking to the person who built them or by hitting them in production.
- Environment and deployment setup. Getting a project running locally sounds trivial. On a distressed project it often takes two days.
If at all possible, overlap the outgoing and incoming teams for at least a week. Pay for it. The alternative is weeks of archaeological investigation that costs more in the end.
Resetting Scope: The Conversation Nobody Wants to Have
Once you’ve decided on a recovery path, the hardest thing you’ll do is freeze scope. Not reduce it temporarily – genuinely freeze it, in writing, for the duration of the recovery sprint.
This feels counterintuitive. You’ve lost time, you’re behind, and the natural instinct is to add the things you’ve been promised and haven’t received. Resist this. Every addition during a recovery sprint extends the timeline by more than the addition itself suggests, because the team is simultaneously recovering context, fixing problems, and trying to build forward. The cognitive overhead is real.
What a good scope freeze looks like: a written list of exactly what will be built before go-live, signed off by everyone with authority to add scope. Not a verbal agreement. Not “we’ll keep it tight.” A document. Everything else goes to a post-launch backlog, visible to everyone, with no commitment attached to it.
The founders we’ve seen recover builds successfully are the ones who treat the scope freeze as a discipline problem, not a technical one. The project didn’t fail because the developers were incompetent. It failed because someone kept changing the brief.
What Recovery Actually Costs in Australia
In rough terms, based on the builds we’ve worked on: if your original budget was $60,000 to $150,000 and the project has stalled mid-build, expect recovery to cost somewhere between $20,000 and $70,000 depending on the path you take. Full restarts with tight scope at the lower end of original budget complexity tend to land between $40,000 and $90,000. Selective rebuilds vary the most widely because they depend entirely on what’s salvageable.
These aren’t comforting numbers. But they’re real ones, and they’re almost always less than starting from scratch with a new brief and a new team who know nothing about the problem.
The founders who spend the least on recovery are the ones who act quickly when the signals appear – missed milestones, unclear status updates, backlog growing faster than it’s being cleared. If you’re reading this because you’re already in distress, the best thing you can do right now is stop, do the audit, and make a clear-eyed decision rather than a frustrated one.
If you want a second opinion on where your build actually stands, talk to Amora about your build – we’ll give you an honest read before you make any irreversible decisions.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.