Technical debt
The future cost of shortcuts taken in code or design to ship sooner.
Technical debt is the extra work a team pays later because of quicker, rougher choices made earlier: duplicated code, missing tests, a structure that no longer fits, or design patterns that drifted apart. Like financial debt, some is a reasonable trade for speed; left unpaid, the interest shows up as slower changes and more bugs.
It is common in prototypes built fast, including those built with AI coding tools. The fix is not a rewrite by default but steady repayment: tests around the riskiest paths, clean-up where the team changes code most, and a design system so the interface stops drifting.
Key characteristics
- A trade of speed now for cost later.
- Grows when shortcuts are never revisited.
- Shows up as slow changes, bugs and inconsistency.
- Paid down gradually, starting where it hurts most.
Example
A startup's prototype works for its first fifty users, but every new feature breaks an old one. A two-week pass adds tests to the payment and sign-up paths before the team builds anything new.
Go deeper
Frequently asked questions
Is technical debt always bad?
No. Taking it on deliberately to learn faster can be the right call. The problem is debt nobody tracks or repays.
Does design have technical debt?
Yes. One-off components, inconsistent spacing and undocumented patterns are design debt, and they slow every new screen.