Software teams face a familiar choice: keep patching a system that’s slowing everyone down, or scrap it and start over. The decision affects more than this quarter’s roadmap. It decides how much capital is left for everything else.
Most teams reach for the second option, because it feels more decisive. It’s usually the expensive one.
Technical debt now runs 21% to 40% of an organization’s IT spending, according to Deloitte’s 2026 Global Technology Leadership Study. A fifth to two-fifths of the technology budget is spent servicing code nobody chose to write that way on purpose.
Here in Brocoders, we’ve spent the past several years auditing, stabilizing, and selectively rebuilding software for companies stuck in exactly this position. The pattern holds every time. Teams overspend when they treat every piece of debt the same way, usually defaulting to a full rebuild whether the situation calls for one or not.
A four-tier model for deciding what to keep, fix, or rebuild
Consider a founder who inherited a platform from a previous team: no documentation, a shrinking runway, and a board asking whether to cut losses and start over. The instinct is to scrap it. That instinct is rarely the cheapest one.
The same discipline that works for physical assets works for code. Impakter has made this case for material recovery: you don’t landfill a warehouse of returned inventory, you grade it, redeploy what’s still sellable, and reserve disposal for what’s genuinely unsalvageable. Software debt recovery runs on the same logic, in four tiers.
McKinsey puts technical debt at 20% to 40% of an organization’s technology estate value, with 10% to 20% added to the cost of every project layered on top of it. The debt isn’t spread evenly either. McKinsey found that ten to fifteen assets usually account for most of it, which is exactly why tier one starts with an audit, not a rewrite.
Tier 1: Audit and redeploy
Find out what already works before you touch anything. When we audited HeyPractice’s telehealth platform, the verdict was to keep the database schema, keep the models and migrations, and rewrite the application layer around them. The data model held up; only the surface needed to change.
Tier 2: Stabilize
Make the system safe to touch before you change what it does. That means reproducible builds, a real CI/CD pipeline, and monitoring that flags what broke before a customer does. Skip this tier and every tier after it gets riskier, because you’re building on ground that still shifts underneath you.
Tier 3: Decompose
Extract and replace piece by piece while the product keeps running. For Lake, a vacation rental marketplace, that meant rebuilding a straining monolith in three months while the site stayed live. Connected properties went from roughly 500 to 40,000, an 80x increase, alongside a 210% spike in site activity, and the content pages stayed untouched so the site kept its organic search rankings throughout.
Tier 4: Rebuild, as a last resort
Some codebases genuinely can’t be saved. CoreHealth inherited a telehealth platform from a previous contractor with no salvageable core: undocumented, brittle, built on choices nobody could explain. We rewrote it in six weeks with a five person team, and it has since grown into three separate products.
Where to start: a checklist for your first 30 days
You don’t need the full model running on day one. You need to know where you stand.
- Inventory what’s actually running. List every service, script, and integration in production, not just what’s documented.
- Grade each piece against the four tiers: still working, needs stabilizing, needs decomposing, or beyond saving.
- Pick one module to test the model on. Not the whole system, one piece you can ship a decision on within weeks.
- Set your rebuild threshold now, before a deadline forces the call. Decide in advance what “unsalvageable” means for your business: an unmaintained dependency, a security gap, a cost of ownership higher than starting fresh.
Why teams skip straight to tier four anyway
A full rewrite feels like progress. An audit feels like more waiting, and boards rarely reward waiting.
That’s the trap. The tier that costs the most is the one you reach for without first checking whether you needed it.
Redeploy what works, stabilize what’s shaky, decompose what’s straining, and reserve a rebuild for what’s actually unsalvageable. That order is what keeps the recovery model paying for itself, instead of becoming one more rewrite nobody budgeted for.
Frequently asked questions
What is technical debt, in plain terms? It’s the gap between the fastest way to ship something and the way it should have been built. Every shortcut adds interest: more time to change later, more risk when you do.
How do I know if code is worth keeping or should be rebuilt? Run an audit before deciding either way. If the core logic and data model hold up and only the surface is the problem, redeploy it. If the foundation itself is broken, rebuilding is usually cheaper than untangling it piece by piece.
What does a technical audit actually check? A real audit maps the architecture, traces dependencies, reviews security and data handling, checks test coverage, and ends with a specific recommendation: keep, stabilize, decompose, or rebuild.
Is rebuilding from scratch ever the right call? Yes. When a codebase has no salvageable core, as with CoreHealth’s inherited platform, rebuilding inside a defined window beats patching something that was broken by design.
How much does unresolved technical debt actually cost a business? Deloitte puts it at 21% to 40% of IT spending. McKinsey adds 10% to 20% to the cost of every new project built on top of it. Left alone, the number only grows.
Editor’s Note: The opinions expressed here by the authors are their own, not those of impakter.com
