How to price technical debt into an acquisition

Technical debt kills more value-creation plans than it kills deals, and it does both mostly because it enters the conversation as a mood. An engineer says the codebase is bad, a committee member remembers a rewrite horror story, and suddenly the deal carries an unquantified fear discount, or worse, no discount at all because nobody could put a number on the feeling.

Our position, after pricing debt in due diligence across many acquisitions: technical debt is a number, or rather three numbers. Cost to fix, cost to carry, and cost to the roadmap. Once a finding is expressed in those three, it stops being a mood and becomes a line item, and line items can be negotiated.

The three costs

Cost to fix is the obvious one: engineer-months to bring the debt-carrying system to the state the plan requires, at loaded cost. Not to perfection, to the plan. A creaky admin tool that the plan never touches costs zero to fix, whatever the engineers think of it.

Cost to carry is the one buyers forget. Debt taxes everything that crosses it: features ship slower, incidents recur, onboarding takes months instead of weeks, infrastructure runs oversized because nobody dares touch the config. Estimate it as the drag on the current run rate: if the team ships at 60 percent of healthy velocity because of the state of the core, that gap is a recurring annual cost, and it usually dwarfs the one-time fix.

Cost to the roadmap is the strategic one. If the value-creation plan needs three integrations, a new pricing model, and AI features on top of the platform, ask of each: does the debt make this slower, riskier, or impossible? A plan item that silently requires a platform rebuild first is not a plan item, it is a discovery waiting for month four.

Measuring technical debt in acquisition due diligence

You cannot get these numbers from a static analysis score. In technical debt due diligence on an acquisition, we build them from four sources: the code itself, but read for the shape of the debt rather than a lint count; the commit record, which shows where changes go to die, the modules everyone routes around, the fix-revert-fix scars; the team, because engineers will map their own debt with startling honesty if you ask what they would rebuild first and what they fear touching; and the incident and delivery data, which converts anecdotes into rates.

Then we cost only what blocks the thesis. The output is a short table of debts, each with the three numbers and a confidence level. Ten line items is typical. Two hundred means the reviewer never chose.

When technical debt is acceptable

Often. Debt is deferred cost, and deferring cost is sometimes exactly right. A company that took shortcuts to win a market while competitors polished their architecture made a good trade. Monoliths, old-but-patched frameworks, an ugly module the team openly manages around: none of this should frighten anyone, and treating it as damning is how buyers get distracted from the red flags that actually matter.

The acceptable pattern has two properties: the team knows the debt (they can name it, locate it, and say why it exists) and the debt sits off the critical path of the plan you are underwriting. Known, peripheral debt is a maintenance schedule.

When it eats the value-creation plan

The dangerous pattern inverts both properties: unknown debt on the critical path. The platform that needs a rewrite before it can serve the expansion market. The data model that makes the AI roadmap a research project. The 40-hour manual deployment that caps release frequency no matter how many engineers you hire. We have seen a hundred-day plan spend its first year on remediation that never appeared in any model, and the sponsor’s returns never caught up with the lost year.

This is why the debt table and the value-creation plan must be written against each other. Every plan item gets a debt check; every severe debt gets a plan consequence. Debt that touches nothing in the plan drops to a footnote.

How it shows up in the price

Concretely, four mechanisms, in rising order of severity: a remediation budget in the model (fix costs, staffed and scheduled, reducing free cash flow in years one and two); a price adjustment, where carry costs justify revising the multiple rather than adding a line item; escrows or earnout conditions when the debt estimate carries real uncertainty; and restructured deal logic, when the fix requires the founders to stay or the timeline to move.

What does not work is the vague haircut: "the tech seems rough, take ten percent off". Sellers reject it because it is unarguable, and buyers regret it because it is uncalibrated in both directions.

Getting from mood to numbers in a deal window is a specific skill: part engineering, part forensic reading, part pricing. The point of a technical audit is to hand the deal team that table, so the negotiation runs on evidence instead of adjectives.