Technical Debt

Technical debt is the gap between the solution you shipped and the solution you should have built. Every shortcut, every "we will fix it later," every decision made under deadline pressure that traded long-term maintainability for short-term speed — that is a deposit in the debt ledger. And like financial debt, it compounds.

The metaphor is precise. A small amount of debt, taken on deliberately with a repayment plan, is a legitimate tool. You ship a prototype with hardcoded values because the demo is Tuesday and the configuration system is a two-week project. That is deliberate, strategic debt — and it is fine, as long as the configuration system actually gets built. The problem is that most technical debt is not deliberate. It accumulates silently. Nobody writes it down. Nobody schedules the repayment. And six months later, the team is spending 40% of their capacity servicing debt they did not know they had.

1. Deliberate Debt You know you are taking a shortcut. You document it. You schedule the fix. The debt is visible and managed. This is the only acceptable form of technical debt — the kind where the interest rate is known and the repayment date is on the calendar.
2. Accidental Debt You did not realize the design would cause problems until later. The team chose a pattern that seemed reasonable at the time but scaled poorly. This is unavoidable — nobody has perfect foresight. The key is recognizing it when it surfaces and adding it to the ledger instead of ignoring it.
3. Inherited Debt The client's existing systems carry their own debt, and your solution has to integrate with those systems. You did not create this debt, but you must account for it in your architecture. Ignoring inherited debt is the fastest way to ship a solution that works in your test environment and fails in theirs.