Definition
Technical debt is the accumulated cost of shortcuts taken in software: quick fixes, outdated libraries, missing tests and messy code that work today but slow down every change tomorrow. The metaphor comes from finance. You borrow speed now and pay interest later in the form of bugs, slower releases and engineers who spend their week understanding old code instead of building new features.
In a company, technical debt shows up as a product roadmap that keeps slipping. A feature that took one week in year one takes a month in year four. Onboarding a new developer takes three months instead of three weeks. The engineering team asks for a "refactoring sprint" or, worse, a full rewrite. Not all debt is bad. Debt taken deliberately to hit a market window is a rational trade, as long as it is tracked and repaid.
A common misconception is that technical debt is a purely technical problem. It is a business decision with a business cost, and the CEO owns it. Another myth is that a rewrite from scratch clears the debt. In practice rewrites often take twice as long as planned and recreate the same problems. In 2026, AI coding agents make repaying technical debt cheaper: they can modernise libraries, add tests and document old code at a fraction of the historic cost.
In practice
A SaaS company I know of froze new features for six months because the billing module, written in a rush during launch, broke every time a new pricing plan was added. Paying that technical debt down earlier would have cost two weeks.
Why it matters
In the companies I run, I ask engineering to report technical debt like a CFO reports liabilities: what we owe, what the interest is costing us each month, and what we are repaying this quarter. If your product velocity is falling, this is usually why.
Frequently asked questions
- Is technical debt always bad?
- No. Taking on technical debt deliberately to launch faster or test a market is often the right call. The problem is unmanaged debt: shortcuts nobody tracks and nobody schedules time to repay. Treat it like a loan with a repayment plan.
- How do you measure technical debt?
- There is no single number. Useful proxies are the time it takes to ship a small change, the share of engineering hours spent on maintenance versus new features, the number of production incidents, and how long a new developer needs before their first useful commit. Track these quarterly.