Technical due diligence for early-stage investments
An independent read on a startup's technology before you invest. Done in days, written for people who do not read code, by someone who has built and run SaaS products himself.
For seed and Series A investors, business angels and accelerators, in Germany, Austria, Switzerland and the rest of Europe.
When you need this
- You are leading or joining a seed or Series A round, and the deck says a lot about the market and very little about how the product is built.
- A founder-built or agency-built product is about to receive real money, and nobody on your side has looked at the codebase, the infrastructure or the people who keep it running.
- The founders have flagged a technical risk themselves, a rewrite, a scaling problem, a single engineer who knows everything, and you want a second opinion on how serious it is.
What it covers
- Architecture: how the product is put together and how it will cope with more customers, more data and more features
- Code quality: structure, tests, and how a change travels from a developer to production
- Infrastructure and operations: hosting, deployment, monitoring, backups, and what it all costs per month
- Security basics and data handling, including the obvious things that are often missing
- Team and ownership: who knows what, what happens if one person leaves, how decisions get made
- Roadmap realism: whether what the founders plan for the next twelve months is possible with what exists today
What the report looks like
Written for the investment committee, not for the engineers. The detail is there, but at the back.
Summary
One page. The overall picture and the few findings that matter for the decision.
Findings by risk
Each with what I saw, why it matters for the business, and what fixing it would take.
Architecture and growth
How the product is put together and how it copes with more customers, data and features.
Code and delivery
Structure, tests, and how a change travels from a developer to production.
Operations and cost
Hosting, deployment, monitoring, backups, and what it all costs per month.
Security and data
The basics, and the obvious things that are often missing.
Team and ownership
Who knows what, what happens if one person leaves, how decisions get made.
Roadmap realism
Whether the next twelve months are possible with what exists today.
Appendix
The technical detail, for whoever on your side wants it.
How it works
Typically within a week from access to report.
Kick-off with you and the founders
We agree on scope and depth, sign the confidentiality agreement, and I get read access to the repositories, the infrastructure and the documentation.
Review
I read the code and the infrastructure, run what can be run, and talk to the engineers. The conversations are as important as the code: they show how the team thinks and where it is honest about its gaps.
Report
Findings sorted by risk, each with what it means for the business and a realistic estimate of what fixing it would take. Written so that a non-technical partner can read it without a translator.
Walkthrough
A call where I explain the findings, answer your questions and give you a short summary you can share with the rest of the investment committee.
What it costs
A fixed price per engagement, quoted after the kick-off call based on the size of the codebase and the depth you need. No hourly surprises, and half of the fee is due when we start. Numbers on request.
Questions people ask first
- What is a technical due diligence?
- A technical due diligence is an independent assessment of a company’s software, infrastructure, engineering team and processes, carried out before an investment or acquisition. It answers one question for the investor: what technical risks exist, and do they change the decision or the price?
- How long does it take?
- For an early-stage startup, usually within a week from the moment I have access until you hold the report. Larger codebases or several products take longer, and I say so after the kick-off rather than squeezing them into the same window.
- What is in the report?
- A one-page summary with the overall picture, then the findings sorted by risk. Each finding states what I saw, why it matters for the business, and what it would take to fix. The last section covers the team and whether the roadmap is realistic. Appendices hold the technical detail for whoever wants it.
- How is this different from an architecture review?
- The client and the question are different. A due diligence works for the investor and asks whether the technology is a risk to the investment. An architecture review works for the company itself and asks what the team should improve and in which order. The methods overlap, the reports do not.
- How do you handle confidentiality and access?
- A confidentiality agreement with both the investor and the startup is signed before I see anything. I work with read-only access, keep nothing after the engagement, and the founders see the report before the walkthrough so there are no surprises on either side.
- Which technologies do you cover?
- Most of what early-stage products are built with today: TypeScript and JavaScript, React and React Native, Node.js, Python, relational and document databases, and the usual cloud and container setups. For a stack outside that range I say so up front rather than guess.