The deploy that one person can run
Picture the diligence package on a mid-market SaaS target. The technical due diligence report is immaculate: clean codebase, no critical CVEs in the dependency scan, sensible AWS architecture, a defensible algorithm the investment committee fell in love with. Everyone signs off on the technology. The deal closes.
Five months later, the lead engineer takes a job at a competitor. And the company discovers that production deployment is a 4-hour ritual that lives entirely in that one person's head — a sequence of manual steps, a config file edited by hand, a "wait for the cache to warm before you flip the flag" step that was never written down anywhere. The roadmap freezes. Engineering asks for a 30% budget bump just to keep shipping at the old pace.
None of that was a code problem. The code was fine. Technical due diligence answered the questions it's designed to answer — is it secure, is it scalable, does it infringe anyone's IP? — and answered them honestly. What it never asked was the operating question: can a stranger run this thing on a Tuesday without the person who built it?
That is the line between the two diligence disciplines, and most PE deal teams never see it because they only buy one of them. Technical diligence audits the artifact. Operational diligence audits the factory that produces the artifact. You can ship a beautiful product through a factory that runs on heroics — right up until the hero leaves. Technical debt shows up on a scan; operational debt shows up in your hold-period EBITDA, one painful month at a time.
Two kinds of debt, and the scanner only finds one
McKinsey's research puts a number on the visible half: CIOs estimate that technical debt amounts to 20-40% of the value of the entire technology estate. The trap for a sponsor is assuming a clean code scan means you've sized that liability. It hasn't. A scanner reads what's in the repository. It is structurally blind to everything that happens around the repository.
Split the diligence into the two debts and the gap becomes obvious:
- Static debt — what TDD sees: dead libraries, brittle modules, security holes, license exposure. Real, findable, and the thing you're already paying a Big 4 team to chase.
- Operational debt — what TDD walks past: no CI/CD, no automated tests, a deploy process exactly one human understands, infrastructure provisioned by clicking around a console, releases that ship quarterly because nobody trusts the build.
Operational debt is the more dangerous half precisely because it doesn't appear in any artifact you scanned. And it compounds. Harvard Business Review's M&A work found that around 70% of acquisitions fail to deliver the synergies the model assumed — and a large share of that failure is operating-model collision, not strategy. If the target deploys quarterly and your platform company deploys daily, you didn't buy a bolt-on. You bought a merge conflict between two release cadences, and someone has to spend the next year reconciling them.
The governance layer makes it worse before it gets better. Gartner expects 80% of data and analytics governance initiatives to fail by 2027 — usually because the org never built the operating discipline to sustain them. Same root cause as the stalled deploy: process debt that no code review surfaces. Here's the concrete version. Say a target's QA looks "automated" on the org chart, but operational diligence finds it's actually five manual testers in a low-cost region, with the cost buried in COGS rather than R&D. That's not a quality finding. It's a margin finding — a recurring labor line you priced as scalable software when it's headcount that grows linearly with revenue.
The diligence questions that actually move the price
Operational reality doesn't surface from the questions on a standard TDD checklist, because those questions invite rehearsed answers. "Is the code documented?" gets you a yes. The follow-up that gets you the truth is sharper. Swap the surface question for the operating one in your next data-room session:
- Not "is the code documented?" but "could a new tech lead deploy to production within 24 hours using only what's written down?" If the answer involves a name, you've found a single point of failure.
- Not "what's your test coverage?" but "what share of an average developer's week goes to firefighting regressions versus building new things?" The ratio is your real velocity tax.
- Not "are you agile?" but "pull the cycle-time data from your last three sprints — how long does a ticket sit in code review?" A queue that won't move tells you where the org is actually bottlenecked.
When you find heavy operational debt, you usually don't walk — you reprice and re-sequence. The fix in the first 100 days is to mend the factory, not the product. Stand up a CI/CD pipeline before anyone refactors a legacy module. Automate the deploy before you rewrite the frontend. A company that ships predictable revenue through messy code is sellable; a company that needs a specific human awake to keep the servers running is not, and your eventual buyer will run the same diligence you should have. That sequencing is the heart of treating diligence as operational engineering, and it's where the margin you underwrote either materializes or quietly leaks away.
Technical diligence prices the risk of a breach. Operational diligence prices the risk of execution failure — and in a market where multiple expansion is no longer doing the work for you, execution is the lever you've got left. Before the next IC date, make sure someone in your diligence stack owns the operating question, not just the code question.
