A checklist is only useful if each item has a consequence attached. This one is ordered by what actually changes a deal.
Ownership and dependencies
Product and operations
Remediation and decision
Use this as a working document during diligence. Each section states what to request, what to verify, and — critically — what a bad answer means commercially. Items are ordered by cost of being wrong, not by convenience of checking.
Before you start: what to request
- Read access to all repositories, including infrastructure-as-code
- Full commit history (not a squashed snapshot — history reveals who really built this and how fast they move)
- Architecture walkthrough with the engineer who built it, 1-2 hours
- Access to the issue tracker and any incident records
- List of third-party services and their contract terms
- Contractor agreements and IP assignment documents
Section 1 — Money and data integrity (deal-level)
| Check | Bad answer means |
|---|---|
| Balances derived from an append-only ledger? | Money can be silently wrong and is unrecoverable — fund remediation or walk |
| Idempotency keys on every payment path? | Retries can double-charge; losses may already exist undetected |
| Money stored as integers in minor units? | Float arithmetic accumulates error across every transaction |
| Reconciliation against provider settlement? | Discrepancies surface via customer complaints |
| Immutable audit trail incl. admin actions? | Cannot answer regulator or dispute questions |
Section 2 — Security and tenancy (deal-level)
- Authorization enforced server-side on every request, not by hiding UI elements
- Multi-tenant isolation verified by test, not assumed from code reading
- Secrets in a manager, absent from git history (check history, not just HEAD)
- What regulated data is stored, where, and whether it needs to be
- Gap to the certification the go-to-market requires (SOC 2, ISO 27001, PCI DSS)
Section 3 — Ownership and legal (deal-level)
- Signed IP assignment from every contractor and founder
- Open-source licence review — copyleft contamination in a proprietary product
- Any code copied from previous employers (ask directly; it happens)
- Vendor lock-in: what breaks if a key provider reprices or shuts down
Section 4 — Architecture and scale (high)
- Where the system breaks under the growth in the financial model — a specific number, not reassurance
- The data layer ceiling: single write master, unbounded queries, index coverage against real query patterns
- Failure isolation: does one slow dependency cascade into full outage
- Infrastructure cost curve at 10x — does unit economics survive
- Architecture matched to team size (distributed systems with a small team is a cost, not a credential)
Section 5 — Delivery capability (high)
| Signal | Healthy | Concerning |
|---|---|---|
| Deployment frequency | Multiple times per week | Monthly, scheduled, feared |
| Lead time for small change | Hours to a day | Weeks |
| Rollback | One command, rehearsed | Never tested |
| Incident detection | Internal monitoring | Customer reports |
| Tests on money/auth paths | Present | Absent regardless of overall coverage |
Section 6 — Team and key-person risk (high)
- Bus factor on each critical subsystem — if any is 1, that is a deal risk requiring mitigation
- Whether knowledge exists in writing or only in heads
- Retention exposure: who would be catastrophic to lose in the next 12 months
- Realism of the hiring plan the roadmap assumes
Scoring: consequence, not taste
Score each finding on what happens if it is not fixed, and let that drive the deal response:
- Deal-level — money integrity, data exposure, unclear IP. Closing condition or funded remediation.
- High — scaling ceiling below the plan, single-person dependency, no deployment safety. Costed into the 90-day post-close plan.
- Medium — compounding debt that slows delivery. Note and monitor.
- Noise — style, framework preference, documentation volume. Exclude from the report entirely.
If a finding cannot be tied to money, time, or legal exposure, it does not belong in an investment memo.
What to insist on in the final report
- A one-page summary a non-technical partner can act on
- Every finding with evidence the target's team can independently verify
- Remediation estimates in engineer-weeks, so they convert to money
- An explicit statement of what was NOT examined — so nobody assumes coverage that did not happen
Turn the checklist into a decision record
A due diligence checklist is useful when each answer can be traced to evidence and a transaction consequence. Agree the review boundary, access and questions before collecting documents. Keep verified findings, management statements and unavailable evidence distinct; a blank cell is not evidence of low risk.
| Make the decision measurable | Evidence to agree before work starts |
|---|---|
| Ownership and dependencies | Request repository history, contributor agreements and a dependency inventory. Legal counsel validates legal rights; technical review tests the consistency of the evidence. |
| Product and operations | Trace a material user journey, review deployment and recovery evidence, and compare the architecture with the stated growth assumptions. |
| Remediation and decision | Attach an owner, effort range, dependency and verification step to each material finding. Separate pre-close conditions from a post-close plan. |
The final report should say what was inspected, what remains unknown and what could change the investment decision. A document review alone does not establish that security controls work in production, and a technical review is not a legal certification.
Frequently asked questions
What should be included in a technical due diligence checklist?
Six areas, in order of consequence: money and data integrity, security and tenant isolation, IP ownership, architecture and scaling headroom, delivery capability, and key-person risk. Each item should have a stated commercial consequence — a checklist without consequences produces reports nobody acts on.
What is the most commonly missed item?
IP assignment from contractors. It is not a technical question, so technical reviewers skip it and legal reviewers assume engineering covered it. It also has the longest lead time to fix, which is why it should be checked in the first days rather than the last.
Can founders use this checklist themselves?
Yes, and it is a good idea before raising. Findings you discover yourself become a remediation plan you control; the same findings discovered by an investor's advisor become a negotiating position against you.
Want this run by someone who does it weekly?
We deliver diligence with findings ranked by business consequence and remediation priced in engineer-weeks.
Further reading
Technical Due Diligence for Investors: The Complete Guide
Technical due diligence is not a code review. It is an answer to one question: what will it cost to get this technology where the investment thesis needs it to be?
What VCs Actually Look For in Technical Due Diligence
Investors are not grading your code. They are pricing the risk that technology stops the plan they are funding — and founders who understand that prepare very differently.