The real cost of "we'll rebuild it properly later"

The phrase "technical debt" gets used like a guilty admission, as though shipping something imperfect is a moral failure a team commits under pressure and should feel bad about. That framing gets the economics backwards. Debt, in the financial sense, is a legitimate tool — you take it on deliberately, you know the interest rate, and you have a plan to pay it down before it compounds past what you can afford. The failure isn't taking on technical debt. The failure is taking it on without knowing the rate, or without ever intending to pay it back.

Framed that way, "ship the faster, less elegant version now" is sometimes the disciplined choice, not the reckless one — if the team is honest with itself about what shortcut was taken and what it will cost to unwind.

Here's the question that actually matters: can anyone on the team describe, specifically, what was skipped and what it will take to fix it? "We hardcoded this instead of building a config system because we have one customer and building it now would be speculative" is a legible decision. "We'll clean this up later" with no specifics attached is usually not a plan — it's a way of not making the decision explicit, which means nobody is actually tracking the interest accruing on it.

We push every client-facing shortcut through that filter. If we can't name the specific cost of not doing it properly now, we usually just do it properly now, because an un-named cost is the one that surprises you eighteen months in, at the worst possible time to discover it.

"We'll rebuild it properly later" is one of the most common promises in software, and one of the least frequently kept — not because engineers are dishonest, but because "later" has to compete against next quarter's roadmap, and shipped, revenue-generating features almost always win that fight. The rebuild that seemed obviously worth doing in the abstract gets deprioritized every single sprint, individually reasonably, until the shortcut has been load-bearing production infrastructure for two years and nobody remembers it was meant to be temporary.

The honest response to that pattern isn't heroic willpower to actually do the rebuild — it's not promising it in the first place unless there's a real, scheduled trigger for revisiting it. "We'll fix this when we hit 10,000 rows and the query gets slow" is a plan. "We'll fix this later" is a wish.

On every project, we ask three questions before deciding to cut a corner: what specifically breaks if we don't fix this, and under what condition; how expensive is it to fix later compared to fixing it now, structurally — not just in hours, but in whether the surrounding code will have grown around the shortcut by then; and who is going to remember this decision was made on purpose, six months from now, when nobody has time to spelunk through git history to find out.

Sometimes the answer is genuinely "ship the fast version, the risk is low and the reversal is cheap." Sometimes it's "this is exactly the kind of decision that becomes expensive precisely because it's invisible — do it right the first time." The discipline isn't in always doing the rigorous thing. It's in never letting the decision happen by default.