Most stalled projects don't fail for technical reasons. They fail because nobody was honest early enough. Here is how to tell the difference between a project worth saving and one that should be stopped.
Most stalled software projects don't fail because the technology is too hard. They fail because nobody with enough experience said the difficult thing early enough. Recovery is possible in many cases — but knowing when to stop is just as important as knowing how to fix.
The honest version of project recovery
When a client comes to us with a stalled project, the first thing we do is triage — not fix. We look at the codebase, talk to the team, review the original scope, and try to understand what actually went wrong.
More than half the time, the technical problems are symptoms, not causes. The real failure was upstream: unclear requirements, changing scope, the wrong team for the job, or no senior technical oversight while critical architectural decisions were being made by developers who were not equipped to make them.
Understanding the root cause matters enormously. If you fix the symptoms without addressing the cause, the same project will fail again — just more expensively the second time.
The four failure modes we see most often
The project started with a clear brief and expanded in ten different directions without a formal change request process. The codebase reflects this: tangled, inconsistent, and impossible to estimate.
Junior developers doing senior architecture work. Developers making product decisions they should not be making. No one accountable for the quality of what is being built.
The previous developer left and took all the context with them. Nobody knows what the codebase does, what the dependencies are, or what was deliberately left unfinished versus accidentally broken.
The business keeps investing because stopping feels like admitting failure. But every month of investment in the wrong foundation makes the eventual rebuild more expensive, not less.
Recovery, partial rebuild, or stop
When we complete a triage, we present three options honestly:
Fix it: The architecture is sound, the problems are identifiable, and recovery is faster and cheaper than rebuilding. This applies to roughly 30% of the projects we assess.
Partial rebuild: Some components are salvageable. The data layer might be fine but the frontend is a write-off, or vice versa. Selectively rebuilding while preserving the stable parts is often the most practical and cost-effective approach.
Stop and redirect the budget: The codebase is not recoverable at a reasonable cost. The architecture choices made early have compounded into a structure that cannot be corrected incrementally. Continuing to invest in it is throwing good money after bad.
"The most valuable thing we can tell a client is sometimes not what they want to hear. A project that should be stopped is better stopped at R50,000 than at R500,000."
The question that changes everything
The most important question in project recovery is not can this be fixed — it is what does it cost to fix it versus rebuild it, and how does that compare to the value the system delivers?
We have seen clients spend R400,000 trying to fix a system that could have been rebuilt for R120,000. We have also seen clients want to rebuild systems that needed only R30,000 in targeted work. Both errors are expensive. Both are avoidable with a clear-eyed assessment.
What we actually do in a triage
Our Technology Recovery Advisory engagements start with a fixed-fee triage — Emergency (2 days, R15,000) or Standard (5 days, R35,000). Within that time, we:
- Review the full codebase for architecture, quality, and maintainability (following a structured technical due diligence approach)
- Interview the development team (or review handover documents if the team has left)
- Map the gap between what was promised and what was delivered
- Identify the root causes of failure — not just the symptoms
- Present three clear options with honest cost and timeline estimates for each
We do not guarantee recovery. What we guarantee is clarity. At the end of the engagement, you know exactly what you are dealing with, what your options are, and what the right decision looks like — even if it is the uncomfortable one.
Written by gigtech
gigtech is a software consulting and product development firm with 20+ years of hands-on engineering experience. We help businesses make better technical decisions, reduce costs, and build systems that last.
About gigtech ›