Deliberate Technical Debt
A consciously chosen shortcut, recorded with its cost and a repayment trigger, as distinct from debt incurred by carelessness.
The distinction that makes the metaphor useful: deliberate and recorded debt is a financing decision; accidental and unrecorded debt is just poor work. Both slow future change, but only the first can be managed.
Legitimate reasons to take it: a market window that will not wait, a hypothesis that may be invalidated — in which case building it properly is waste — a fixed external deadline, or an early-stage product where the requirements will change beyond recognition.
What makes it deliberate rather than a euphemism: a written record of what was cut and why, an estimate of the repayment cost, a trigger condition ("before we onboard the second tenant", "when this exceeds 1,000 requests per second"), and containment — the shortcut behind an interface so its blast radius is bounded when it is replaced.
The debt worth refusing to take is structural: a wrong service boundary, a shared database, a data model that will hold years of records. Architectural debt charges interest on everything and repaying it means a migration, so the discount rate is nothing like that of a scrappy implementation behind a clean interface.
The organisational requirement is a visible register and periodic review. Debt that is not tracked is not repaid, and the interest is paid silently as declining delivery speed that nobody can attribute.