Technical Debt
The future cost of a shortcut taken today, paid back as slower delivery until the shortcut is fixed. Sometimes a smart trade, sometimes accidental cruft, dangerous mostly when nobody can see it.
Technical debt is a metaphor, and a good one. When you take a shortcut to ship faster (a quick hack instead of the clean design, a hard-coded value instead of the config system), you borrow time now and pay it back later as interest: every future change in that area is slower, riskier, and more annoying. Like financial debt, it is not automatically bad. It is a tool.
Taking debt deliberately is often the correct call. Before product-market fit, speed beats elegance, because most of what you build will be thrown away anyway. Building a pristine architecture for a product that might not exist in six months is its own kind of waste. The right move is frequently to take the shortcut, ship, learn, and pay the debt down once you know the thing is worth keeping.
The danger is not debt. The danger is invisible debt. Deliberate, documented debt (“we hard-coded this, here is the ticket to fix it before we scale”) is a managed liability. Undocumented debt that nobody decided to take, that just accreted through hurry and turnover, is the cruft that quietly strangles a codebase. Velocity drops, nobody can say why, and every estimate doubles. By the time it is visible in the metrics, the interest payments have been compounding for a year.
Wavect’s stance: debt is a deliberate trade-off, not a moral failing. We will happily take debt to hit a window, and we will write down exactly what we took and what it will cost to repay. The conversation we refuse to skip is the one where someone is paying interest and nobody has named the loan. See our full-stack development work for how we keep this trade-off explicit.