What Founders Get Wrong About Technical Debt in Diligence

# What Founders Get Wrong About Technical Debt in Diligence A founder walked me through their codebase apologizing for "a lot of technical debt" before I'd looked at a single file. What they showed me was a monolith that hadn't been refactored into microservices, using patterns that were unfashionable but consistent, tested reasonably well, and boring in exactly the way that makes a system easy to operate. What they actually had wrong wasn't in the parts they apologized for. ## Technical debt is a metaphor, and founders often use the wrong half of it The term suggests a loan: you took on debt to move fast, and now you pay interest until you pay it down. Under that framing, "old architecture" and "code you'd write differently today" get flagged as debt, because they're the parts that visibly diverge from a current best-practice checklist. But a system that's unfashionable and stable isn't paying interest — it's just not the system you'd design from scratch today, which is true of almost every system old enough to have real users, and is not, on its own, a cost. Actual technical debt — the kind that compounds and constrains what a team can safely do — looks different and is usually harder for a founder to see from inside, because it's often invisible until someone tries to change the thing it's attached to. A monolith with clean boundaries and one deploy pipeline is an architectural choice. A monolith where three unrelated features silently share a global mutable state object, so that a change to one has to be manually checked against the other two every time, is debt — not because it's old, but because every future change pays a tax that has nothing to do with the size of that change. ## The signal that actually predicts future cost What I look for isn't "does this use current best practices." It's "what does it cost, in practice, to make a small, well-scoped change here" — checking that directly, by tracing what a recent small feature actually touched, rather than inferring it from the architecture's age or fashion. A codebase can look modern and still fail that test if a change to one endpoint requires touching twelve files across three services because of tangled implicit coupling that no amount of current framework choices prevents. A codebase can look dated and pass that test cleanly if its boundaries, however unfashionable, are honest about what depends on what. That's the check that actually predicts what diligence should care about: how much a future acquirer's team will have to fight the codebase to ship the things they'll want to ship. Architectural age doesn't predict that well. Coupling does. ## What founders should actually apologize for, and usually don't The things I've found that genuinely cost an acquirer money later are rarely the things founders lead with in a nervous pre-diligence disclosure. They're the config value hardcoded in three places that have to be changed together and aren't documented as coupled. The migration that was done manually once and never turned into a repeatable script, so nobody can safely reproduce it in a new environment. The test suite that exists but silently stopped being run in CI eight months ago and nobody noticed because nothing broke loudly enough to force the question. None of those show up as "technical debt" in the way founders usually use the term, because none of them are about the code looking old. They're about a gap between what the team believes is true of their own system and what's actually true of it — and that gap, not architectural fashion, is the thing that actually costs money after a deal closes.