Short answer
Technical debt is the future cost of a shortcut taken now: code that works but is structured for speed rather than for change. Interest is paid in slower delivery, so a login system hard-coded for one user type charges its first instalment the day a second role is required.
Also called: Tech debt, Code debt, Design debt
The metaphor is about repayment rather than blame. Debt taken deliberately can be rational — shipping a hard-coded configuration to hit a launch date is a reasonable trade if the decision is recorded and repaid soon after. Accidental debt is the harder kind, accumulated by a team unaware that a better pattern existed, because nobody knows a payment is falling due until delivery slows.
The signal a non-technical owner can read is the estimate curve. When changes of similar size cost steadily more than they did a year ago, and every small request returns with a caveat about touching something else, the interest is visible in the invoice. Outdated dependencies, no automated tests around critical paths, and a deployment only one person knows how to perform are the usual specifics behind it.
Common questions
Should technical debt always be paid off?
No. Debt in code that rarely changes and works correctly can be left alone; debt in the parts touched every week is what taxes delivery. The practical approach is to repay along the routes new work travels, rather than scheduling a cleanup project with no feature attached, which is hard to justify and tends to be cancelled halfway.
Where this comes up in our work
Related terms
Minimum Scalable Product (MSP)
A minimum scalable product is a first release built narrow in features but sound in architecture, so the same codebase carries the product from launch through growth without a rewrite.
Staging Environment
A staging environment is a private copy of a live system, running the same code and configuration, used to test changes before they reach customers.
Sprint
A sprint is a fixed working period, commonly one or two weeks, in which a development team commits to a defined set of work and ends with something demonstrable.
Custom Software vs Off-the-Shelf Software
Custom software is built for one organisation’s specific process; off-the-shelf software is a finished product many organisations subscribe to, such as Shopify or QuickBooks.
Reading definitions because you are scoping a project? Skip ahead and just ask.