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.

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.

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 50-point checklists floating around 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.