Bad software is one of the most expensive things a business can own — and one of the hardest to see on a balance sheet.
It does not show up as a line item. It shows up as features that take three times longer than they should. As incidents that happen on Friday evenings. As engineers who leave after 18 months saying the codebase is unmaintainable. As customers who churn because the product is unreliable. As a growing list of things the business cannot do because the technical foundation cannot support them.
This is technical debt — and most businesses significantly underestimate what it is costing them.
What Technical Debt Actually Is
The term "technical debt" was coined as a useful metaphor: shortcuts taken in building software are like borrowed money. They let you move faster now, but they accrue interest. The longer you leave them unaddressed, the more they cost to resolve — and the more they slow down everything built on top of them.
The metaphor has a limit, though. Financial debt is visible, tracked, and has a known interest rate. Technical debt is invisible until it starts causing pain, rarely tracked with any rigour, and compounds unpredictably.
There are three types worth distinguishing:
Deliberate debt is taken on consciously: "We know this is not the right solution, but we need to ship this week. We will revisit it in Q2." This is legitimate when the trade-off is understood and the repayment is actually planned.
Accidental debt accumulates without anyone noticing: code that made sense when written but became wrong as the system grew, dependencies that were never updated, architectural decisions that were right for 100 users but wrong for 100,000.
Reckless debt is built by engineers who did not know better, were under too much pressure to care, or simply did not think about long-term consequences. This is the most expensive kind.
💡Key Insight
Most businesses have all three types. The goal is not to eliminate all technical debt — some deliberate debt is a sensible trade-off. The goal is to know what debt you are carrying, understand its cost, and have a plan for the parts that are actively slowing you down.
The Real Costs: How to See Them
Velocity Loss
The most measurable cost of bad software is delivery speed. In a healthy codebase, adding a new feature requires understanding the relevant parts of the system, writing the new code, and shipping it. In a degraded codebase, that same feature requires understanding the relevant parts of the system, navigating the unintended side effects of existing shortcuts, working around the parts that nobody wants to touch, and shipping it — after significantly more time.
Teams in debt-heavy codebases typically report that features which should take a week take three. This is not laziness or incompetence — it is the compounding interest on unresolved shortcuts.
A rough way to measure this: Ask your engineers to estimate how long a set of features would take in an ideal codebase. Compare to how long they actually took. The gap is velocity loss from technical debt.
Incident Cost
Bad software fails more. Not necessarily catastrophically — often in small, frequent ways that are individually survivable but collectively exhausting.
An incident has multiple costs. The direct engineering cost of diagnosis and resolution. The customer-facing cost of degraded experience or downtime. The on-call cost — being woken at 2 AM is not free, even if the engineer is salaried. And the opportunity cost: every hour spent fighting fires is an hour not spent building.
Businesses with significant technical debt typically run 2–4x the incident rate of those with healthier codebases. If your team is spending more than 20% of engineering time on unplanned work — incidents, urgent fixes, production firefighting — that is a signal.
Talent Attrition
This is the most underestimated cost. Good engineers do not tolerate bad codebases indefinitely. They will try to improve things, hit organisational resistance or indifference, and eventually leave for an environment where they can do their best work.
Replacing a mid-senior engineer typically costs 50–100% of their annual salary when you factor in recruiting fees, interview time, onboarding, and the productivity gap during ramp-up. Losing two or three engineers per year to a poor technical environment can cost more than the entire engineering productivity budget.
⚠️Watch Out
When engineers leave and cite "technical challenges" or "wanting to work on something newer" as their reason, they are often being polite. Run an honest exit interview process. If the codebase is driving attrition, the cost is compounding every time someone walks out the door.
Opportunity Cost
Some costs are what the business cannot do, rather than what it is spending.
An architecture that cannot support a mobile app. A data model that cannot handle the new product line. A system so tightly coupled that changing the pricing logic requires touching 40 files and risks breaking unrelated features. These are not abstract engineering concerns — they are direct constraints on business strategy.
Every time a product decision is made against the backdrop of "engineering says that would take 6 months," ask whether that estimate is genuinely about the complexity of the feature, or about the complexity of the existing system it has to be built on top of.
The Warning Signs of a Codebase in Trouble
These signals are visible to non-engineers. If several of them are present, the cost is already accumulating.
Feature delivery is slowing despite headcount growing. More engineers should mean more output. If it does not, the system itself is the bottleneck.
The same areas of the system cause most of the incidents. Every system has weaker parts, but if 80% of your incidents trace back to the same services or components, those components are carrying disproportionate debt.
Engineers are reluctant to touch certain parts of the codebase. Phrases like "nobody really understands how that works" or "we try not to change anything in that service" are red flags. Systems that are too risky to change are a liability.
Onboarding new engineers takes longer than it should. A well-structured codebase takes a new engineer 2–4 weeks to be productive in. A debt-heavy one can take 3–6 months, and some engineers never fully get there.
Testing is sparse or unreliable. A codebase without meaningful test coverage cannot be changed confidently. Every change becomes a risk, which slows everything down and makes engineers hesitant.
★Remember This
These signals are lagging indicators — they appear after the debt has already accumulated. If you are seeing two or more of them consistently, the cost is real and growing.
How to Start Fixing It
The instinct when confronted with significant technical debt is often to propose a full rewrite. Resist this instinct. Full rewrites are expensive, slow, and risky — and they often reproduce the same problems in a new codebase because the underlying organisational behaviours have not changed.
The more effective approach is targeted, continuous improvement alongside delivery.
The Strangler Fig Pattern
Rather than replacing a broken system all at once, build the replacement incrementally alongside it. New functionality is built in the new, clean architecture. Existing functionality is migrated piece by piece as it is touched. Over 12–18 months, the old system is strangled — replaced from the outside in while the business continues running.
This approach reduces risk significantly: the old system remains in place as fallback until the new one has proven itself in production.
The Boy Scout Rule
Leave every part of the codebase you touch slightly better than you found it. Fix the variable name that confused you. Add the test that would have caught the bug you just fixed. Remove the dead code path you noticed while debugging. This does not solve large structural problems, but it prevents the codebase from getting worse and gradually improves the parts that see frequent change.
Debt Sprints
Dedicate one sprint in every four — or one day per week, depending on your cadence — specifically to technical debt reduction. Not bug fixes, not features — structural improvements, test coverage, documentation, and architectural work that does not ship directly to users.
→Practical Tip
Frame debt reduction work in business terms, not engineering terms. "Reduce incident rate in the payments service by 60%" is a business outcome. "Refactor the payments service" is an engineering task. Stakeholders fund outcomes, not tasks.
Prevent New Debt From Accumulating
Addressing existing debt while taking on new debt at the same rate is a treadmill. The habits that prevent accumulation:
- Code review standards that flag shortcuts before they merge
- Architectural decision records that document why choices were made, so context is not lost
- A "definition of done" that includes tests and documentation, not just working code
- Engineering time protected for debt work — not just promised and then cancelled when a deadline looms
The Business Case for Investing in Quality
Engineering leadership often struggles to make the case for technical investment to non-technical stakeholders. The instinct on the business side is that investing in "cleaning up" is engineering self-indulgence — something engineers want but that does not create business value.
This framing is wrong, but it is understandable. The way to counter it is with numbers.
Calculate what your current delivery velocity actually is. Calculate what it would be with a healthier codebase — engineer estimates are typically reliable here. Calculate the value of shipping features faster. Calculate your incident rate and the cost of those incidents. Add the cost of the attrition you are experiencing or risk experiencing.
The business case for addressing technical debt is almost always compelling once it is expressed in these terms. The challenge is making the invisible visible — translating engineering concerns into business consequences that stakeholders can evaluate.
★The Bottom Line
Technical debt is not an engineering problem that occasionally surfaces as a business inconvenience. It is a business liability that happens to live in the codebase. Treating it as such — with the same rigour you would apply to any other significant business risk — is the starting point for getting it under control.
If your team is struggling with a codebase that is slowing delivery, driving incidents, or making it hard to retain good engineers, let's talk. An independent technical review can give you a clear picture of what you are carrying and a prioritised path forward.