Technical debt isn’t bad. Unpriced technical debt is.

Technical debt is often a rational trade: move faster now and accept a future cost. The dangerous part is when nobody records the cost, trigger or owner — and the shortcut quietly becomes architecture.

Debt is not the same as bad code

The metaphor is useful because real debt can be strategic. A startup may keep an admin step manual for now, to see whether anyone wants the feature before automating it. A product may run on a single database because its scale does not yet justify anything more complex.

Those decisions can be excellent engineering if the team understands what it is borrowing from the future.

The problem is invisible interest

Debt becomes dangerous when the shortcut raises the cost of every future change and nobody notices. A hard-coded permission rule appears in six places. A temporary CSV import becomes a daily chore for someone. A service with no idempotency — no way to recognise the same request arriving twice — leaves people reconciling duplicates by hand.

The original shortcut may have saved two days. The interest is now paid every sprint.

Price debt when you take it

When taking a shortcut, record four things:

This turns ‘we should clean this up someday’ into a decision the business can reason about.

Use triggers, not guilt

Not every debt item deserves immediate repayment. Tie it to conditions. The manual reconciliation is acceptable until 500 orders per day. The single-region deployment is acceptable until enterprise availability requirements arrive. The hard-coded roles are acceptable until custom permissions become a sales requirement.

A trigger keeps teams from polishing architecture that the product does not yet need.

A shortcut becomes dangerous when nobody remembers the repayment trigger.

Separate local mess from structural debt

A poorly named function is annoying. A data model that cannot keep one customer’s data separate from another’s can block a major contract. Both get called ‘technical debt’ in casual conversation, but they deserve very different priority.

Prioritise debt by business impact, change frequency, incident risk and how much it slows delivery.

Budget debt into normal product work

If repayment only happens during mythical quiet periods, it will not happen. Pay debt down while you are already working in that part of the system. Reserve some capacity for high-impact maintenance, and put larger structural work on the roadmap where everyone can see it.

The goal is not zero debt. Zero debt would often mean zero urgency, zero experimentation and a suspicious amount of engineering time spent predicting futures that never happen.

Good debt has an owner and an exit

A deliberate shortcut should sound like this: ‘We are doing X because Y. It will create Z. We will revisit when condition A occurs.’

That is a business trade-off. ‘Nobody remembers why this works this way’ is not technical debt. It is technical archaeology.