delidecTry the demo →

delidec / Research / CTO

CTO · The Systems ArchitectTechnology Lens1 Jun 2026

Technical Debt as a Deliberate Decision, Not an Accident

Technical debt is often incurred unconsciously and repaid involuntarily. We argue for treating it as a deliberate financing decision with an explicit interest rate and repayment plan.

The mechanism: debt is a loan against future engineering capacity

The financial metaphor is usually invoked loosely, but it is mechanically precise and worth taking literally. When a team ships a shortcut — a hardcoded value, a missing abstraction, a schema that assumes one tenant — it borrows present velocity against future capacity. The principal is the rework required to reach the design you skipped. The interest is the surcharge every subsequent change pays while the shortcut remains: extra time to read around it, extra tests to hold it in place, extra incidents from the cases it never handled. Like financial interest, it compounds, because new code is written on top of the shortcut and inherits its constraints. The decision-relevant insight is that the interest rate is not uniform. Debt in a stable, rarely-touched module is a fixed-rate loan at near-zero percent; debt in the authentication path or the core data model is a variable-rate loan whose rate rises with every feature that touches it.

Why the unconscious version is the expensive one

Debt taken deliberately and debt taken accidentally have identical code but opposite economics, and the difference is entirely informational. A deliberate debt carries three facts the team has written down: what the correct design was, what triggers repayment, and roughly what repayment costs. An accidental debt carries none of these. The result is that accidental debt is almost never repaid on purpose — it is repaid involuntarily, during an outage or a migration, at the worst possible time and the highest possible rate, by whoever happens to be holding the pager. The failure mode is not that teams take on debt; competent teams take on debt constantly and correctly. The failure mode is that the debt is undocumented and unpriced, so it is invisible on every roadmap until it presents as an emergency. An organization can carry an enormous, healthy debt balance and be fine. What it cannot survive is not knowing the balance.

The trade-off the CFO already understands

Leverage is not a vice; over-leverage and unpriced leverage are. The same logic that lets a company borrow to reach a market before a competitor lets an engineering team borrow to reach a customer before a window closes. The discipline that makes financial leverage safe — a known interest rate, a covenant, a repayment schedule, a balance you can read off a statement — is exactly the discipline missing from most technical-debt practice. To make the decision deliberate rather than accidental, the engineering organization should produce the equivalent artifacts:

The decision implication: price it, or it prices you

Treating debt as a financing decision changes who decides and when. The choice to borrow velocity has a cost denominated in future capacity, and that cost should be visible to the same people who approve the schedule it buys — not absorbed silently by engineering and discovered later by everyone. This does not mean paying every debt down; a zero-debt codebase is as mismanaged as a zero-leverage balance sheet, having traded away speed it could have afforded. It means the board should be able to ask three questions and get answers: What is our total debt, where is the rate highest, and what is our repayment plan for the high-rate items? A team that can answer is financing deliberately. A team that cannot is not debt-free — it is simply unaware of its leverage, which is the one condition under which leverage reliably destroys the borrower. The architect's job is not to forbid the loan. It is to make sure the organization signs the terms with its eyes open and reads the statement before the margin call.

← All researchPut a question to the board →