[Table of contents]Show table of contents
Tech debt is like a mortgage: manageable in small doses, fatal when you ignore the interest. Most companies don’t even know their monthly payment. No technical balance sheet, no interest calculation, no repayment plan. They find out the scale on a Friday at 5 PM, when the system goes down and nobody can bring it back up.
At Do More Soft we’ve run rescue missions for five years — saving projects others abandoned. We’ve seen every level of debt, from cosmetic to terminal. Below is the framework that tells you plainly: save it, or rewrite it from scratch in 8 weeks.
5 levels of technical debt
Every level carries an operational consequence — not theoretical, measurable in sprints.
- Cosmetic — inconsistent naming, missing comments. 10-20% slower, but no prod fires.
- Structural — no layer separation, no tests. A feature takes 3x longer, regression every sprint.
- Architectural — monolith with no API, database as integration point. Every integration is a quarter-long project.
- Infrastructural — zero CI/CD, manual FTP deploys. Friday deploy = Russian roulette.
- Terminal — dead technology, zero tests, original team gone. 80% of the IT budget on maintenance, development effectively frozen.
Level 1: Cosmetic
Suboptimal SQL queries, duplication, missing comments. The system works correctly, it is just unpleasant to maintain. Fix: refactor inside normal sprints, no dedicated budget. Every project has this level, and that is fine.
Level 2: Structural
UI tangled with business logic, no tests, hardcoded config. The system works, but every change requires modifications in 5 places and produces regressions. Fix: a dedicated refactoring sprint every 4-6 weeks.
Level 3: Architectural
A monolith that won’t scale. The database as an integration point — systems talk through a shared schema. Zero API, zero integrations. New features take 3-5x longer. Fix: extract critical modules into separate services, add an API layer. 2-4 months of work.
Level 4: Infrastructural
No CI/CD, FTP deploys, production on a single server with no backup, zero monitoring. The system runs on “nobody touch this.” Catastrophic failure risk plus total dependency on the one person who “knows how it works.” Fix: build infrastructure from scratch alongside the running system — swapping an engine in a moving car. 1-3 months.
Level 5: Terminal
Classic ASP, AngularJS, PHP 5. Zero tests, zero documentation, original team gone. Every change produces unpredictable side effects. Nobody understands the system as a whole. Maintenance eats 80%+ of the IT budget. Binary decision: save it or rewrite it.
Rescue Assessment Matrix — when to save vs. rewrite
We’ve run this 30+ times. Three of five dimensions at 3+? Save it. Three at 1-2? Rewrite wins. When a client comes in with a project “to be rescued,” we run a 3-5 day technology audit and score 5 dimensions on a 1-5 scale (1 = scrap, 5 = solid): database quality, test coverage, API design, infrastructure, documentation.
Decision rule
Three of five dimensions at 3+ — rescue mission. We save what is good and rewrite what is broken. Typical cost: 40-60% of a full rewrite budget, timeline: 2-4 months. Three dimensions at 1-2 — rewrite from scratch. Saving it would cost more than a new system and produce a worse result. The database is the lever: if the data is well-designed, the rest is recoverable.
In an automotive project: database solid (5/5), API legacy (1/5), tests zero (1/5). Saved, because 2 of 5 were worth saving — database and frontend. We wrote the API and tests from scratch in 14 weeks, the client kept the data and the processes.
The real TCO of ignoring debt
Companies that ignore debt pay interest across every TCO axis: slower time-to-market (competitors pull ahead), 90% of the IT budget on maintenance instead of growth, key-person dependency (one developer leaving paralyzes the project), catastrophic failure risk.
The most expensive line item in tech-debt TCO is the cost of missed opportunities. A company that could ship a product in 3 months ships it in 12 — because 75% of team capacity is consumed by fighting debt. The competition takes the market in the meantime. That cost is invisible on the balance sheet and painful in the quarterly results.
Rescue playbook: a rescue mission step by step
Week 1: Audit and stabilization. Critical security gaps, monitoring, backup, as-is architecture documentation.
Weeks 2-4: Priority refactoring. We separate core logic from UI, write tests for critical paths, ship a CI/CD pipeline.
Months 2-3: Modernization. New API, infrastructure migration, dead-code elimination.
Month 4+: Development. New features on a solid foundation.
The 20% rule
Friday sprint at DailyHair: 2h refactor, 1h docs, 30min test coverage. Not optional. This is the pattern we enforce with every client that has an engineering culture.
Why it works — compounding effect
20% of every sprint capacity goes to debt repayment. 20% today saves 200% next year, because every unfixed shortcut blocks the next architectural decision. A team that pays down debt regularly is faster and writes better code. The client pays for it twice: once in lower maintenance cost, again in higher feature throughput.
How to enforce it — spike card, non-negotiable backlog
A “Tech Debt 20%” spike card in every sprint backlog, prioritized alongside features, not after them. Definition of Done identical to a business story. No spike → the sprint doesn’t start. For companies without an engineering culture: one Friday a month dedicated to cleanup (“Tech Debt Fridays”). This is an investment in future productivity, not a loss.
We do this ourselves
Q2 2026, velocity 45 SP. 9 points on Friday tech debt, 36 on features. On every new engagement we show the client the debt counter from the previous system — that usually ends the discussion about whether 20% is “really necessary.”
FAQ
What is technical debt and how do you measure it? Percentage of the IT budget consumed by maintenance instead of growth. Above 70% → red flag.
When to refactor vs. rewrite? Rescue Matrix, 5 dimensions × 1-5 scale. Three at 3+ → rescue (40-60% of rewrite cost). Three at 1-2 → rewrite.
What is the 20% rule? 20% of sprint capacity for debt repayment, spike card in the backlog, not “if there is time left.”
How much does tech debt cost a company? 60-90% of the IT budget on maintenance. The most expensive line item is the cost of missed opportunities.