'We'll fix it later' is a loan. Here's the interest rate

Every time someone on your team says "we'll clean it up later," they're taking out a loan. The problem is that almost nobody checks the interest rate — until it bankrupts an entire sprint. Technical debt is the most-used and least-understood metaphor in software. Used well, the metaphor is genuinely powerful, because debt is exactly the right mental model — including the part everyone forgets: interest. Debt isn't the same as bad code First, a correction. Technical debt isn't just messy or bad code. It's a deliberate or accidental trade: you took a shortcut — skipped the abstraction, hardcoded the value, deferred the test — to move faster now, in exchange for a cost later. Sometimes that's a smart, conscious decision. Shipping today to validate an idea, knowing you'll refactor if it works, is often the right call. The debt isn't the problem; unmanaged, invisible debt is. The interest is the point Here's what the metaphor gets exactly right and most teams ignore. Debt accrues interest. Every feature you build on top of a shortcut is a little harder to build. Every bug in the messy area takes a little longer to fix. The shortcut doesn't cost you once — it taxes every future change that touches it, and that tax compounds. This is why teams mysteriously slow down over time. It rarely feels like a wall; it feels like everything gradually getting harder, estimates creeping up, small changes turning into week-long ordeals. That's compounding interest on debt nobody tracked. I've watched a system's velocity get quietly reclaimed by exactly this, and paying it down deliberately is part of how I approach building things properly. Good debt, bad debt The framework that makes this actionable: Deliberate, prudent debt: "We know the right design, but we're shipping the simple version to hit the deadline, and we'll fix it." Fine — it's a conscious, tracked trade. Accidental, reckless debt: "What's a design pattern?" — debt taken on through inexperience, invisibly, with no plan to repay. This is the dangerous kind, because you can't manage what you don't know you owe. The goal isn't zero debt — that's as impractical as a business that never borrows. The goal is conscious debt: you know you took it, you know roughly what it's costing, and you have a plan to pay it down before the interest eats you. Paying it down Debt you never repay compounds until a "simple" change becomes impossible and someone proposes a full rewrite. The healthier path is continuous, deliberate repayment: refactor the area you're already working in, keep the interest from compounding, treat paying down debt as real work rather than a someday-luxury. The best time to fix the shortcut is the next time you touch that code — not "later," which never comes. The takeaway Stop saying "we'll fix it later" as if later is free. Every shortcut is a loan with compounding interest, and the interest is paid by your future self, in slower delivery and harder changes. Take debt on purpose, track it, and pay it down deliberately — that's the difference between using leverage and drowning in it. More of how I think about building maintainable systems at www.divyakush.com. Related reading Making an LLM trustworthy over bank statements — a project where splitting a monolith into services was paying down architectural debt for responsiveness.