Technical Due Diligence Before Series A: 2026 Checklist

Technical Due Diligence Before Series A: 2026 Checklist

Technical due diligence for AI startups in 2026 checks more than code quality. Investors want to know who owns the code, whether the team can explain what AI wrote, which models you depend on, what inference costs per user, where your data comes from, and whether security basics and SOC 2 are in motion. Most of it can be prepared in 30 days.

This post is for founders heading into a seed or Series A raise, especially with a codebase that Claude Code, Cursor or Lovable wrote a lot of. It covers what reviewers look at, which findings move the price and which just go on a fix list, a 30-day self-audit plan and a data room checklist.

The sources are practitioner and vendor views (including ours), not regulation. Investors differ. Treat this as a map of what is commonly asked, not a guarantee of what your investor will ask.

What do investors check in tech due diligence before Series A?

Justin McKelvey’s 2026 guide breaks a review into eight areas, which is a useful frame for tech due diligence before Series A:

For AI products, AKF Partners adds the AI-specific layer: whether your models are differentiated or easy to replicate, where training data comes from and how it is governed, quality metrics over time, how you monitor drift, GPU and inference cost as usage grows, dependence on third-party model APIs, and AI-specific threats like data poisoning. AKF also notes that deal timelines have “compressed from months to weeks,” which leaves less room to fix things mid-process.

AI code provenance: can the team explain the code?

This is the 2026 addition, and it is the one founders worry about most. The good news: reviewers are not penalising you for using AI. McKelvey’s central point is that the real question is whether people can explain the code, not whether AI wrote it.

So AI code provenance due diligence comes down to three things you can prepare: a short note on which tools you use and how changes are reviewed, evidence of review (PRs, tests, a spec), and a founder or engineer who can walk through authentication, billing and data handling without opening the AI chat history. Our post on vibe coding vs AI-native engineering covers the difference investors are really probing for, and spec-driven development is the simplest way to leave a reviewable trail.

IP and code ownership

BeevR’s seed DD guide calls code and IP ownership the red flag that “kills deals” and sets the passing standard plainly: the founder owns 100% of the IP and the GitHub repo. In practice that means signed IP assignment from every contractor and agency, the repo in a company-owned org, and cloud accounts in the company’s name.

Model dependencies and inference unit economics

Expect “API or self-hosted, and why?” and “what does a user cost you to serve?” BeevR lists inference cost per user and gross margin at scale as core seed questions, alongside a clear evaluation method (“benchmarks, not vibes”). If you cannot say what an active user costs in tokens per month, work it out before the raise. Our guide to cutting LLM costs shows where the usual savings hide.

Data sources and rights

Where did your training, fine-tuning or retrieval data come from, and do you have the right to use it commercially? BeevR and AKF both put documented data provenance near the top. A thin wrapper on someone else’s model with no proprietary data or workflow is a valuation question, not just a technical one.

Security basics and SOC 2

Security reviewers look for the boring things: MFA on everything, least-privilege access, dependency scanning, encryption, logging. BeevR claims SOC 2 (at least a Type I, or visibly underway) is now expected at seed rather than at Series A for AI startups selling to enterprises. That is one vendor’s view, but if your buyers are enterprises it matches what their procurement teams send you anyway.

Which findings reprice a deal and which are just fix-it items?

Not every finding is equal. McKelvey’s split is the clearest we have seen:

To that list we would add one more: a reinitialised repo history. If your git history starts three weeks ago with a single “initial commit” containing the whole product, a reviewer cannot see how the code evolved, who wrote it, or whether secrets were removed properly. It looks like something is being hidden even when nothing is. Keep the real history; clean secrets out of it properly instead.

Why the split matters: AxonBuild’s 2026 review of 26 AI-built apps found most issues were missing code rather than wrong code, and noted that reviewers treat a defect as having a severity, while an absence can lead them to judge the team. A known issue on a written list reads as maturity. The same issue found by the reviewer reads as a surprise.

AxonBuild’s sample is small and self-published, but the patterns are worth checking: at least 18 of 21 third-party apps had no working test, 9 of 26 ran a framework version with a known, reachable remote code execution or auth bypass, and 8 of the 14 apps with an AI feature let untrusted user text reach the model as an instruction.

What does a 30-day pre-raise self-audit look like?

Here is a plan a founder and one engineer can run before opening the data room.

Week 1: ownership and secrets

• Move the repo, cloud accounts, domains and app store listings into company-owned accounts.
• Collect signed IP assignment from every contractor, agency and early helper.
• Scan the full git history for secrets (not just the current tree) and rotate anything found. Purge it from history properly rather than starting a fresh repo.
• Run a licence scan on dependencies and flag anything copyleft (GPL, AGPL) in shipped code.

Week 2: the money path and auth

• Confirm authentication and authorisation happen on the server, never only in the browser.
• Run AxonBuild’s two-account test: create two users and try to open one’s records while signed in as the other.
• Write tests for signup, payment and a user viewing their own data. Three good tests beat zero.
• Make sure at least two people can explain auth, billing and data writes.

Week 3: AI and cost

• Document every model and provider you depend on, and what you would do if one changed pricing or terms.
• Calculate inference cost per active user and per key action.
• Put spend limits and rate limits on AI endpoints so a stranger cannot burn your model budget.
• Write a one-page note on how you evaluate output quality, with a small eval set.

Week 4: security, compliance and the story

• Update the framework and dependencies with known critical issues.
• Turn on error tracking and basic logging if you have not.
• If you sell to enterprises, start SOC 2 readiness and get an external pentest from a team like pentest.ae.
• Write the known-issues list with a fix plan. Then rehearse a 30-minute architecture walkthrough.

If week 1 or 2 turns up more than you expected, a vibe code audit gives you a senior second pair of eyes on an AI-built codebase before an investor’s reviewer gets there.

What goes in a technical due diligence data room?

None of our four sources publishes a single standard list, so this is our working technical due diligence checklist 2026, built from the areas they all check:

• Architecture diagram (one page) and a short system description
• Repo access (read-only) for the reviewer, with real history
• List of models, providers and third-party APIs, with contracts or terms
• Inference and infrastructure cost for the last 3-6 months, plus cost per active user
• AI tooling and review policy: which tools, how changes are reviewed, provenance note
• Evaluation method and recent quality results for AI features
• Data inventory: sources, rights to use, PII held, where it lives, retention and deletion
• IP assignments from founders, employees and contractors
• Dependency licence report or SBOM
• Security summary: MFA, access control, scanning, latest pentest report
• SOC 2 or ISO 27001 status and timeline, if relevant (our devsecops team covers readiness)
• Incident history and how each was handled
• Team map: who owns which critical system, and the hiring plan
• Known issues list with a fix plan and dates

Who should run the self-audit?

If you have a strong technical cofounder, they can run most of this with the checklist above. If you are a solo founder or your technical lead built most of it with AI agents, get an outside reviewer first. Their job is to find what the investor’s reviewer will find, while you still have time to fix it.

That is part of our fractional AI CTO work: a named principal architect, Adrian Vale, leads raise-ready prep, backed by the NomadX practice team across AI engineering, security, Kubernetes, QA and FinOps. For the cost side of that decision, see our breakdown of fractional CTO cost in 2026.