Technical Due Diligence Checklist: Software in the AI Era
Classic technical due diligence answers whether the software works today. That is no longer enough. The questions that decide valuations now are different: can this dev organization absorb AI leverage, can the product be reached by machine customers, and does anything here depend on a distribution channel that is quietly disappearing? This is the checklist we work through when we assess a portfolio company. It is free to read, because a checklist is not the value. Knowing what the answers mean, and fixing what they reveal, is.
A. Architecture & code
-
Does the architecture carry the business plan?
Not "is it modern" but: can it support the next three years of roadmap without a rewrite? Ask for the one diagram everyone agrees on; if it does not exist, that is the finding.
-
Where are the hotspots?
The 5% of the code that receives 50% of the changes. High churn plus high complexity plus one single author is the classic time bomb.
-
Is there a verification loop?
Trusted tests running in CI, fast enough to iterate against. Without it, every future change is slow and risky, and AI agents cannot check their own work, so the productivity upside stays locked.
-
How does software reach production?
Deployment frequency, rollback capability, time from commit to live. Quarterly release trains are a valuation-relevant liability.
B. Team & process
-
Who is irreplaceable?
Key-person risk by module, not by org chart. The one developer who understands billing is a bigger risk than any framework choice.
-
Does the team measure flow?
Throughput and cycle time, tracked and visible. A team that only knows story points cannot tell you (or itself) whether it is getting faster or slower.
-
How does code review actually work?
Review depth, review latency, and whether the process has adapted to AI-generated volume. A two-day review queue caps every other improvement.
-
How long until a new developer ships?
Onboarding time to first production change is the cleanest proxy for hidden complexity and missing documentation.
C. AI readiness of the dev organization
-
Are agents part of the daily workflow, or just licensed?
Tool licenses signal intent; daily agent-written code in production signals capability. Ask for last month's merged PRs, not the tooling budget.
-
Does persistent agent memory exist?
Rules files, CLAUDE.md, encoded conventions that make agents better every week. Their absence means every session starts from zero, and the team has not actually adopted the working model.
-
Is the AI effect measured?
Cycle time before and after adoption. Teams that cannot show the delta are running on enthusiasm, which does not survive the first budget review.
D. Product & strategic exposure
-
Can the product be reached by AI agents?
API access, machine-readable interfaces, transactable flows. A product only a human with a browser can use is on the wrong side of where distribution is moving.
-
How exposed is customer acquisition to AI-driven search shifts?
Share of revenue that depends on organic search referrals: the channel AI answers are actively absorbing.
-
What data is a licensable asset?
Proprietary data an AI company cannot synthesize elsewhere carries pricing power; commodity content does not.
-
Is the security posture agent-aware?
Sandboxing, permission boundaries, and audit trails for AI agents with system access: the incident class of this decade.
A checklist finds the problems. It does not fix them, and that is where most due diligence ends: a report, a discount on the price, and a portfolio company that still ships slowly. We run both halves: the assessment above, then a structured 100-day improvement with the same team, goals set on day 1 and measured on day 80. See PE/VC Assessment & Improvement and the investor FAQ.
NEXT STEP
Assessment to action in 100 days
We assess AND fix: same team, same engagement, measured at day 80.