The loan you did not know your software took out
Every piece of custom software your business runs on carries a balance you cannot see on any invoice.
Technical debt is the accumulated future cost of building software the fast or cheap way now instead of the sound way. When a shortcut is taken to hit a deadline or trim a budget, that saving does not vanish. It gets recorded against the code, and the business pays it back later, usually with something added on top. That is the whole meaning of the term, and it holds up because the debt metaphor has three moving parts you already understand from money.
The principal is the shortcut itself: the time or money saved at the moment the decision was made. The interest is the extra cost you pay on every future change to that rushed code, because each new feature or fix now has to work around the corner that was cut. Compounding is why this matters: an ignored problem does not sit still. The awkward code gets built on, worked around, and copied, so the cost of leaving it grows at an accelerating rate. Left long enough, this becomes code rot, where a system nobody has tended slowly turns brittle.
The model in three parts. Principal: the shortcut taken, and what it saved at the time. Interest: the extra cost paid on every future change to that code. Compounding: why an ignored problem gets worse at an accelerating rate rather than staying still.
Ward Cunningham coined the phrase in 1992, specifically to explain rework to non-technical colleagues, which is exactly why it is the right lens for an owner rather than an engineer. This page covers how to spot the symptoms, when taking on debt is a sensible choice, how to talk about it with your developer, and how paying it down actually works.
How Technical Debt Shows Up in Your Business
You will rarely hear the words "technical debt" from the people it affects, because debt is not something your developers tend to announce. You feel it first as friction. Work that used to be quick starts to drag, and the tone of your conversations with whoever writes your code shifts in ways that are easy to notice once you know what to look for. None of the signs below is dramatic on its own; together they are that interest made visible.
The clearest technical debt examples are the ones that live in your own workflow. Consider a change to how an order is priced. It should be one edit. Instead it touches six places, because a launch-week quick fix hard-wired the pricing logic into a single screen, and that screen was later copied whenever a new one was needed. Every workaround like this makes the next change slower, so your developers' pace falls while your spend stays flat: you commissioned no less work, yet less of it gets done. Stripe's 2018 Developer Coefficient report found engineers spend roughly a third of their time dealing with technical debt and maintenance. McKinsey's 2020 report, "Tech debt: Reclaiming tech equity", frames paying it down as recovering equity you already own rather than pure cost.
Technical Debt Is Not Always a Mistake
Not every shortcut was a failure of discipline. Some technical debt is a deliberate, correct commercial choice: shipping fast to hit a funding window or a seasonal deadline, or validating an idea with a minimum viable product before you commit to building it properly. If that shortcut bought you the market evidence to justify the real investment, it was cheap at the price. This is the same speed-versus-ownership judgement behind any build-versus-buy decision. Martin Fowler's Technical Debt Quadrant turns that judgement into a tool you can use on your own history. Ask two questions of any past shortcut: was it taken on deliberately or did it creep in inadvertently, and was the choice prudent (eyes open, planned to repay) or reckless (no thought given).
Reckless and deliberate
"We do not have time to do it properly, ever." The shortcut quietly becomes the permanent design.
Prudent and deliberate
"We ship now and accept the rework cost." Eyes open, with a plan and a date to pay it back.
Prudent and inadvertent
"Now we understand the domain, we would design this differently." The first version was sound for what you knew then.
Reckless and inadvertent
Nobody realised what good looked like, so shortcuts accumulated without anyone deciding to take them on.
Steve McConnell observed that technical debt is "less visible" to business staff than most liabilities, which is exactly why owners need a framing like this. People also sort debt into code, design, test and documentation types, and blame deadlines, changing requirements, skill gaps or skipped testing, but the distinction that changes your decisions is deliberate versus accidental.
How to Talk to Your Developer About Technical Debt
When a developer or agency tells you the code is a mess and needs refactoring, they are usually doing you a favour. Raising debt out loud is an invitation to decide together, not a confession to be picked apart. Meet it that way, and ask four plain things: what specifically slows down because of this, what it costs to leave the code as it is, what it costs to fix, and what happens if you wait six months.
Refactoring: improving the internal structure of the code without changing what the software does for the user. It buys cheaper changes later and fewer bugs.
The common objection is that this feels like paying twice for a feature you already own. It is not. Refactoring pays down the principal so you stop paying the interest that every future change is quietly charged.
Read the answers for what they connect to. A genuine need points at a business outcome; perfectionism points only at taste. Both are honest, but only one is urgent.
Key-Person Dependence Lowers What Your Business Is Worth
Developers call it the bus factor: the number of people who could be hit by a bus before a system becomes unmaintainable. When only one developer or agency understands how your software fits together, that number is one. Undocumented knowledge is technical debt in its purest form, a shortcut someone took on documentation and handover, and the interest is paid by everyone who comes after.
Concentration risk: a system only one person can maintain is a single point of failure dressed up as convenience. It runs fine until the day it does not.
While that person stays healthy, engaged and on good terms with you, nothing feels wrong. An illness, a resignation or a dispute over fees then stops being an inconvenience and becomes an existential problem for the systems your business depends on daily. The same weakness resurfaces when you come to sell. A buyer's due diligence will price in the risk of software nobody but one person can maintain, and tangled, undocumented legacy code stops being a technical worry and becomes a balance-sheet one. The way out is deliberate: document what exists and consider bringing in a fresh team to take over the existing system before circumstances force the decision for you.
A Full Rewrite Is the Most Expensive Route, Not the Safest
When a system feels beyond saving, "just rebuild it" carries a certain relief. A clean start sounds like certainty: no more patching, no more inherited mess, a fresh page. That instinct is understandable, and it is usually the wrong one. A full rewrite is the largest and riskiest single move you can make. It stops all new value while it runs, because the old system still needs patching and the new one earns nothing until it ships whole. It also tends to recreate the same debt, through the second-system effect, where the rebuild over-corrects everything the first version got wrong and over-engineers the rest.
This is why a rewrite sits last among the three repayment routes, correct only when the interest genuinely exceeds the cost of replacement. The route most owners have never heard of is the Strangler Fig pattern, named after a fig that grows around a host tree and slowly takes its place. You replace the old system piece by piece while it keeps running, so value keeps flowing and each step stays small enough to reverse. The old system carries the load until the last part is gone, and when a step goes wrong you have lost a fortnight, not a year.
| Area | Big-bang rewrite | Gradual replacement |
|---|---|---|
| Risk | One large bet, placed all at once | Many small bets, each contained |
| Value during the work | Frozen until launch day | Keeps flowing throughout |
| Cost profile | Heavy upfront, uncertain end date | Spread out, paced, easier to forecast |
| Reversibility | Hard to undo once committed | Each step can be rolled back |
Before commissioning any rebuild, it is worth revisiting whether to build at all.
Managing Technical Debt Comes Down to Budget, Cadence and Visibility
Knowing when a rewrite is justified is one decision. The steadier work is deciding, month to month, how much debt you pay down and how you keep track of it. Three routes cover almost every case, and the first two run quietly in the background rather than arriving as a crisis.
A standing maintenance allocation
A fixed slice of every development cycle reserved for paying down principal, updating dependencies and clearing known problems before they compound.
Refactoring alongside new features
When a developer builds near messy code, they tidy it as they go. Robert C. Martin calls this the Boy Scout Rule: leave the code a little cleaner than you found it.
A rewrite, as a last resort
Reserved for when interest genuinely exceeds the cost of replacement, as covered above. Rarely the right first move.
The allocation route is the one most worth formalising, and there is a defensible number for it. Treating maintenance as a permanent line in your development budget, rather than an occasional emergency, is what a standing maintenance arrangement actually looks like in practice.
As an industry planning benchmark, setting aside roughly 15 to 20 per cent of development capacity for maintenance and debt repayment is defensible ongoing spend. Some benchmarks put it nearer 10 per cent. It is a planning figure, not a quoted price.
Visibility is the last piece. Keep a debt register: a short, reviewable list of known debt items, each with its business impact and rough repayment cost. This is not a developer's Jira board or ticket queue; it is a list you read and budget against. Outdated dependencies and thin test coverage belong on it alongside the tangled modules, so debt becomes a managed backlog you prioritise rather than a vague worry living in one person's head.
Technical Debt You Can See Is Technical Debt You Can Manage
Technical debt is not a mysterious slowdown or a run of bad luck. It is a set of decisions, made at particular moments for particular reasons, and decisions can be examined and costed. Some of what you carry was the right call at the time: a shortcut that let you ship, win a client or test an idea before committing to it fully. The work is not to feel guilty about that history. It is to know which kind of debt you hold, roughly what it costs each month, and to give repayment a standing place in the budget rather than a panic every couple of years. A register you can read, repayment you have planned for, replacement done in pieces rather than one nervous rewrite, and a plain conversation with whoever writes your code. That is the whole of it.
Make the invisible visible
If a system you depend on has started to feel slow or fragile, we can look at it together and work out what the debt is actually costing and where repaying it first would help most. No obligation, just a clear picture.
Start a conversation →