How to Price Tech Debt Into an Acquisition Offer

Tech debt discovered in due diligence is rarely a reason to kill a deal. It is a number you convert into a price adjustment. The codebase needs six months of remediation before your team can move at speed on it? That is a real cost, it lands after close, and it belongs in the purchase price or the earnout, not in a vague anxiety about quality. The skill in acquisition is turning what your engineers found into dollars the deal team can defend across the table. Most technical reviews stop at a findings report and never make that translation.

Why walking away is usually the wrong move

Every codebase has debt. If you walk from every messy repo, you never buy anything, and the messy repo might be attached to a business with real revenue and real customers. The debt is not the question. The question is what the debt costs to fix and whether the price already accounts for it.

Reframing debt as a price input changes the whole conversation. Instead of arguing about whether the code is good, which is subjective and gets defensive fast, you argue about remediation cost, which is an estimate you can build, show your work on, and negotiate. That is a conversation deal teams know how to have. Treat the codebase like the balance sheet item it is, and the debt becomes a line, not a dealbreaker.

How to turn findings into a number

Your engineers hand you findings. Your job is to attach effort to each one. Group the debt into buckets: things you must fix before you can safely operate, things you should fix to move at your target speed, and things you can live with indefinitely. Only the first two carry a cost that belongs in the price. The third is noise.

For the must-fix and should-fix buckets, estimate engineering time. This is where a disciplined refactor effort estimate matters, because a hand-wave becomes a defensible number when you tie it to specific modules and specific work. A repo intelligence scan gives you the raw material fast: which modules are the hotspots, where the coupling is worst, how much of the tree is dead code you can ignore versus load-bearing tangle you must unwind.

Rank by cost to fix, not by count

The trap is letting the scanner's volume drive the number. A tool that reports 4,000 lint warnings and one decayed core architecture will make the 4,000 feel like the problem. They are not. The 4,000 are a weekend. The architecture is the six months. If you price the volume instead of the cost, you overpay attention on the cheap stuff and underprice the expensive stuff.

Rank every finding by what it actually costs to remediate and by what it costs you to leave unfixed. This is the same discipline as deciding which tech debt to fix first, applied to a valuation instead of a sprint. The most expensive debt is usually invisible to counters: architectural decay, missing tests around critical paths, key-person knowledge that walks out the door at close. Price those, because those are what actually slow your team down.

Structure the adjustment so it holds

Once you have a number, decide how it enters the deal. A straight price reduction is cleanest when the debt is certain and quantified. When the cost is uncertain, an earnout or a holdback tied to remediation milestones shares the risk with the seller, which is fairer and easier to agree. When the risk is a specific liability, security debt in a regulated product for example, an indemnity clause is the right tool, because security debt is not the same as technical debt and should be handled as risk, not just cost.

Watch the key-person problem separately. If the entire architecture lives in one engineer's head and that engineer is not staying, no code fix solves it. That is a retention package or a knowledge-transfer requirement written into the deal, and it is often the most expensive item on the list even though no scanner will ever flag it.

What good pricing protects

Done right, pricing tech debt into an acquisition protects you twice. It stops you overpaying for a codebase that needs a year of work before it earns its multiple. And it stops you walking from a good business because the code offended your engineers. The debt is neither a virtue nor a veto. It is a cost, and cost is negotiable. Bring a number, show your work, and let the price carry what the code cannot.