Software & AI technical due diligence checklist
A technical evidence checklist for investors assessing a software or AI company across product, architecture, team, security, data, economics and execution risk.
· Practical guide · ZeroFoldA long checklist does not create good diligence. The scope should be driven by the technical and operating claims under examination, their materiality and the evidence required to test them.
Start with the technical questions and operating case.
Write down the technical assumptions beneath scalability, reliability, defensibility, product expansion and integration. Rank them by technical materiality and uncertainty. This determines where interviews, demonstrations, code review, architecture evidence and specialist testing deserve time.
The output should explain what is known, what is inferred, what remains unverified and what each point changes for remediation, integration or the post-close operating plan. The client and its licensed advisers retain every investment, valuation and transaction conclusion.
Seven workstreams to examine.
Product
Maturity, customer-critical workflows, roadmap credibility, release evidence and dependence on manual operations.
Architecture
System boundaries, scalability, reliability, technical debt, third-party dependencies and credible modernisation needs.
Engineering
Team depth, key-person risk, development velocity, testing, documentation, incident learning and delivery leadership.
Security
Identity, data protection, vulnerabilities, monitoring, incident response and material customer or regulatory exposure.
Data
Ownership, provenance, quality, governance, access, portability and whether the data asset creates real advantage.
AI
Model role, evaluation quality, failure modes, human controls, unit economics, vendor dependence and replication risk.
Execution
Budget, people, sequence and dependencies required for the technology to meet the stated operating case after close.
Evidence to request.
- Product demonstration against representative customer workflows and failure cases.
- Architecture and data-flow views grounded in the deployed environment.
- Repository, delivery-pipeline, incident, reliability and security evidence proportionate to the risk.
- Roadmap, backlog and team interviews that explain how priorities become releases.
- AI evaluation results, model and data dependencies, inference costs and human-review controls.
- Material contracts or supplier dependencies that constrain portability, cost or continuity.
Absence of a document is not automatically a red flag. The question is whether the organisation can produce credible operational evidence appropriate to its stage, customers and claims.
Common findings that change the ownership plan.
| Finding | Why it matters | Possible response |
|---|---|---|
| One person holds critical context | Continuity and roadmap execution depend on retention. | Retention plan, documentation and leadership depth. |
| AI claims lack representative evaluation | Quality and economics may not hold in real use. | Technical validation and controlled deployment gates. |
| Architecture scales only through manual intervention | Growth may increase cost and operational risk faster than revenue. | Capacity plan and sequenced platform investment. |
| Security controls lag customer expectations | Sales, insurance and incident exposure may expand the remediation scope. | Immediate controls and a funded remediation roadmap. |
This checklist concerns technical evidence only. It does not recommend whether to acquire, dispose of or hold an investment; value a business or financial product; arrange a transaction or fundraising; or deal in securities. Those conclusions remain with the client and its appropriately licensed or qualified advisers.