Technical due diligence at seed stage, when there is barely a product
Technical due diligence on an early stage startup sounds like a contradiction. There are eight thousand lines of code, no scale, no security posture to speak of, and half the product still lives on a whiteboard. What is there to audit?
Quite a lot, as it turns out, but not the usual things. At pre-seed and seed, what you underwrite is a team’s judgment and whether the thesis can be built. The audit shifts from "what did they build" to "how do they decide, how fast do they move, and can the thing they are promising be built at all". Those questions have evidence behind them even when the product barely exists, and the evidence fits in a day or two of work.
What to skip, deliberately
Half the value of early stage technical diligence is knowing what not to assess, because running the full playbook on a seed company produces noise dressed as findings.
Skip the scalability review: nothing at this stage should be built for scale, and finding "this will not hold at 10x" means the founders spent their time correctly. Skip the technical debt inventory: debt at seed is rational borrowing, and a pristine codebase before product-market fit can even be a warning about priorities. Skip the compliance and certification checklist for the same reason.
The rule for what remains: assess only what is expensive to change later. Data model choices, the shape of the core abstraction, anything touching how customer data is stored. Those decisions calcify. The rest can be refactored once the company has found its market.
Architecture choices as evidence of judgment
What the early codebase does reveal, and reveals well, is how the founders make decisions under uncertainty. The architecture is a record of judgment calls, and you can read them.
A boring stack chosen for speed, one well-known database, managed infrastructure, no invented frameworks: that is a team spending its novelty budget on the product. The opposite pattern, a distributed system with five services for a product with ten users, or a bespoke framework where a library existed, tells you the team optimizes for engineering aesthetics over survival. At this stage we would rather see ugly pragmatism than beautiful over-engineering, every time.
The second thing we read is velocity, because at seed the repo is mostly a record of pace. Three months of commit history answers questions no pitch deck can: how often working software lands, whether the pace holds or comes in heroic bursts, what happens after a hard problem appears. A team that ships steadily through difficulty is demonstrating the capability the whole investment depends on.
Can the AI thesis be built at all
For AI companies, one question at this stage outranks all others, and a generalist review is poorly equipped to answer it: can the claimed capability be built, or does the pitch quietly assume a research breakthrough?
The demo always works, so we look underneath it. What does the impressive path depend on, and what happens on inputs the demo never sees? What data does the thesis need, and does the team have a credible route to it? "We will fine-tune on customer data" is a plan only if customers will grant those rights and the data exists in usable form. And is the differentiation durable, or is it a feature the next model release absorbs? We treat that last question fully in evaluating an AI moat when the models are everyone’s.
The distinction that matters is hard engineering versus open research. Hard engineering means the path exists and costs effort; a seed team can walk it. Open research means nobody has done it and it might not work. That is a different risk class, and the investor should know which one it is buying. Founders are usually candid about this when the question is specific.
The team, weighted double
At this stage the team assessment is half of the audit. Who wrote the system, and is the technical depth in the room or in a contractor who has already left? Can the technical founder explain every major decision and its alternatives, fluently, without defensiveness? Have they scoped what they will need to hire, and is that plan realistic for their geography and their cash?
The red flags are the classic ones, but their weight doubles because there is little else to assess. A seed company is its people plus a head start, so a founding team that cannot navigate its own code, or an outsourced core with no plan to bring it in-house, is a finding of the first order, in the same family we rank in the red flags that matter.
What early stage technical due diligence looks like in practice
A seed-stage technical read is short by design: a day or two, most of it in conversation. A repo walk with the founder, an architecture discussion built on "why" rather than "what", a hard look at the AI claims, references where the team has a past. The deliverable is a two-page memo rather than a forty-page report: thesis buildable or not, quality of judgment, the two or three risks worth watching, and what the next round’s diligence should verify.
It is a different exercise from a growth-stage audit, and it should be scoped and priced as one, a distinction we unpack in what AI due diligence is and when you need one. When a fund brings us a company this young, we run this compressed read as a technical and AI audit sized to the check: enough evidence to invest with open eyes, and nothing padded on top.