← Back
Thesis. The founder thinks technical debt is an engineering problem. She plans to fix it after the sale, hopes the buyer will not find it, or assumes that because the product works, the code will not affect the price. But a buyer’s technical diligence team is not filing a bug report. It is estimating the size of an obligation the acquirer will inherit. That obligation has a dollar value. It may appear as a lower multiple, an escrow, a holdback, an earnout, or a price chip late in the process. If the obligation is material, it rarely disappears. It changes form.
The revised offer arrived on a Thursday afternoon.
She had spent four months preparing. The information memorandum was thorough. Revenue quality had been reviewed. Customer contracts were tidy. IP ownership had been confirmed. She had worked through every dimension of the business she had been told would matter.
The initial indication of interest had come in at a range she could work with. Then the buyer’s technical diligence team spent two weeks in the codebase.
The number had moved.
Not because the buyer had changed its mind about the market. Because it had changed its view of ownership.
She asked her advisor to explain.
The product had not failed. No functionality was broken. Customers had not complained. Revenue was still growing. The platform was live, processing transactions, doing exactly what it had been built to do for seven years.
Her advisor sent her a summary of the technical report.
She read it twice. The product worked. The report agreed. But it had not been asked whether the product worked today. It had been asked what it would cost the buyer to own it safely tomorrow.
Those were different questions. She had spent four months preparing an answer to the first one. No one had told her the second one existed.
Place two software companies side by side.
Both report ten million in ARR. Both grew at twenty-five percent in the prior year. Both have gross margins above seventy percent. Both have passed revenue quality review. Customer contracts are clean. IP ownership is confirmed. By every measure the founders have been tracking, both are healthy, well-run businesses.
A buyer prices them differently.
The first has a modular architecture. Services are separated. Dependencies are documented. The codebase has reasonable test coverage. Security practices are current. A new engineering team could extend the platform without fear. When the buyer’s technical team models what integration will cost, the estimate is manageable. The business transfers cleanly.
The second has a different kind of history. Seven years of compressed delivery cycles, competitive pressure, and a small team moving fast. Not broken. Still running. But the shortcuts are embedded: undocumented workarounds, unsupported libraries, systems that only one engineer fully understands, a security posture that
made sense in 2018 and has not been reviewed since. The platform works. But it does not transfer cleanly. For seven years, the founder was rewarded for speed. In diligence, the buyer prices the residue of that speed. The buyer is not choosing between good code and bad code. It is choosing between one product that transfers and another that arrives with an unmeasured obligation attached. Known cost can be modelled. Unknown cost is discounted.
A buyer’s technical diligence team does not produce a bug report. It produces an ownership budget.
That budget is built around five questions. What will it cost to bring the platform to the acquirer’s engineering standard? What integration delay will the codebase impose on the acquirer’s product roadmap? What security or compliance exposure is the buyer inheriting, particularly if it is larger, listed, regulated, or operating in a different jurisdiction? How dependent is the system on people , the founder, a single engineer, or institutional memory that has never been documented? And what is the risk premium for what the team could not see in two weeks?
Those five questions do not always produce a neat spreadsheet deduction. They produce an internal view of the cost of ownership. The buyer does not present that view as a remediation invoice. It does not hand the seller the calculation. It appears in the offer, quietly.
It may appear as a lower multiple, an escrow that releases after an integration milestone, a holdback tied to platform stability post-close, or a late-stage price chip introduced after the seller has declined other buyers and the leverage has shifted.
The buyer does not call it bad code. It calls it platform risk.
Technical debt is not a product problem the new owner will address when the time is right. It is a balance sheet item the founder forgot to include.
The liability does not disappear at completion. It moves from the seller’s future into the buyer’s budget. And buyers do not inherit unpriced liabilities generously. They price the transfer.
The founder who assumes the product’s functionality determines its value has answered the wrong question. The product may work. The question is what it will cost the buyer to own it.
Technical diligence is not a code review. It is a translation exercise. It translates engineering conditions into buyer consequences.
Architecture: Can this platform scale, integrate with the acquirer’s systems, and be extended without expensive redesign? A monolithic codebase is not automatically a problem. But tight coupling, undocumented interfaces, and components that cannot be changed independently create an integration cost that travels into the buyer’s valuation model.
Dependencies: Is the business relying on unsupported libraries, end-of-life infrastructure, fragile vendor arrangements, or undocumented workarounds? Dependency debt is visible in diligence because it is easy to audit. If the acquirer operates in another jurisdiction, regulatory or infrastructure requirements may expose costs the seller never contemplated.
Security posture: What exposure does the buyer inherit? A larger acquirer, particularly one that is listed, regulated, offshore, or operating in sectors with compliance obligations, will apply its own security standard to the acquired codebase. Gaps between the seller’s posture and the acquirer’s standard are not treated as engineering preferences. They are treated as remediation costs.
Documentation: Can a new team understand and operate the system without tribal knowledge? The engineer who built it is often leaving. The founder is often leaving. If the system lives in their heads rather than in
documentation, the buyer is acquiring a dependency on people who will not be there.
Test coverage: Can the buyer change the product without breaking it? A platform with low test coverage cannot be safely modified. The acquirer’s engineers cannot extend it, integrate it, or improve it with confidence until coverage is rebuilt or strengthened. That work takes time and budget.
Each answer either reduces the buyer’s confidence or increases the buyer’s budget. Both affect price.
Technical debt cannot be retired between signing an advisory engagement and distributing an information memorandum. It is the accumulated output of years of delivery decisions. It will not be reversed in eight weeks.
But the goal is not a perfect codebase. It is a known one.
A founder who commissions a technical audit eighteen to twenty-four months before a process begins receives something the buyer’s team will also eventually produce: an honest assessment of what exists, what it would cost to address, and what the priority order should be. The difference is that the founder receives it with time to act.
A roadmap that documents the debt, sequences the remediation, and shows twelve months of progress against it tells the buyer something specific. The risk is understood. It is being managed. The estimate is smaller than it would have been if no one had looked.
A buyer can price known debt. Unknown debt becomes a discount.
The founder who commissions the audit before the process begins is not eliminating technical risk from the offer. She is changing the buyer’s confidence in the size of it. That is the difference between a liability the buyer can underwrite and a discount the buyer imposes.
Issue 13, The Deal That Falls Over on the Seller’s Side, turns to the legal and structural conditions that kill transactions after terms are agreed, and why most of them were visible before the process began.
Issue 06 The Revenue Your Buyer Won’t Pay For
Issue 07 Your Customers Don’t Belong to You
Issue 08 Who Actually Owns Your Software?
Issue 09 The Number That Decides Your Multiple
Issue 10 The Risk You Are
Issue 11 You’re Not Selling History
Issue 12 The Liability Inside Your Code
Issue 13 The Deal That Falls Over on the Seller’s Side
Issue 14 The Prepared Business Premium
Sell-side technology M&A advisory. Sydney, Australia.
© 2026 Cube Capital Pty Ltd. All rights reserved.
Cube Capital provides M&A advisory services to wholesale clients only. This website does not constitute financial product advice. Advisory services are provided in accordance with applicable Australian financial services law.