A manufacturing company deployed an AI-generated dashboard connected to live production floor data. At first it worked. Then the inconsistencies started. Leadership could not explain to the board what had been built or why it was failing. The developer who built it was no longer around.
The instinct in that moment is usually to fix the project; bring someone in, stabilize what exists, keep moving. We see that instinct a lot. And fairly often, it's the wrong call.
We started with a technical audit. The audit showed that almost no code was reusable. We rebuilt. 90 days later the system was stable and in production.
This comes up more than people expect. AI prototypes that made it to production before they were ready, custom builds that stalled, offshore projects that were abandoned mid-flight. The rescue-or-rebuild question is the same in all of them. It needs honest data.
Why the Default Answer Is Usually Wrong
Two patterns show up consistently when a project fails.
The first is reflexive rescue. Significant capital has already been spent. Leadership doesn't want to write it off. A new vendor comes in, recommends salvaging the work, and the project continues. Eighteen months later, the same structural problems resurface under a new layer of patched code.
The second is reflexive rebuild. A new technical lead arrives, reviews the codebase, and concludes it is unsalvageable. A full rebuild is scoped and approved. Two years later, the organization has a new system built on requirements that were never properly validated the first time.
Both failures share the same root cause: the decision was made before a structured assessment produced the data needed to make it. The Standish Group's research shows that projects entering recovery phases without a proper diagnostic are significantly more likely to fail again regardless of which path is chosen.
The model is rarely the problem. What breaks is the infrastructure, the data quality, and the process the system was asked to support before anyone had a solid engineering plan.
The Five Criteria That Drive the Decision
A credible assessment looks at five variables. Any one of them can shift the recommendation. A project with a salvageable codebase may still warrant a rebuild if data migration complexity is prohibitive. A project with serious technical debt may still be rescuable if timeline pressure makes a rebuild untenable.
1. Codebase salvageability
This is the most visible input but frequently the least decisive. The question isn't whether the code is clean. It's whether the architecture can support the intended functionality without fundamental restructuring. A messy codebase built on a coherent pattern is rescuable. A clean-looking codebase built on a flawed data model is not.
2. Team knowledge retention
Custom software carries undocumented knowledge: why specific decisions were made, where edge cases live, which integrations are fragile. When the original team is gone, that knowledge goes with them. Rescue work in that scenario means rebuilding institutional understanding of a system that may be poorly documented and that narrows the cost gap between rescue and rebuild quickly.
3. Timeline pressure
Rebuild timelines for mid-market software are a multi month effort If there's a hard external deadline, a regulatory requirement, or a board commitment within that window, rebuild is off the table regardless of codebase quality.
Timeline pressure also constrains rescue scope. An eight-to-twelve week window limits what can be fixed and what has to be deferred.
4. Data migration complexity
This one gets underweighted more than any other. A rebuild requires migrating existing data into a new schema. If the legacy system's data is inconsistent, undocumented, or spread across disconnected sources, that migration can add months and significant cost. In some cases, data complexity alone makes rescue the more economical path even when the codebase is in rough shape.
5. Cost trajectory of the current system
What is the broken system costing every month it keeps running? Vendor support, staff workarounds, error correction, operational drag can all compound. If the cost trajectory is high and accelerating, it changes the math on both sides of the decision.
The Conflict of Interest Problem
The most common way organizations make this decision is to ask vendors to assess the situation. That is a structurally flawed process.
A rescue-capable vendor has an incentive to recommend rescue. A vendor that specializes in new builds has an incentive to recommend rebuild. The organization ends up choosing between two proposals rather than evaluating an objective assessment.
The more reliable approach is a paid diagnostic engagement scoped specifically to produce the assessment data before any build work begins. The deliverable is not a proposal for more work. It is a documented evaluation of the five criteria above, with a recommendation and the reasoning behind it.
In our experience with mid-market organizations across Canada, this type of assessment typically runs three to four weeks. It produces the concrete documentation needed to make a concrete decision.
What a Credible Rescue Engagement Looks Like
If the assessment points to rescue, the first thirty days define whether recovery is achievable. We have done this across a range of situations including a physical security information management software company whose MVP had broken backend architecture and could not be deployed. The vendor that built it was no longer involved. The system existed but did not work.
We audited it, determined the core structure was salvageable, fixed the backend, optimized for scalability, and delivered a production-ready system. Three things made that possible.
Stabilization before improvement
The first priority is finding the failure modes that are actively causing the most operational damage and addressing those before anything else. Rescue projects that attempt broad improvements in the first month routinely create new instability while fixing old problems. In that engagement, we started by understanding exactly where and why it was breaking.
Documentation of the current state
Before any significant changes are made, the incoming team needs a clear map of what exists: architecture, data flows, integration points, known failure modes. Without that baseline, rescue work produces a system the new team understands no better than the original team did.]
A defined scope boundary
Rescue engagements expand. The codebase always contains more problems than the initial audit surfaces, and there is always pressure to fix them while the team is already inside the system. A defined scope boundary with a formal change process is the only reliable way to prevent a rescue from becoming an uncontrolled rebuild by accumulation.
When Rebuild Is the Right Call
Rebuild is appropriate in three scenarios we see consistently.
The first is a fundamental architecture mismatch. The system was built for a different scale, a different user model, or a different integration environment than it now needs to serve. No amount of rescue work resolves this because the problem is structural, not executionial.
The second is accumulated technical debt past the point of return. When every feature addition requires significant rework of surrounding code, and that pattern has held for eighteen months or more, the rescue cost trajectory will eventually exceed the rebuild cost.
The third is undocumented legacy code with no available authors. Without documentation and without the original developers, rescue means reverse-engineering a system that may be deeply idiosyncratic. The knowledge reconstruction cost narrows the gap between rescue and rebuild to the point where starting fresh is often faster.
Two engagements illustrate this clearly.
A manufacturing company deployed an AI-generated dashboard connected to live production data. Outputs became inconsistent. Leadership could not explain the system to the board. The developer was gone. The audit showed that almost no code was reusable, but the prototype had done something valuable. It had clarified scope, surfaced the key workflows, and documented the business logic the client needed. That made the rebuild faster and more accurate than starting from nothing. 90 days from the audit, the rebuilt system was stable and in production.
A legal tech startup building an AI platform for court form completion had a similar situation. Their early prototype showed real promise at 35% accuracy. It was a solid proof of concept, but nowhere near reliable enough for live filings. The underlying approach was sound; the implementation needed a complete rebuild. We rebuilt the pipeline from the ground up: categorized over 1,500 document types, redesigned the data mapping workflow, and developed a process for handling unlabeled form fields. Seven weeks later, accuracy was at 93% and 90% of required fields were being filled correctly.
An AI prototype that cannot go to production is not wasted work. It is a discovery artifact. The mistake is treating it as a production system before it has been validated as one.
Start With the Assessment, Not the Answer
The rescue-or-rebuild decision warrants an independent evaluation. Codebase quality, data migration scope, timeline constraints, cost trajectory all need to be audited before any build work begins.
That is what TTT Studios' UX and Technical Audit process is designed to produce. For organizations in a project recovery situation, Discovery maps the current state, identifies what is salvageable and what is not, and delivers a recommendation with documented rationale. The organization gets a basis for decision-making that does not depend on trusting the vendor pitch.
If your project is in trouble and you are weighing the options, Discovery is the right starting point.
Sources
Standish Group. CHAOS Report: Software Project Outcomes. 2022. standishgroup.com
