How I Think About Technical Debt on Client Projects

Technical debt gets treated as inherently bad, something to eliminate on principle. I think that framing misses the more useful distinction, which isn't whether debt exists, it's whether it was taken on deliberately or accumulated by accident.

Deliberate debt is a legitimate tool

Sometimes the right call on a client project is a simpler, faster implementation now, with a clear understanding that it'll need revisiting once the product has proven itself with real users. That's not a mistake, it's a reasonable bet that speed to validation matters more right now than long-term elegance, especially early, when the biggest risk usually isn't code quality, it's building the wrong thing carefully.

Accidental debt is the actual problem

The debt that causes real damage isn't the deliberate kind, it's the kind that accumulates because nobody made a decision at all, a shortcut taken under deadline pressure and never revisited, an integration bolted on without touching the surrounding design, growing inconsistency because there was never a moment to step back and reconcile it. This kind compounds silently, because nobody's tracking it as a decision that was made.

What I actually do differently

When I take on debt deliberately, I say so, to the client, and to myself, in whatever form of documentation the project actually uses. Not out of ceremony, but because a debt that's written down is a debt that can be revisited on purpose later, instead of being rediscovered the hard way when it finally causes a real problem.

Why this framing changes the conversation with a client

"We're taking a shortcut here" is a very different, more useful conversation than either pretending everything's being built to the highest possible standard, or not discussing tradeoffs at all. It lets a client make an informed call about where their money buys speed versus where it buys long-term durability, instead of that decision being made silently and invisibly on their behalf.

The actual measure of good technical debt management

Not "how much debt exists," but whether anyone could explain, right now, which shortcuts were taken and why. If that question has a clear answer, the debt is being managed. If it doesn't, that's the real problem, not the debt itself.