Start from the investment decision
A useful diligence checklist is not an inventory of everything technical. It is a map from the investment thesis to the evidence capable of changing price, terms, timing, or the post-close plan.
Name the claims
Write down the technical claims material to valuation: scale, reliability, release velocity, security posture, proprietary advantage, AI performance, or low operating burden. Each claim needs an owner and an evidence path.
Define the consequence
For every question, state what a confirmed weakness would change: transaction terms, an evidence request, a closing condition, the Day 1 plan, or no action at all.
Bound the access window
Agree which repositories, cloud views, documents, interviews, and operating records can be inspected before close. Record what remains unavailable so confidence is not overstated.
Verify the product and engineering surface
Code matters, but code without architecture, delivery, and operating context can support the wrong conclusion.
Architecture and maintainability
Map critical services, data flows, integration boundaries, single points of failure, test posture, dependency age, and the cost of changing the system. Distinguish active production paths from abandoned or experimental code.
Delivery and operations
Inspect build and deployment controls, environment separation, observability, incident history, rollback evidence, backup and recovery, and the release path actually used by operators.
Team and concentration
Connect system ownership to the people who can operate and change it. Look for knowledge concentration, undocumented critical paths, hiring assumptions, and dependencies on founders or external vendors.
Connect security, dependencies, and rights
The question is not whether a scanner can find an issue. It is whether the issue is real, material, controlled, and portable into action.
Security control effectiveness
Reconcile stated controls with configuration, workflow, incident, and access evidence. Route penetration testing, certification, and legal conclusions to the qualified specialists who own them.
Dependencies and intellectual property
Identify material open-source, commercial, cloud, data, and AI-provider dependencies. Verify the rights and operating assumptions behind the features central to the thesis.
Technical debt with a consequence
Translate debt into delivery friction, reliability risk, concentration, remediation effort, or integration constraints. A long issue list without a decision consequence is not diligence.
Make the result usable after the meeting
The final record should let an investment committee understand the conclusion and let an operating team own the next move.
Cited findings
Keep the exact source, scope, evidence state, reviewer disposition, and management-claim connection attached to each material finding.
Decision posture
State what is supported, what remains conditional, which gaps could still change the decision, and what must be resolved before close or carried into Day 1.
Day 1 / 30 / 90 ownership
Turn accepted findings into actions with an owner, timing, evidence of completion, and escalation path. Do not let the diligence report become an orphaned PDF.