The 7-area technical due diligence checklist investors actually use

When a fund asks me to run technical due diligence on a startup, they are not paying me to read every line of code. They are paying me to answer five questions. Can this team ship the roadmap they just pitched? Will the architecture survive the growth the deck promises? Is there a security or data liability that becomes the investor's problem at the worst possible moment? Does the company actually own its IP? And — new since 2025 — how much of this codebase was generated by AI, and can anyone on the team explain it?

That is the entire checklist, compressed. Everything below is the expanded version: the seven areas I examine when a seed or Series A investor sends me a deal, the red flags that actually kill or reprice transactions, and what the process costs. If you are an investor, steal it. If you are a founder about to raise, read it as a preview of your next data room request.

What is technical due diligence, really?

Technical DD is not an audit. It is a risk-pricing exercise. The investor already likes the market and the team — otherwise nobody is paying for diligence — and now needs to know whether the technology supports the valuation or quietly undermines it. The output is a decision: invest, invest with conditions, or pass.

Most DD reports fail this test. They are sixty pages of tool screenshots — dependency scans, coverage percentages, lint warnings — that no partner reads. In practice, deals die or reprice on a handful of findings, and those findings almost never come from a scanner. They come from asking the right five people the right uncomfortable questions. Bain & Company's 2026 M&A report found that one in five dealmakers walked away from a transaction over AI-related risk alone, and FE International's 2026 analysis puts the valuation haircut from technical and regulatory risk in AI businesses at 15–30% of the multiple. The money at stake is not theoretical.

What does the checklist actually cover?

Seven areas. Weight them by stage — at pre-seed, the team section is 60% of the answer; by Series A, security and unit economics carry far more.

How is this different from a long technical due diligence checklist?

The current SERP is full of exhaustive documents: Papermark advertises a 25-document investment diligence list, ZTABS has a 54-item technical DD checklist, and several agency pages split the work into architecture, code quality, security, team, process, and compliance sub-items. Those lists are useful for making sure the data room is complete. They are not how an investor should price risk.

For a seed or Series A deal, I compress the long list into seven decisions: who owns the system, whether the architecture fits the next 18 months, whether the team can ship safely, what security/data liability exists, whether IP is clean, what one customer costs to serve, and whether the AI layer is supervised. If an extra checklist item does not change one of those seven answers, it belongs in the appendix, not the partner memo.

1. Team before code: who actually built this?

The first thing I establish is bus factor. Who wrote the core system, are they still around, and can the people who remain explain the decisions? A codebase built entirely by a departed contractor or an agency, with no in-house engineer who understands it, is the single most common fatal finding at seed. I ask founders to walk me through one architectural trade-off they made and one they regret. Strong teams answer in seconds; teams that outsourced their thinking cannot.

2. Architecture: is it right-sized for the next 18 months?

I am not checking whether it is microservices. I am checking whether the architecture fits the roadmap the investor was just pitched. Over-engineering is as damning as under-engineering: eleven services and a Kubernetes cluster for 200 users tells me the team optimizes for résumés, not customers. A boring monolith on Postgres that deploys in minutes is usually the right answer at this stage, and I say so in reports.

3. Code quality and delivery: how often do they ship?

I do not ask for test coverage numbers; they are trivially gamed. I ask for deploy logs. A team that deploys daily with a working CI pipeline and reviews its pull requests has engineering discipline, whatever the code looks like. A team that deploys monthly because everyone is scared of production has none, whatever the coverage report says. Tests on the money paths — billing, auth, data writes — matter; tests written to hit a percentage do not.

4. Security and data: what leaks, and who can access what?

The basics catch most offenders: secrets committed to the repo (including in git history), shared admin credentials, no offboarding process, production PII copied into staging. For anything handling personal data I map what is collected against GDPR and, for UAE companies, the PDPL. I have seen a term sheet repriced because customer data sat in an unsecured S3 bucket — a ten-minute finding.

5. IP and licensing: does the company own what it is selling?

Three checks: signed IP assignment from every contractor and employee who touched the code; an open-source license inventory (AGPL inside a proprietary SaaS is a real conversation with lawyers); and, for AI products, clarity on training data provenance and whether model outputs can even be claimed as IP. Contractor IP assignment is missing more often than any founder expects — especially where early work went through freelancers on three continents.

6. Infrastructure and unit economics: what does one customer cost?

Cloud spend per active user, and for AI products, token spend per user action. In 2026 the second number is where gross margins go to die. If nobody on the team can tell me the model API cost of their most common workflow, the pitch-deck margin is fiction. I rebuild the number from billing dashboards during DD — it takes an hour and has changed investment terms more than once.

7. The AI layer: evals, dependency, and injection

For AI products I add three checks: evaluation discipline (do they measure output quality with anything beyond vibes — the eval-first approach I laid out in how to scope an AI MVP that ships in 30 days), model dependency (is the product one provider deprecation away from a rewrite), and prompt-injection exposure for anything that touches user data or takes actions on a user's behalf.

What changed in 2026: the AI-generated code question

Andrej Karpathy coined "vibe coding" in February 2025. Within a year it stopped being a meme and became a diligence workstream. Roughly a quarter of Y Combinator's Winter 2025 batch reported codebases that were about 95% AI-generated, and by 2026 close to half of new code industry-wide is machine-written. Meanwhile Veracode's 2025 GenAI code security research found 45% of AI-generated code contains security flaws.

So the question investors now ask is not "did you use AI to write this?" — everyone does, including me. The question is: how much of this codebase can your team explain? What review process sits between the model and production? Where are the tests that would catch a confidently wrong function? A 95%-AI-generated codebase with strong evals, review discipline, and an architecture the founders can defend on a whiteboard is fine. The same codebase where the honest answer is "it works, we're not sure why" is uninvestable at any meaningful valuation.

How should investors evaluate an AI-generated codebase?

Do not turn the percentage of AI-written code into a score. Treat it as a prompt to demand evidence that a human team still owns the system. For an investor data room, I ask for five control packets:

1. Human ownership. Name the engineer accountable for each critical service. Have that person explain one AI-assisted change from issue to architecture decision, review, test, deploy, and rollback. If nobody can defend the trade-offs without reopening the coding assistant, the company does not yet own the implementation.
2. Critical-path assurance. Show review history, automated tests, deployment records, rollback evidence, and production incidents for auth, billing, data writes, and any workflow that can act on a customer's behalf. Generated tests that only restate generated code are not independent evidence.
3. Dependency, licence, and supply-chain controls. Provide lockfiles, a dependency and licence inventory, update policy, branch protection, and release provenance. OpenSSF Scorecard is a useful automated baseline for open-source security practices, but its own documentation warns that the checks are heuristics, not a one-size-fits-all verdict.
4. Model, data, and evaluation evidence. If AI is part of the product—not only the coding workflow—include the model/provider inventory, training or retrieval-data rights, evaluation set and results, known failure modes, latency, and cost per core workflow. NIST's Generative AI Profile is a cross-sector baseline for bringing trustworthiness into design, development, use, and evaluation.
5. Agent boundaries. For systems that call tools or touch customer data, show prompt-injection tests, least-privilege tool permissions, secret isolation, audit logs, spending limits, and where a human must approve an action. Use the current OWASP GenAI LLM Top 10 2026 as a threat checklist, not as a security certificate.

That packet lets an investor separate fast teams using AI responsibly from products whose apparent velocity is borrowed from controls they have not built. It also makes remediation estimable: missing evidence becomes a named workstream, owner, and cost rather than a vague "AI risk" discount.

What red flags actually kill deals?

• Bus factor of one. The system lives in one contractor's head, and the contractor is not part of the deal.
• Fear of deploys. Shipping less than weekly at seed stage, because every release is an event with a rollback plan and a prayer.
• License contamination. Copyleft code inside the proprietary core, discovered by the acquirer's lawyers instead of the founders.
• Secrets and PII in the repo. Especially in history — deleting the file last week does not delete the key.
• The demo–production gap. An AI product with a great demo, no evals, and no idea what its failure rate is on real inputs.
• Founders who cannot answer "what breaks at 10× load?" The answer can be wrong; having no answer is the flag.

Equally important is what does not kill deals: ugly code, honest tech debt with a plan, a boring stack, a monolith. I have never written "pass" over ugly code. I have written it over ugly ownership.

What do investors NOT look at?

Half the anxiety founders bring into DD is spent on things no serious reviewer weighs. Nobody prices your test coverage percentage (gameable in an afternoon), your code style, whether you picked React or Vue, how current your framework versions are, or the fact that you run a monolith out of one repo. The long checklist pages floating around often grade exactly those items, because line items justify invoices. Seven areas is the whole game: ownership, architecture fit, delivery cadence, security, IP, unit economics, and supervision of the AI layer. How VCs actually read a codebase deserves its own post, but the compressed version is this: they read the team through the code, not the code itself.

How long does technical due diligence take, and what does it cost?

For a seed-stage company: three to five working days of actual work, spread over one to two weeks — repo and infrastructure access, two or three hours of interviews with the founders and senior engineers, an architecture walkthrough, and a written report with a clear recommendation. Series A, with more surface area and compliance questions, runs two to three weeks. Anyone quoting six weeks for a seed-stage DD is billing, not diligencing.

Cost: an independent senior practitioner typically charges USD 4k–15k (roughly AED 15k–55k) depending on depth; consultancy firms charge a multiple of that for a longer document with the same three findings that matter. What I run for funds is the practitioner version — details are on my services page. The economics only make sense because the person reading the code has also written and shipped it at scale.

How should founders prepare?

Flip the checklist and you have your data room. Before you raise, assemble: read-only repo access, a one-page architecture diagram, a dependency and license inventory, a security one-pager (access control, secrets handling, data map), a team map showing who owns what, a cost-per-user dashboard, and eval results for any AI feature. If producing this takes more than a week, that delay is itself the finding — and every question an investor has to chase becomes a discount.

And if reading that list made it obvious that nobody senior owns your technology, fix that before diligence rather than during it. That gap is exactly what a fractional CTO in Dubai exists to close — a few days a month of someone who has sat on both sides of the DD table is the difference between diligence as a formality and diligence as a repricing event.

The bottom line

Technical due diligence is judgment, not tooling. Scanners find lint; interviews find liabilities. The checklist above prices the only risks that consistently move deals: whether the team understands its own system, whether the architecture fits the promise, whether the data and IP are clean, and — in 2026 — whether the AI that wrote the code is supervised by anyone who can explain it.

Related: if the AI feature is the product, the AI MVP scoping guide covers the eval set and cost instrumentation this checklist expects to find. If the codebase was agency-built, how founders keep a dev agency honest shows the paper trail this checklist hopes to see. If the target runs on an external CTO arrangement, CTO as a service in Dubai explains how those engagements are structured and priced.