Technical debt is no longer a conversation between engineers. It is a line in the model, and the person holding the pen works for the buyer.
Founders and management teams tend to think about technology debt as an engineering concern — a backlog, a known set of compromises, something to be tidied when there is time. Acquirers think about it as a number. Specifically, they think about it as a reason to pay less.
That shift has become considerably sharper. Technical due diligence used to be a verification step near the end of a process: does the software work, is the IP owned, are the licences in order. It is now run early and treated as a driver of valuation in its own right, with the emphasis on how the estate will behave under new ownership and what liabilities are sitting in it.
What it actually costs
Deloitte’s 2026 Global Technology Leadership Study puts technical debt at somewhere between 21% and 40% of total IT spend. That is the ongoing tax — the proportion of the budget servicing past decisions rather than buying anything new.
21–40%
of total IT spending is consumed by technical debt, according to Deloitte’s 2026 Global Technology Leadership Study
In a transaction the arithmetic becomes more direct. A buyer who identifies a twelve-month remediation backlog does not describe it as debt. They describe it as three additional senior engineers for a year, price that at prevailing rates, and put the figure into the model. At current market rates that single example lands somewhere in the region of $600,000 to $900,000 — and it is deducted from what they are willing to pay, or held back, or converted into a warranty the seller now carries.
The seller’s instinct is to argue that the estimate is too high. It usually is. That is not the point. The point is that the seller arrived without a number of their own, so the buyer’s number is the only one in the room.
A seller who cannot quantify their own technical debt has not avoided the conversation. They have delegated it to the person with the opposite incentive.
The findings that reliably move a price
Diligence findings are not equally weighted. Some are noted and forgotten. A small number consistently change terms, and they are the same ones across most processes.
End-of-life infrastructure. Software or hardware past vendor support is not a preference issue; it is an unbounded liability with a date attached. A buyer can price a migration. What they cannot price is the possibility of being forced into one at short notice by a security disclosure, so they price it high.
Undocumented systems. A system that only one person understands is a concentration risk expressed in headcount. Buyers ask directly what happens if that person leaves during the transition, and a shrug is an expensive answer.
Compliance gaps. Not just formal certification, but the ordinary evidence that controls operate: access reviews actually performed, data retention actually enforced, subprocessors actually recorded. Gaps here are rarely expensive to fix and are disproportionately expensive to be found with, because they suggest the rest of the estate has been managed to the same standard.
Customer concentration inside the architecture. The bespoke integration built for the largest customer, which nobody else uses and nobody can safely change. This one is often invisible on the technology side and obvious on the commercial one, and it links the two in a way that unsettles buyers.
Why “it works fine” is not the defence it feels like
Management teams frequently and sincerely believe their technology is in reasonable shape, because it delivers what the business needs today. That belief is usually accurate and entirely beside the point.
A buyer is not assessing whether the estate works. They are assessing what it will cost to run it at two or three times the current volume, integrate it with something else, or operate it without the people currently holding it together. “It works fine” answers a question nobody asked.
The version that lands is different in kind: here is our technical debt register, here is what we estimate remediation costs, here is the sequence we would follow, and here is what we have already done in the last eighteen months. That is not a weaker position because it admits problems. It is a stronger one, because it demonstrates the estate is understood and managed — and it puts the seller’s number in the room first.
The eighteen-month point
Almost everything that surfaces in diligence was visible well before the process started. End-of-life dates are published years ahead. Documentation gaps are known to the team. The single-person dependency is a standing joke internally long before it is a finding.
What changes is who is looking, and what it costs to be wrong. Eighteen months out, an end-of-life platform is a planned piece of work with a sensible budget. Inside a process, the same platform is a discount, a warranty, or a reason for the buyer to walk while blaming something else.
What to have ready eighteen months before you think you need it
- A technical debt register with an owner and a cost estimate for each item, maintained rather than produced once
- Support and end-of-life dates for every material component, with the decision already taken for anything inside two years
- Evidence that controls operate, not just that policies exist — access reviews, retention, subprocessor records
- A named second person for every system where knowledge currently sits with one
- A short, honest account of the compromises you made deliberately and why, because buyers find them anyway and the explanation is worth more than the discovery
The part that is genuinely reassuring
Technical debt does not have to be eliminated before a transaction, and attempting it is usually a poor use of the eighteen months. Buyers do not expect a pristine estate; they have never seen one. What moves the price is not the amount of debt but whether it is known, owned and being worked.
An estate with a documented backlog, a remediation plan and eighteen months of evidence that the plan is being followed prices very differently from an identical estate with none of those things. The technology is the same. The difference is entirely in whether the management team can demonstrate they are in control of it, and that is a discipline rather than a project.
Which is the same reason it is worth doing whether or not there is ever a transaction. A business that knows what its technology debt costs makes better decisions about it in the ordinary course. The valuation benefit is a consequence of running the estate properly, not a reason to.