Stop Buying Broken Code: How to Quantify Technical Debt in Due Diligence

The Off-Balance-Sheet Liability You Can't See

If you were buying a manufacturing plant, you would inspect the machinery. You would know exactly how much capital expenditure (CAPEX) is required to replace rusting conveyor belts before signing the check. Yet, when Private Equity firms acquire software assets, they often treat the codebase as a black box, assuming "it works" because the demo looked good.

This is a fast track to value destruction. Technical debt is not an engineering complaint; it is a financial liability. According to authoritative research by McKinsey, technical debt can amount to 20-40% of the value of the entire technology estate before depreciation. For a $100M acquisition, that is $20M to $40M of hidden liability that doesn't appear on the balance sheet but will aggressively tax your post-close EBITDA.

We call this the "Tech Debt Tax." It manifests as 10-20% of your new product budget being diverted solely to fixing legacy issues rather than driving growth. When you acquire a company with unassessed technical debt, you aren't just buying software; you are inheriting a high-interest loan that your engineering team pays off hourly, at the expense of your value creation plan.

The Audit: Red Flags and Benchmarks

You need to move beyond subjective CTO interviews and run objective, quantitative code audits. The goal is to translate "spaghetti code" into "cost to remediate." Here are the specific benchmarks and red flags we look for in a technical due diligence (TDD) process.

1. Open Source Risk Exposure

Modern applications are built on open source. The risk lies in unmanaged dependencies. The 2024 Synopsys Open Source Security and Risk Analysis Report found that 74% of codebases contained high-risk vulnerabilities—a massive 54% increase from the previous year. If the target company is running 5-year-old libraries with known exploits, you are buying a cybersecurity breach waiting to happen.

2. The Cyclomatic Complexity Threshold

We measure Cyclomatic Complexity—a quantitative metric of how tangled the code logic is. A healthy score is under 10. Scores over 25 indicate code that is effectively unmaintainable. If a core revenue-generating module has a score of 50+, it cannot be upgraded; it must be rewritten. That is a CAPEX event you must model.

3. The "Bus Factor" and Documentation

Ask this specific question: "If your two lead engineers won the lottery and quit tomorrow, can we ship a release next week?" In many founder-led firms, the answer is no. Tech debt often hides in the form of tribal knowledge. If documentation is missing, the cost of replacing talent isn't just a recruiting fee; it's six months of lost product velocity.

The Action Plan: Adjusting Valuation

Once you have diagnosed the debt, do not just flag it—price it. You must convert engineering findings into a dollar value to adjust the purchase price or structure an earn-out.

• Calculate the Remediation Budget: If the code audit reveals that 30% of the platform requires refactoring to scale, estimate the engineering hours required. If it takes 5 engineers 6 months at a $150k run rate, that is a $375k immediate cost. Add a 50% buffer for integration testing.
• Adjust EBITDA Expectations: If the target claims a 20% EBITDA margin but relies on legacy infrastructure that requires $2M in server maintenance and manual patching annually, their true adjusted EBITDA is significantly lower. Use this data to renegotiate the multiple.
• Demand a "Clean" Bill of Health: For critical security vulnerabilities (like those found in the Synopsys report), require remediation pre-close as a condition of the deal, or hold back escrow funds specifically for this purpose.

The Bottom Line: Technical debt converts your equity into overhead. Don't let a target company pass their sloppy engineering costs onto your balance sheet. Quantify it, price it, and fix it.