Skip to main content
Architecture & Engineering

Technical Debt

Technical debt is the future cost created by choosing a faster implementation now over a better one. Like financial debt it can be a sound decision — shipping sooner has real value — but it accrues interest in the form of slower future changes, and unmanaged it eventually consumes a team's capacity.

The metaphor is useful precisely because debt is not automatically bad. Taking a shortcut to validate an idea before investing in the proper implementation is often correct. What makes it damaging is taking it unknowingly, or taking it deliberately and never recording it.

The reliable symptom is that changes take longer than they should for reasons unrelated to their complexity — a small feature requiring edits in six places, or a fix that keeps reappearing. Teams that track debt explicitly, with the cost of the shortcut written down where it was taken, tend to pay it back before it compounds; teams that rely on remembering do not.

Codazz builds this in production — Legacy Modernization.

FAQ

Technical Debt
FAQ.

Common questions about technical debt.

Ask Us Anything

Enough that shipping speed is not obviously suffering. A useful signal is whether estimates are dominated by working around existing code rather than by the new work itself — when that flips, debt has become the constraint. Zero debt is not the target; deliberately incurred, recorded and repaid debt is.