The Asset You Underwrote Is the One You Looked At Least
By the time you sign the LOI on a software target, you can recite the net revenue retention, the CAC payback, and the top-five logo concentration from memory. You've role-played the VP of Sales' pipeline math. And then there's the one asset that produces every dollar of that revenue—the codebase—for which your entire evidentiary basis is a CIO interview and a questionnaire the seller filled out about themselves.
That is the trade most deal teams make without noticing: deep rigor on the financial statements, a handshake on the engine that generates them. I have sat in board meetings where an Operating Partner realizes, six months post-close, that the "proprietary AI platform" they just bought is actually a tangled web of GPL-licensed open source libraries they legally cannot monetize the way the thesis assumed. Nobody scanned for it. The questionnaire didn't ask, and the seller wasn't going to volunteer it.
The base rate makes this a near-certainty rather than bad luck. Synopsys' analysis of real production codebases found that 74% of commercial codebases contain high-risk vulnerabilities—meaning the target you're chasing almost certainly carries them too. The variable isn't whether the issues exist. It's whether you've priced them before signing or discover them with your own capital at stake.
The teams that look closely capture it in the deal. McKinsey found that buyers running deep technical due diligence are 2.8x more likely to reach a successful exit—not because they kill more deals, but because they buy the same assets at the right basis. The point of looking under the hood isn't to admire the engineering. It's to know what you're actually buying before the wire goes out.
Four Questions That Move the Number
"Is the code good?" gets you nothing a seller will answer honestly. The questions that matter produce artifacts—a license report, a dependency graph, a deploy log—and each one maps to a line in your model. Here's where, in software specifically, the value hides.
1. Do you actually own what you're buying?
This is the question unique to software, and the one with the largest swing. Run an automated license scan, not a verbal assurance.
- Copyleft contamination: GPL or AGPL components compiled into proprietary code can obligate you to open-source the very IP you're paying a premium for. One contaminated dependency can vaporize the defensibility your thesis is built on.
- Abandoned dependencies: A large share of production codebases run on components many versions out of date. Each one is unpatched security debt you'll inherit and have to fund.
- Secrets in the repo: Cloud keys and database passwords hard-coded into source control. If a contractor with read access ever existed, treat it as already breached.
2. Will the architecture survive your growth thesis?
You underwrote 3x. Ask whether the platform can physically get there.
- The distributed monolith: Services split across the network but so tightly coupled that nothing deploys independently. You pay the operational cost of microservices and get none of the scaling benefit.
- Single points of failure: Name the specific database or service that, if it falls over, takes the entire revenue stream with it. There usually is one.
- Cloud spend leakage: A workload burning $50k/month on infrastructure that should cost $10k is EBITDA walking out the door every month. To turn that gap into a defensible number, see our guide on quantifying technical debt in M&A.
3. Are you buying a platform or renting a team?
Software is built by people, and in a smaller software company the institutional knowledge often lives in two or three heads.
- Bus factor: If the lead architect resigns the week after close, does development stall? Map who is genuinely irreplaceable—then decide whether retention is a deal term, not a hope.
- The deploy gatekeeper: Watch for the one engineer who is the only person who can push to production. That's not seniority; it's a hostage situation you're about to inherit.
- Ramp time: If a new hire takes more than a month to ship their first commit, the codebase is too tangled to scale a team against—which caps how fast you can execute the plan.
The Findings Are Leverage, Not a Veto
The instinct after a rough technical read is to walk. That's usually leaving money on the table. The skilled move is to convert the findings into a price you'd happily pay.
Consider a hypothetical that mirrors how this plays out: a buyer chasing a logistics SaaS platform, where the scan reveals roughly 40% of the core library is deprecated and unsupported, with modernization realistically running well into seven figures over a year-plus. The naive read kills the deal. The disciplined read keeps it—and re-trades the purchase price to absorb the remediation, then writes a technical debt paydown plan into the first 100 days so the work actually gets funded instead of quietly deferred. Same asset, lower basis, a plan in hand. That's what the 2.8x in the McKinsey data actually buys you.
The lines where re-trade becomes walk-away
Most findings are negotiable. A few are structural enough to either crater the price or end the conversation:
- No automated tests, at all: Every fix risks two new regressions. Engineering velocity will collapse the moment your team touches the code, and velocity is the whole point of the buy.
- Active GPL violations in shipped product: A legal exposure that doesn't get cheaper with time. Until it's remediated, the IP isn't fully yours to monetize.
- No documentation and a thin bench: Combined with bus-factor risk, you're not buying a platform—you're leasing the team that happens to understand it. Our breakdown of the diligence mistakes that quietly cost buyers millions walks through how this one compounds.
Do this before signing, while you still have leverage: commission an independent license-and-dependency scan and an architecture review keyed to your growth thesis, and require the seller to grant code access as a condition of exclusivity. Then carry every finding into the model as a number—a price cut, a holdback, or a closing condition—not a footnote. You apply that rigor to the balance sheet as a matter of course. The codebase generates the EBITDA on it; underwrite it the same way.
