Technical due diligence in three days: what investors should actually check

Three days can be enough for a focused technical risk review at seed or Series A, provided access is ready and the decision is clear. I would start with three questions: can the team ship, can the system support the plan, and what needs fixing first? Anything the review cannot verify should stay visible as an open question.

What technical due diligence is for

It is not a code quality score. It is a read of technical risk against the plan and the price. A messy codebase can be fine if the team ships every week and the plan does not depend on scale. A clean one can be a problem if a single engineer understands it and is about to leave.

The question is always the same: what in the software could stop this company from doing what the deck says it will do?

What to ask for before day one

• Read access to the main repositories, under NDA.
• A 30-minute architecture walkthrough with the technical lead.
• The last three months of cloud and third-party service bills.
• The incident log, or a list of the last outages and what caused them.
• Who owns what: a simple list of people and the parts of the system they know.
• The product roadmap for the next 12–18 months.

Missing records are worth noting. They may mean weak controls, limited access or simply that nobody has collected them yet; the review needs to distinguish those cases.

The eight areas to check

Area	The question	Evidence to look at	Red flag
Architecture	Can the system support the next 18 months of the plan?	Walkthrough, data model, main service boundaries	The core data model contradicts the roadmap
Delivery	Can the team ship safely and often?	CI history, deploy frequency, rollback process	Only one person can deploy
Dependencies	Is the software built on maintained foundations?	Dependency list, update history, licences	Unmaintained critical libraries, licence conflicts
Security	Are the basics in place?	Secrets handling, auth, access control, git history	Credentials in the repository that were never rotated
Data and privacy	Is customer data handled legally and safely?	Where data lives, who can access it, backups	Production data copied to laptops or test systems
Infrastructure and cost	Does cost grow sensibly with usage?	Cloud bills against active users	Cost growing much faster than customers
Team	Does the knowledge survive one resignation?	Ownership list, commit history	One person wrote and understands most of the core
AI components	Is the AI part defensible and compliant?	Model vendors, evaluation, data rights, EU AI Act exposure	The product is a thin wrapper on one vendor’s model, with no evaluation

For AI products, the AI due diligence playbook goes deeper into that last row.

How the three days run

1. Day 1, scope and read. Agree on the decision the review must inform. Read the code, the bills and the incident log. Note open questions.
2. Day 2, deep dive. Go into the two or three riskiest areas with the technical team. Verify claims against the code, not slides.
3. Day 3, write-up. A short decision memo, a risk register with severity and effort, and the questions management must answer before closing.

Tools find candidates; a reviewer decides

Automated scans are a good start and a poor finish. My public evidence pack for tokio-rs/axum, generated with an open-source audit toolkit, shows why. The scan flags a list of “potential God modules” as a high-severity risk, and one of them is axum/src/routing/tests/mod.rs: a 1,354-line file of tests. A large test file is not an architecture problem, so a reviewer downgrades that item. The same pack reports a cycle among top-level modules. That also needs checking against the code before it becomes a finding.

That filtering step is most of the value of a three-day review. An investor needs a short list of risks that are real, each with the evidence behind it, not a long list of warnings.

Red flags and yellow flags

A monolith or an older, supported framework is not a red flag on its own. Low test coverage needs more context: missing tests around billing or access control matter more than a repository-wide percentage.

Findings that may affect price, closing conditions or the remediation plan include:

• Secrets in the git history that were never rotated.
• A core component nobody but the founder can change.
• Licences that conflict with how the product is distributed.
• Customer data handled in a way that would not survive a GDPR complaint.
• Infrastructure cost that makes the unit economics in the deck impossible.

What the output should look like

The deliverable should be short enough for a partner to read before the investment committee: two pages of decision memo, a risk register you can sort by severity and a list of questions for management. The public evidence packs show the risk register and review questions. A deal-specific memo also needs the business context and the limits of the review.

FAQ

Do founders have to share their source code? Read access under NDA is standard. If that is not possible, a guided session where the reviewer drives and the team shares their screen is a workable second best.

Can a startup commission its own review before a round? Yes, and it often speeds up the round. Founders who arrive with a recent independent review answer the technical questions before they are asked.

Is three days enough? For a focused review, it can be. Scope, access and the risks found determine whether more work is needed before the investment decision.

What does it cost? Prices vary widely. My 3-Day Technical Risk Review is $3,500 fixed, excl. VAT. If the founders are still deciding whether to rewrite, send them this note on stabilising, rewriting or pausing.