The True Cost of Technical Debt

The Debt Metaphor Is Accurate

Technical debt is what you take on when you choose the quick solution over the correct one. Like financial debt, it isn't inherently bad — sometimes borrowing to move fast is exactly right.

The problem is that most companies never look at the interest rate.

What It Looks Like in Practice

Technical debt isn't "messy code". It's specific, and you can usually name it:

• The same business logic copied into four places, so a rule change means four edits and one forgotten
• No automated tests, so every release requires a day of manual clicking
• A database design that made sense when you had one product line and now fights you daily
• One developer who is the only person who understands the billing module
• A framework three major versions behind, so security patches require an upgrade project first
• Configuration that only exists on a server nobody wants to touch

Each one was a reasonable decision at the time. Together they become the reason a two-day feature takes three weeks.

The Interest Payment

Here's what makes debt expensive: it compounds against every future change.

A concrete pattern we see repeatedly at Malaysian SMEs.

Year one. A team ships fast. Features land in days. Everyone is pleased. Some shortcuts get taken to hit a launch date — entirely defensible.

Year two. Features take a bit longer. Occasional strange bugs. The team starts saying "we should really clean that up".

Year three. A change that should take two days takes two weeks, because it touches the copied logic in four places and there are no tests to prove nothing else broke. New developers take three months to become productive. Deployments are scheduled for Friday evening because everyone is nervous.

Year four. The team spends more time firefighting than building. Someone proposes a full rewrite. That proposal is the invoice arriving.

Putting Numbers on It

For a Malaysian SME with, say, three developers at roughly RM8,000 per month each:

A healthy codebase: perhaps 15% of time on maintenance and firefighting. Around RM43,000 per year.

A moderately indebted codebase: 35% of time. Around RM100,000 per year.

A severely indebted codebase: 60% or more. Around RM172,000 per year — and that's before counting the features you never shipped because the team was busy.

The difference between healthy and severe is well over RM100,000 annually in a three-person team. That's the interest payment, and it's invisible on your P&L because it looks like normal salary cost.

The Costs That Don't Show Up in Salaries

Slower time to market. A competitor ships in six weeks what takes you five months. This one can be existential.

Staff turnover. Good developers leave codebases they can't work in. Replacing a developer costs several months of salary in recruitment and ramp-up, and the person who left took undocumented knowledge with them.

Failed hiring. You can't easily hire for a dead framework, and candidates who could work on it don't want to.

Outages. Systems with no tests and no monitoring fail in ways nobody predicted, usually at the worst time.

Decisions you stop making. The most expensive effect, and the hardest to see. Teams stop proposing good ideas because everyone knows the answer will be "we can't do that with our current system".

Debt Worth Taking

To be clear, not all debt is a mistake. Deliberate, time-boxed debt is a legitimate tool.

Take it when:

• You're validating an idea and might delete the whole thing in three months
• A genuine deadline has real money attached
• You're prototyping to learn, not building to keep

The condition is that it must be deliberate and recorded. Write down what you skipped and why. Set a date to revisit. Debt becomes dangerous when it's accidental and forgotten.

Debt Never Worth Taking

Some shortcuts are simply bad trades:

• Skipping security. Injection flaws, credentials in code, no access control. These don't become cheaper to fix later; they become breaches.
• Skipping backups and recovery. Cheap to set up, catastrophic to lack.
• Skipping data model design. Everything else can be refactored. Rewriting a data model with five years of production data in it's genuinely painful.
• Skipping the ability to deploy. If you can't release safely, you can't fix anything quickly, including your debt.

Paying It Down Without Stopping the Business

You can't halt feature work for six months to refactor. Nobody will agree to that, and they're right not to.

What works:

1. Fix what you touch. When you work on a module, leave it better. Small, continuous, no separate approval needed.

2. Reserve capacity. Allocate a fixed share of every sprint — 15-20% is typical — to debt work. Protect it. If it's negotiable, it will always be negotiated away.

3. Attack by pain, not by ugliness. Track where bugs actually come from and where changes take longest. Fix those areas. The ugly module nobody has edited in two years isn't costing you anything.

4. Add tests before refactoring, not after. Tests are what make refactoring safe rather than terrifying.

5. Make it visible to management. "This module caused 40% of our bugs last quarter and takes three times longer to change" is an argument a business owner can act on. "The code is bad" isn't.

Warning Signs to Watch For

You have a real problem if:

• Estimates for similar-sized features keep growing
• Nobody wants to deploy on a Friday
• The same bug keeps returning
• Only one person can safely change a given area
• New developers take more than two months to ship independently
• The phrase "we should rewrite this" comes up more than once a month

The Short Version

Technical debt is a real cost with a real interest rate. It just doesn't appear on any statement, which is why it grows unchecked.

Borrow deliberately, write down what you borrowed, and pay a fixed instalment every sprint. Do that and you'll never face the choice between a rewrite and a slow decline.

Feeling your development slow down and not sure why? We do codebase health reviews — a clear read on where the debt is concentrated and what it's costing you.