Speaking Topic: Technical Due Diligence
What a real forensic software audit looks like, and why most due diligence never gets past the slide deck.
When I speak to Private Equity and venture teams on technical due diligence, the throughline is always the same: documentation is theater, and the system under real load is the only witness that matters. Most diligence reports are built from interviews and architecture diagrams the target company wrote about itself. That is not diligence, it is a confession read back to the confessor.
The version I argue for stress-tests database query execution under synthetic peak load, audits the deployment rollback ratio, and measures key-person dependency across tribal runbooks that were never written down. If a platform cannot survive its own engineers taking a two-week vacation, that is the real risk disclosure, not the pitch deck's uptime number.
I also walk audiences through where AI changes the diligence calculus: agentic systems introduce a new liability surface that traditional code review was never built to catch, because the risk is not in the code, it is in what the agent is allowed to do unsupervised.
Key Takeaways
- 01Documentation reviews are not diligence; synthetic peak-load testing is.
- 02Key-person and tribal-runbook dependency is a quantifiable, auditable risk.
- 03Agentic AI systems need a distinct liability audit, not a code review checklist.
Frequently Asked
What does a technical due diligence engagement actually cover?
Forensic audit of software architecture, operational moats, deployment risk, and AI agent liability, stress-tested against synthetic peak load rather than taken from documentation alone.
Who typically books this talk or engagement?
Private Equity firms, venture capital teams, and acquirers evaluating a target company's software durability before capital is committed.
From the Q&A
“Isn't a code review enough before an investment decision?”
No. A code review checks whether code works as written. It does not test whether the platform survives peak load, or whether recovery knowledge exists only in one engineer's head.
“How long does a real forensic audit take versus a documentation review?”
Longer, because synthetic peak-load testing and rollback-ratio audits take real engineering time. The extra days are consistently cheaper than the risk they surface.