Investors read your codebase now
A demo answers 'does it work'. Diligence answers 'can you keep it working', and that question has a paper trail.
The short version
4 things that decide this
- 01Many funds now send an engineer or a technical advisor into the repository before a term sheet. It is no longer only a partner reading the deck.
- 02Commit history is the first thing checked. One person, one giant commit, or a repository created the week before the raise all read as risk.
- 03A codebase with no tests, no CI, and no record of who has access is treated as a liability on the cap table, even if the demo works.
- 04Generated code is not the problem. Unreviewed generated code with no one able to explain a decision in it is.
Why the deck stopped being enough
A pitch deck used to be the whole technical review. A working demo on a call was proof enough that the product existed. Two things broke that pattern.
First, AI coding tools made it possible to produce a convincing demo in days. A working screen no longer signals months of engineering behind it. Second, more funds now keep a technical partner or a network of contract engineers. Their job is to open the repository before money moves. A demo shows what the product does. A repository shows how it was built, and those are different questions.
What a technical review actually looks at
The review is short, usually a few hours, and it follows a fairly fixed order. None of it requires reading every line of the product.
- 01Commit history: a real history of incremental work, or one person and one enormous commit the week before the raise
- 02Tests and CI: whether anything runs automatically before code reaches production, or every deploy is a manual push and a hope
- 03Access hygiene: who has admin on the cloud account, the database and the repository, and whether that list matches who is still on the team
- 04Data handling: where customer data lives, who can query it directly, and whether secrets are in the code or in a secrets manager
- 05Dependency and license risk: whether the stack includes anything that blocks an acquirer or creates a support obligation nobody budgeted for
Generated code is not the risk. Unreviewed code is
Founders sometimes assume the risk is the tool: that code written with an AI assistant is inherently less fundable than code written by hand. That is not what a technical reviewer is checking.
The question is whether a human on the team can explain the code. Why does the authentication check happen where it does, and why is a table structured that way? What happens when an external call fails? A team that reviewed and understands its AI-generated code passes that conversation. A team that shipped a prototype nobody can walk through does not. The origin of the code is not what fails them.
How to self-audit first
Run the same checks a reviewer would, before they ask. Can anyone but the founder explain how a new user's data stays separate from every other customer's? Does at least one automated test run before code ships? Is there a list of who has access to production? Does it match who is actually still working on the product? A shrug is the finding a reviewer will write down. It is cheaper to fix before the data room opens than to explain during it.
Questions this raises
01What does technical due diligence actually check in a startup's code?
Commit history, automated tests and CI, who has access to production and customer data, and any licensing or dependency risk. A reviewer is checking whether the team can maintain and secure the system, not grading code style.
02Can an MVP built with AI coding tools pass technical due diligence?
Yes, if the team understands and can explain the code. Basic hygiene has to be in place too: access control, some automated testing, and a real commit history. The tool used to write the code is rarely the finding. An unreviewed prototype nobody can explain is.
03How do we prepare for a technical review before a raise?
Walk through the checklist yourself first. Check data separation between customers, automated tests before deploy, and an access list that matches who is actually on the team. Fixing gaps before the data room opens is far cheaper than explaining them during it.
