McKinsey published a number that should scare every CTO: the CIOs it surveyed estimated that technical debt amounts to 20-40% of the value of their entire technology estate. Not 20-40% of the IT budget. Of the entire technology estate: the accumulated value of every system, platform, and tool the company has built or bought.
In a 2025 report, CAST Software analyzed more than 10 billion lines of code from 47,000 applications and estimated 61 billion workdays of global repair time for accumulated technical debt. That is not a typo. Billion.
I have run an engineering studio for 11 years. We inherit codebases with technical debt. We also create technical debt, because every engineering team does. The question is not whether you have debt. It is whether you manage it or let it compound.
What Technical Debt Actually Is
Technical debt is not bad code. Bad code is just bad code.
Technical debt is the accumulation of shortcuts, deferred decisions, and aging dependencies that slow down future development. It is the decision to skip writing tests because the deadline was tight. The framework you chose in 2017 that reached end-of-life in 2021. The database schema that made sense for 100 users but breaks at 10,000. The API design that worked for one client but cannot support three.
Every one of these decisions was rational at the time. Ship fast, fix later. The problem is that "later" compounds. Each shortcut makes the next feature take longer. Each deferred upgrade makes the eventual migration more expensive. Each missing test makes every deployment riskier.
The Numbers
McKinsey (2020): The 50 CIOs it surveyed, at financial-services and technology companies with revenues over $1 billion, estimated tech debt at 20 to 40 percent of the value of their entire technology estate. In McKinsey's survey, CIOs also reported that 10 to 20 percent of the technology budget for new products is diverted to resolving tech debt issues.
CAST Software: Average technical debt of $3.61 per line of code, from 1,400 applications and 550 million lines. The figure is not new: InfoWorld reported it from a CAST study in December 2011. For a 500,000-line application (medium SaaS product), that is $1.8 million in embedded debt.
Stripe Developer Coefficient (2018): Developers surveyed estimated that maintenance takes 17.3 hours of a 41.1-hour week, about 42%. Stripe's chart of the work week puts 13.5 of those hours under technical debt and 3.8 under bad code. That means for every 2 developers you hire, you effectively lose almost 1 to maintenance.
How It Happens
I have seen the same pattern across dozens of client engagements:
Year 1: Ship fast. Framework choice is good. Architecture is simple and appropriate. Tests are sparse but the team knows the code. Debt is low.
Year 2-3: Team grows. New engineers do not understand the original decisions. Features are bolted on. The test suite is inconsistent. The original framework releases a major version but nobody has time to upgrade. Debt accumulates.
Year 4-5: The framework is now 2 major versions behind. Dependencies have security vulnerabilities. The database schema has been patched 50 times. New features take 3x longer than they should because every change touches fragile code. Hiring is hard because good engineers do not want to work in legacy stacks.
Year 6+: The CTO starts talking about a rewrite. The CEO asks why the team is slow. The answer is technical debt, but it is invisible to everyone except the engineers.
What To Do About It
Allocate 15-20% of every sprint
Not a "tech debt sprint" once a quarter. A consistent allocation every cycle. 15-20% of engineering capacity goes to debt reduction: upgrading dependencies, improving test coverage, refactoring the ugliest module, migrating off deprecated APIs.
This is not a tax on velocity. It protects velocity. The teams that skip debt reduction for 6 months to "ship faster" end up slower by month 9 because every feature fights the accumulated shortcuts.
Prioritize by business impact
Not all debt is equal. A deprecated logging library is annoying but not blocking. A database query that scans 10 million rows on every page load is an emergency. An authentication module with a known vulnerability is a liability.
Rank debt by: business impact (does it affect users, revenue, or security?), blast radius (how many features touch this code?), and migration difficulty (is this a 2-hour fix or a 2-month project?). Fix the high-impact, low-difficulty items first.
Migrate incrementally
The full rewrite is almost always a mistake. You spend 12 months rebuilding a system that already works, during which no new features ship, and when you launch the rewrite, you discover it has its own bugs.
Our legacy migrations don't get rewrites. They get incremental migrations: we refactor module by module, replace legacy framework patterns with Laravel equivalents, and ship each module to production independently. The platform never goes down. Features keep shipping during the migration.
Greek House followed the same pattern. The previous team had a large codebase with accumulated debt. We did not rewrite it. We refactored it to Laravel and React best practices, set up CI/CD, and started shipping same-day releases. The platform went from stalled releases every few months to daily deployments.
Measure it
You cannot manage what you cannot see. Track: deployment frequency (are you shipping faster or slower over time?), lead time for changes (how long from commit to production?), defect rate (are bugs increasing?), and developer survey scores (is the team frustrated with the codebase?).
If deployment frequency is declining and lead time is increasing, you have a debt problem. The numbers do not lie.
The definitional piece that anchors all of this: what an MVP in software actually means. And if you're scoping a build, our development services show how we take products from spec to shipped.
The Business Case
Technical debt is invisible to the business until it is not. The moment a competitor ships a feature in 2 weeks that takes your team 3 months, the debt becomes visible. The moment a security breach happens because a dependency was not updated, the debt becomes expensive. The moment your best engineer quits because they are tired of fighting legacy code, the debt becomes a retention problem.
McKinsey's 10 to 20 percent is not an abstract number. It is budget for new products that CIOs reported as diverted to resolving tech debt. Stripe's 17.3 hours is an estimate, and it is the developers' own: the time they say is wasted on maintenance every week.
The fix is not dramatic. It is disciplined: 15-20% allocation every sprint, prioritized by business impact, measured over time. The teams that do this ship faster, retain engineers longer, and pass technical due diligence when the exit comes.
We build software that lasts. HeyTutor: 9 years, no major rewrites. MyFlyRight: 10 years, architecture decisions from year 1 still holding. That is what managing technical debt looks like in practice.
Last updated November 12, 2026