The Real Cost of Technical Debt (And How to Price It)

Every roadmap conversation eventually hits the same wall: engineering wants to pay down debt, the business wants a new feature, and there's no shared number to decide between them. That's not a prioritization problem — it's a pricing problem, and it's solvable.

Debt is a loan, so price it like one

Technical debt isn't a moral failing, it's a financing decision — you borrowed velocity now against velocity later, usually correctly, to hit a deadline that mattered. The mistake isn't taking the loan. It's never writing down the interest rate.

For any deliberate shortcut, I ask the team to estimate two numbers at the time it's taken:

1. The time it saved right now — the actual sprint(s) you didn't spend doing it properly.
2. The recurring tax it adds to every future change that touches this area — extra QA time, slower onboarding for new engineers, the workaround every related feature now has to account for.

That second number, multiplied by how many times a quarter that area gets touched, is your interest payment. When it exceeds the original time saved, you're underwater and it's time to pay down principal.

The debt that compounds vs. the debt that doesn't

Not all debt is equal, and treating it as a single backlog is a mistake. I sort it into two buckets:

• Isolated debt — an ugly implementation in a module nobody else touches. It's expensive to fix and cheap to ignore. Leave it.
• Load-bearing debt — a shortcut in a module that sits on the path of most new features. Every sprint, someone pays the interest whether they notice it or not. This is the bucket that actually needs a place on the roadmap.

The single biggest lever I've seen teams pull is simply separating these two buckets. Most "we have too much tech debt" conversations are actually about a handful of load-bearing items buried in a backlog of a hundred low-stakes ones.

Making it compete fairly against features

Once load-bearing debt has a number attached — hours per sprint currently lost to it — it's directly comparable to a new feature's projected revenue impact. Put both in the same currency (engineering hours, or dollars if you want executive buy-in) and let them compete on the same roadmap instead of debt living in a separate "someday" list that never gets funded.

What I tell clients who are worried they've let it go too far

Rarely is a system unrecoverable. What's usually needed is one focused sprint auditing the load-bearing debt specifically, pricing the interest rate on each item, and fixing the two or three that are actually costing the most — not a rewrite. A full rewrite is its own form of debt, and it's the most expensive kind: you don't find out what you got wrong until you're most of the way through paying it off.