Technical due diligence: a 25-point checklist for European founders.
May 9, 2026 · due-diligence, fundraising, fractional-cto
Technical due diligence kills more European Series A rounds than founders realize. Not because the technology is bad. Because the documentation is missing, the architecture is undefended, and the founder cannot answer specific questions on a thirty-minute call without checking with their lead engineer.
This is the checklist I run with founders before they walk into investor diligence. It is also the structure I follow when I conduct DD on behalf of acquirers and boards.
The list is twenty-five points across five sections. If you cannot answer the question with a specific document or a one-paragraph explanation, mark it as a gap and fix it before the call.
1. Architecture and stack (5 points)
1.1. A single architecture diagram, no more than one page, that an engineer outside your company can read in five minutes. Include data stores, services, third parties, and trust boundaries.
1.2. A written justification for every major stack choice. “Why Postgres and not DynamoDB” is a fair question. “Because that’s what we used at the last company” is not a fair answer.
1.3. A list of every third-party dependency that touches user data, with the data-processing agreements filed.
1.4. A documented disaster recovery plan with RPO and RTO targets, even if the targets are aspirational. Investors do not expect zero downtime; they expect you to have thought about it.
1.5. A current list of cloud-spend by service, with a one-line explanation of each line item over €500/month.
2. Code and engineering practices (5 points)
2.1. Branching model documented. Whether it is GitHub Flow, trunk-based, or something custom, write it down.
2.2. Code review policy. Who reviews what. What “approved” means. What blocks a merge.
2.3. CI/CD pipeline diagram with timing. A merge to main takes how long to reach production. If the answer is “we don’t know”, that is the gap.
2.4. Test coverage numbers, by service. Do not lie. A 12% coverage number you can defend is better than a 70% number you can’t.
2.5. Incident retro template, plus the last three retros. If you have had no incidents in the last twelve months, that is suspicious. If you have had many, the retros prove you learn.
3. Security and compliance (5 points)
3.1. A current list of who has production access. A short list is good. A list that includes “the founder, in case” is fine. A list that includes a former employee is fatal.
3.2. Secrets management documented. Where API keys live. Who can read them. How rotation works.
3.3. GDPR compliance: a one-page data flow diagram, a privacy policy that matches the diagram, and a record of processing activities.
3.4. A pen test or external security review in the last twelve months. If you can’t afford a formal pen test, an automated tool report is acceptable evidence that you tried.
3.5. A documented response plan for the day you discover a breach. Who calls whom, in what order.
4. Team and process (5 points)
4.1. Org chart current as of the last two weeks, including contractors. Investors will ask why your engineer count grew or shrank.
4.2. A list of every key-person dependency. The number of people whose departure would block a release. If the number is greater than one, name them.
4.3. Hiring plan tied to the funding round. “We will hire ten engineers” is not a plan. “We will hire two senior backend engineers in Q3 to unblock the payments rebuild” is.
4.4. Engineer attrition over the last twelve months, by month. Real number. Honest commentary.
4.5. A documented engineering culture, even if it is two paragraphs. Investors are buying the team that builds the product.
5. Roadmap and product (5 points)
5.1. A six-month product roadmap with named owners. Not a quarter, not a year. Six months is the diligence horizon.
5.2. A list of the top five technical risks that could prevent the roadmap from shipping. With mitigation status.
5.3. A list of features built and abandoned in the last twelve months, with the reason. This builds credibility, not the opposite. Founders who claim no abandoned features are either lying or new.
5.4. A clear separation between product features and platform investments in the roadmap. Investors penalize platform debt that hides as feature work.
5.5. A measurable definition of “AI strategy” if the company claims one. “We will use LLMs” is not a strategy. “We will use RAG over our customer support corpus to reduce ticket-handling time by 30% by Q3, with the eval harness defined” is a strategy.
How long this takes
For a Series A-stage company with reasonable hygiene, working through this checklist takes two to three weeks of focused work, mostly because it forces decisions that have been deferred. Most of the value is not in the diligence pack itself; it is in the conversations the checklist forces you to have internally.
For a company with no documentation and a founder-engineer who has been holding the architecture in their head, this is closer to four to six weeks.
Working with a fractional CTO on diligence
This is one of the cleanest fractional engagements there is. Fixed scope. Defined deadline. Hard outcome. Either you walk into the diligence call with the pack defended, or the round delays.
I run diligence engagements as a four to eight week sprint, scoped explicitly. The deliverable is the pack, the rehearsal of the diligence call, and the cleanup of the gaps the checklist exposed. The engagement ends at the funding decision.
If you are six to twelve weeks from a Series A and your DD pack is not defended, book a call.
Written by Andreas Scharf, fractional CTO at int32. Book a call or email m@int32.at.