The first question in a software rescue is not “how bad is the code?” It is “is this product economically worth saving?” Code condition, accumulated business knowledge, replacement cost, revenue importance, and available senior engineering capacity decide that together. Across individual rescues, we have seen meaningful reuse range from roughly 5 to 10 percent to around 70 percent. That is evidence of variability, not a benchmark.
On this page
What the first 48 hours actually are
We’ll be straight about this: our first 48 hours with a broken build are not a branded framework. They are a practical assessment of what exists, what actually works versus what the founder believes works, and what the fastest path to a working product is. Everything sorts into three buckets: what can be fixed, what should be rebuilt, and what may not need to exist at all. The goal is not to prove the previous work can be saved. It is to get you to a working product in the most sensible way.
The economics come first
One rescue taught us this permanently. The product was salvageable on paper; the economics were not. The rescue would have consumed senior engineering capacity that the engagement’s budget couldn’t carry, and proceeding anyway would have failed slowly instead of failing honestly. Rescue viability is a resourcing question as much as a code question, and any rescuer who quotes before understanding revenue, users, replacement cost, and available budget is diagnosing without the full picture.
What actually survives, with real numbers
On one platform we took over, roughly 5 to 10 percent of the original codebase, if that, remained in meaningful use; the auth layer alone needed such fundamental work that rebuilding beat reworking. In more favorable refactoring situations we have retained around 70 percent. The variable is the original architecture and how much the product needs to change, which is why we publish the range and refuse to publish an average.
The idea that changes the math
A rebuild starts at zero technically. It never starts at zero intellectually. When a team already understands the first version, its users, and its failure history, the second build moves at a completely different speed. We rebuilt the third version of one of our own products, at least 80 percent improved, in roughly two and a half months, and the biggest accelerant was not AI. It was accumulated knowledge of two operated versions. This is why “rebuild” is not the catastrophe founders fear, and why the fastest rescues often rebuild the core and keep the learning.
When repair genuinely wins
Enterprise-scale systems with years of embedded business rules often make a full rebuild difficult; staged modernization can be the safer path. And some rescues end with “keep it”: one AI-built app we assessed for a planned rebuild turned out to be good enough to launch, and we maintain it today instead. Anyone who quotes a rebuild before assessing is selling, not diagnosing.
What the assessment produces, concretely
The output of the first pass is not a feeling; it is three lists and a recommendation. The keep list: components that work, tested against what the founder believes works, which are frequently different lists. The rebuild list: pieces where rework costs more than replacement, with the auth-layer example above as the archetype. The kill list: features that may not need to exist at all, which founders consistently underestimate; scope that was wrong to build is wrong to rescue too. The recommendation then prices both paths against the product’s economics, and it is delivered in writing with the reasoning attached, because a rescue decision you cannot explain to your cofounder is not a decision yet.
The decision list
Ask, in order: does the product have revenue or users worth protecting; what would a clean replacement cost against repair; who actually understands the current system; what share of the code is actually worth preserving; and do you have access to senior capacity for either path. Answer those and the technical decision mostly makes itself.
How much does a software rescue cost?
It prices from the assessment, not from the code volume: what survives, what rebuilds, and what dies determine the number. The assessment itself is a small fraction of any path it recommends.
Can you rescue an app another agency abandoned?
Usually, and abandonment is often better news than it feels: the economics get evaluated fresh, without anyone defending prior decisions.
How long does the assessment take?
The first pass runs in days, not weeks; the three-bucket sort and the written recommendation follow directly from it.
Have a build that stalled or a product you’re not sure deserves rescue? Send it over; the honest answer is sometimes “don’t save it,” and we’ll tell you that too.
Work with us
