Technical Debt Assessment: Sizing the Hidden Liability Before You Buy

What Technical Debt Is (and What It Isn't)

Technical debt is the accumulated cost of engineering shortcuts. Every team takes them: a quick patch instead of a redesign, a library pinned three versions back because upgrading would cost a week, a fragile module everyone works around because nobody has time to rebuild it. Each shortcut trades future capacity for present speed.

That trade is often correct. A company racing to product-market fit should take on some debt, the way a growing company takes on borrowed capital. Debt becomes a liability when the service cost starts eating operating capacity: when so much engineering time goes to maintaining old decisions that little is left for building new capability.

Two clarifications keep an assessment honest. An old stack is not the same as debt. A ten-year-old codebase with fast deploys, reliable tests and distributed knowledge is a healthier asset than a modern stack nobody dares touch. And debt is invisible in the data room by default. It sits in no ledger and no contract. Unless it's assessed deliberately, it transfers to the buyer unpriced.

Why Technical Debt Assessment Belongs in Due Diligence

The size of the liability justifies the workstream. Stripe's developer research put the share of engineering time lost to technical debt and maintenance near 42 percent at the average software company. Take that ratio seriously for a moment. A 50-person engineering team operating there delivers the new-feature output of a team roughly half its size, while the buyer pays for the full headcount.

The deal case usually assumes the opposite. Value-creation plans lean on new features, integrations and platform work, delivered at a pace consistent with revenue targets. If 40 percent or more of capacity is already committed to servicing old decisions, those timelines are fiction before day one.

Debt also compounds. Deferred upgrades get harder every quarter they're deferred. Fragile modules accumulate patches, and the patches accumulate patches of their own. A company can grow revenue for years while its ability to change its own product quietly declines. Catching that divergence before signing is what the assessment is for.

Reading Technical Debt Without a Code Audit

A full code audit takes weeks, requires specialist reviewers, and still samples a fraction of the codebase. Sometimes the deal warrants one. But most of the signal is available faster, from the records the engineering system produces anyway: repository history, pipeline logs, issue trackers. Who changed what, when, how often. Patterns, not source code.

Five signals carry most of the weight:

• Maintenance-to-feature ratio. What share of effort goes to bug fixes, patches and workarounds versus new capability? Ticket types and branch history approximate it well. Teams in good shape typically hold maintenance to 20 to 30 percent of capacity.
• Hotspot concentration. A healthy codebase spreads changes across many files. A debt-laden one shows a handful of files modified in nearly every cycle: code so fragile it needs constant patching, where every change risks breaking something adjacent.
• Deploy complexity trajectory. If releasing takes more steps, longer builds and more manual checks than it did a year ago, the system is getting harder to work with. The direction matters more than the absolute number.
• Test suite trajectory. A growing suite with stable pass rates signals discipline. A stagnant suite, falling pass rates, or tests routinely skipped so a release can ship: quality infrastructure eroding in plain view.
• Dependency age. Libraries several major versions behind current are deferred work accruing interest, plus widening exposure to known vulnerabilities. Update cadence is visible in commit history.

The Maintenance Tax: Turning Debt Into a Number

The practical output of a technical debt assessment is a maintenance tax: the share of future engineering capacity already spoken for.

A worked example. The target employs 50 engineers at a fully loaded cost around $250,000 each. The signals converge on a 40 percent maintenance share. That's roughly $5 million a year in payroll holding the current product together rather than building the roadmap, repeating every year of the hold. It appears nowhere in the financial statements.

The tax feeds the deal twice. It corrects the effective size of the team the buyer thinks it's acquiring. And it prices the remediation: working debt back to a manageable level typically means dedicating 15 to 20 percent of engineering capacity for several quarters, capacity the plan cannot simultaneously spend on features. Both numbers belong in the valuation conversation, the same way deferred maintenance belongs in the price of a building.

Thresholds and Red Flags

Working thresholds practitioners use, not laws:

• Under 30 percent maintenance share: normal operating condition for a growing company. Monitor, nothing more.
• 30 to 40 percent: watch the trend line. Stable is manageable. Climbing means the debt is compounding faster than the team pays it down.
• Over 40 percent: the tipping point. Feature velocity will keep declining, and the effective team is meaningfully smaller than the org chart claims.
• Feature lead time stretching quarter over quarter is the same disease seen from outside the repository: the pipeline from spec to production is silting up.
• 'We're planning a rewrite' deserves scrutiny, not comfort. A full rewrite proposal is often the symptom of debt so deep the team sees no incremental path out, and rewrites carry their own multi-year risk.

What to Do With the Finding

A high debt reading is rarely a reason to walk away. It's a reason to reprice, and to plan.

Repricing is straightforward once the maintenance tax is quantified: the cost of remediation and the delay to roadmap-dependent revenue both move the number. Planning is where the finding earns its keep. Debt paydown is among the more predictable operational interventions available to a new owner. The methods are known, the timeline runs in quarters rather than years, and the recovered capacity compounds through the hold.

The finding to fear isn't the big number. It's the unexamined one. A target whose leadership can name its debt, show where it lives and explain the paydown plan is demonstrating engineering maturity. A target that reports having no technical debt at all has simply never measured it.