An earnout can look like a fair way to bridge a valuation gap. Then the business misses its targets because the acquired platform cannot support the growth plan.
That is the danger in tech debt acquisitions. In mergers and acquisitions, technical debt can undermine the growth plan. Parties may agree on targets before agreeing on the cost and disruption required to fix the technology underneath them.
The issue is not that every imperfect codebase should reduce a deal price. The issue is whether the business can keep the promises built into the deal.
Key takeaways for buyers and founders
- An earnout turns future operating performance into part of the purchase price. Technical debt can make those targets harder to hit after close.
- You need to separate normal investment from inherited technology debt that will consume unexpected money, leadership attention, and engineering capacity.
- A useful diligence review produces a costed remediation plan, not a vague statement that the platform needs work.
- The buyer and founder should agree on which post-close costs affect earnout calculations before signing.
- Your first 100 days should stabilize the business, confirm the facts, and sequence the work. It should not become an unplanned rebuild.
Why tech debt acquisitions become earnout disputes
An earnout asks the acquired business to perform after ownership changes. That creates pressure even in a well-run company. Add technical debt, fragile integrations, undocumented processes, or overdue security work, and the argument starts before the first target period ends.
A traditional earnout is a payment tied to future performance criteria, as described in this NYU research on deal structures. The legal definition is straightforward. Running the business through the arrangement rarely is.
The earnout measures outcomes, not effort
A founder may say, “We need six months to modernize the platform.” The buyer may hear, “We need six months before sales growth can resume.”
Neither side is necessarily wrong. The problem is that remediation work competes with product delivery, customer commitments, integration tasks, and the time-to-market pressure built into the growth plan.
If engineers spend half their time fixing brittle infrastructure, they have less time to build customer-facing features. If a core release fails during a migration, sales may lose momentum. If data infrastructure makes reporting unreliable, the parties may not even agree on the metric.
Debt changes the economics after close
Technical debt can turn a projected margin improvement into a higher run rate. You may need more cloud capacity, specialist contractors, replacement software, security controls, unexpected maintenance costs, or retention payments for people who understand the system.
That does not always mean the seller hid a problem. Founder-led businesses often made sensible short-term decisions to win customers or preserve cash. But a shortcut that helped the company reach today’s scale may not support the next stage.
An earnout can fail even when revenue grows, if the technology required to support that growth costs more than the deal model assumed.
The accounting treatment does not settle that business question. Under ASC 805, contingent consideration is measured at fair value on the acquisition date, as outlined in Deloitte’s guidance on contingent consideration. You still need clear operating assumptions behind the earnout.
Separate technical debt from normal investment
Every company has work it would like to improve. That is not automatically technical debt. Buyers should avoid treating routine product investment as a deal defect.
The question is simpler: What will it cost to run, protect, and grow this business after close, including its data infrastructure?
Debt that disrupts the business plan
The most material problems usually fall into a few practical categories:
- Architectural debt, where tightly coupled systems and workflows create operational complexity, making changes slow, expensive, or risky.
- code quality and testing problems, where releases depend on manual checking, heroics, or a small number of engineers.
- infrastructure debt, where aging servers, weak cloud design, limited monitoring, or unreliable backups create operational exposure.
- Security and open-source debt, where unsupported components, unclear software licenses, or weak identity controls create legal or cyber risk.
- Process and data debt, where deployments, reporting, critical workflows, and data infrastructure depend on spreadsheets or tribal knowledge.
Legacy systems deserve context. Age alone is not proof of risk. An older language is not a problem by itself. A profitable COBOL application with reliable documentation and available support may be easier to manage than a newer application built around one contractor’s undocumented scripts. Software intelligence from the live environment can distinguish contained debt from growth-blocking debt.
Look for the cost of delay
Some technical debt can wait. Other debt blocks the deal thesis.
A fragile payment integration is different from a messy internal reporting tool. A missing disaster recovery plan is different from an outdated design pattern. Scalability issues may prevent a platform from supporting the buyer’s growth thesis. You need to know what failures in data infrastructure could interrupt revenue, reporting, or expansion, breach a contract, delay an integration, or force emergency spending.
The cost of delay matters as much as the cost to fix. Some code changes can be sequenced through refactoring instead of treated as an immediate rebuild. A platform problem that prevents a new-market launch creates technical risk and may reduce acquisition value far beyond the engineering invoice.
Price technical debt before signing
A useful technical due diligence assessment converts findings into a deal decision. Its remediation roadmap should identify the work, likely cost, timing, owner, business effect, funding, and whether the item belongs in purchase-price negotiations, the earnout agreement, or the post-close roadmap.
A $200,000 cost can look small in a transaction. At a 12x EBITDA multiple, a rejected $200,000 adjustment can reduce deal valuation by $2.4 million in indicated enterprise value. That discipline matters for private equity firms evaluating add-on acquisitions or platform investments.
Use software intelligence to estimate effort, sequence remediation, and test assumptions before arguing about the headline number.
| Debt item | Fix cost | Business effect | Deal response |
|---|---|---|---|
| Unsupported core component | $150,000 | Raises outage and security exposure | Fund remediation before close or adjust price |
| Fragile customer integration and data infrastructure | $300,000 | Delays growth and integration | Make timing explicit in earnout targets |
| Duplicate software tools | $75,000 exit cost | Creates avoidable spend | Include vendor-offboarding plan |
| Missing automated testing | $250,000 | Slows feature releases | Set a phased remediation milestone |
The point is not false precision. Early estimates will change. The point is to stop treating known technical debt as upside.
For each item, confirm whether reporting, integration, or growth assumptions depend on the data infrastructure. Then choose one of three paths:
- Fix it before close when it threatens revenue, security, or deal completion.
- Carry it with a funded plan when the work is necessary but can be sequenced.
- Delay it deliberately when the risk is contained and the business case does not support immediate work.
A strong software due diligence process, as outlined in this acquisition technology due diligence guide, ties those choices to the investment thesis, not to a generic list of technical improvements.
Make software due diligence test operating reality
A slide deck, architecture diagram, and developer interview are not enough. Software due diligence should test whether the system will perform under new ownership, rather than simply describe intent.
Technical due diligence needs to test what is true in the operating environment.
Ask for evidence, not reassurance
Start with a systems inventory of the tech stack: applications, infrastructure, legacy systems, data infrastructure, data flows, vendors, contracts, code repositories, and key integrations. Identify the people who can keep each part running. Use software intelligence from repository, dependency, deployment, and runtime evidence to validate the map and expose inherited technical debt.
Then test the claims that matter:
- Can the business deploy safely and reverse a failed release?
- Are backups tested against realistic recovery expectations?
- Does the platform have known capacity limits, and has the data infrastructure been tested under load?
- Can leadership trace customer, revenue, and operational data through the data infrastructure to a trusted source, with clear schema management?
- Who owns critical vendor relationships and access rights?
- What breaks if the founder or lead engineer leaves?
This work should include cybersecurity due diligence. Weak access control, unpatched systems, infrastructure debt, untested recovery, and unclear incident ownership can create costs that surface at exactly the wrong time.
An open source composition analysis identifies open-source packages and dependencies in production. It helps you investigate license obligations, unsupported components, and known security vulnerabilities. That review should form part of a software audit covering production code, not only the repository someone remembers to share.
Tie findings to the forecast
A quality of earnings review asks whether EBITDA is sustainable. Technology diligence should ask the matching question: can the business produce that EBITDA without spending more than the model assumes? Software intelligence helps connect technical findings to the forecast, including the cost of maintaining data infrastructure.
Cloud commitments, capitalized development costs, vendor contracts, and founder compensation all need context. Capitalizing software can change when an expense appears in financial statements. It does not make development free, and it does not change the cash that left the business.
Sonar’s research on the cost of technical debt is a useful reminder that code quality problems carry both financial and productivity costs. In an acquisition, that lost capacity becomes part of the deal economics.
Build the first 100 days around facts and ownership
The close is not the finish line. It is when diligence assumptions about technical debt meet the real operating environment.
Your first 100 days should confirm the diligence findings, protect customer operations, and make the next decisions visible. It should not begin with an open-ended software modernization program or uncontrolled refactoring.
Stabilize before you rebuild
Start by securing administrator access, testing backups, documenting critical vendors, confirming incident response contacts, and protecting data infrastructure and revenue-critical workflows.
Next, use software intelligence to validate the biggest operational assumptions. Review actual release frequency, dependencies, system performance, data quality across the data infrastructure, cloud bills, and engineering capacity. The post-close facts may change both the remediation sequence and the earnout conversation.
A practical post-acquisition IT integration plan supports post-acquisition integration by helping you decide what to keep, connect, replace, or retire without disrupting the business.
Give the work a business owner
Engineering can estimate effort. It cannot decide alone whether a six-month delay is acceptable, whether a vendor should be replaced, or whether a customer commitment outweighs a remediation project.
Each material item needs:
- A named executive sponsor who owns the business tradeoff.
- A technology lead who owns the delivery plan and risks.
- A funding decision with a clear source.
- A visible decision on how the cost affects the earnout calculation.
This is where founder-led technology decisions need more structure. The founder may have held the whole operating picture in their head. After close, that knowledge needs to become documented ownership, decision rights, and reporting leaders can trust.
Use technology leadership to keep the deal honest
Technical debt becomes expensive when no one owns the full picture. Finance sees cost in reporting and data infrastructure. Operations feels friction in customer workflows. Engineering sees constraints. The board sees a late surprise.
You need executive technology leadership that connects those facts before they become separate arguments. It should make the state of data infrastructure, ownership, decision rights, and consequences visible to the board.
A fractional CTO can provide ongoing judgment, a 12-month technology roadmap, and stronger technology governance without rushing into a full-time hire. An interim CTO is often a better fit when the leadership seat is open. It can provide immediate control when the acquisition is under pressure.
For cyber-heavy deals, a fractional CISO, virtual CISO, or interim CISO may need to work alongside the technology lead. Board cybersecurity reporting should name the exposure, the owner, the decision required, and the financial or operational consequence.
A business-aligned technology strategy creates business alignment by connecting remediation to margin, customer experience, growth, and risk. It also helps prevent the buyer from funding a technical wish list that no one can defend.
If the technology picture is still scattered, Get an Executive Technology Clarity Check. You should leave with sharper priorities, clearer ownership, and a practical next step.
The deal needs an operating plan, not optimism
Earnouts do not create technical debt. They expose whether the parties priced, funded, and governed it honestly.
The strongest deal teams treat technical debt as a business issue. They test the evidence and build realistic operating and financial assumptions around data infrastructure reliability and capacity. They also agree on post-close work, including remediation funding and clear ownership for data infrastructure as the business grows.
That gives you a fairer earnout, a calmer integration, and confident decisions when the first hard tradeoff arrives.
Frequently asked questions
Should technical debt always reduce the purchase price?
No. Some technical debt is manageable and already reflected in the business plan. Price should change when that debt requires unplanned spending, creates material risk, or prevents the buyer from achieving the deal thesis on the expected timeline.
Can remediation spending be excluded from an earnout calculation?
It can, but only if the agreement is clear. Define which costs qualify, who approves them, how they’re documented, and whether they’re capped. Leaving those decisions until after close creates avoidable conflict.
What should founders prepare before a buyer starts diligence?
Prepare a current systems inventory, key vendor contracts, architecture documentation, code quality evidence, security evidence, backup and recovery records, code ownership details, and a candid list of known debt. A founder who names the problem and shows a credible plan is in a stronger position than one who lets the buyer discover it.