Technical Due Diligence for Founders & Acquirers
Due diligence is where technical debt turns into a valuation conversation. Whether you’re the founder heading into one or the acquirer running one, walking in without a clear technical picture is how good deals die.
I’ve spent 16 years building and scaling engineering teams at startups and scale-ups, and led the technical side of 4 products that went on to generate over €25M in annual revenue. I’ve been the CTO answering diligence questions and the technical lead asking them. I know what a diligence team is going to look for, what actually matters, and what only looks like a problem.
Alongside my work as a CTO, I now run technical due diligence for a small number of engagements a year, on both sides of the table.
Two sides of the same table
You’re a founder preparing for a round or an exit
The investor’s diligence team will find your weaknesses. The only question is whether you find them first.
- A pre-diligence assessment of your codebase, architecture, team, security, and infrastructure costs, before someone else’s report frames them for you
- A prioritized fix list: what actually moves the deal, what’s worth fixing, and what just needs a straight answer
- Help writing the technical narrative, so your architecture reads as a deliberate decision, not an accident
You’re acquiring a product or a team
The pitch deck is not the codebase. I give you an independent read on what you’re actually buying.
- Architecture and code quality reality check: what’s there, what it will cost to maintain, and what’s one refactor away from falling over
- Key person risk, team structure, and whether the team that built it is the team that can scale it
- Infrastructure and run costs, security posture, and the technical debt that turns into your budget after closing
What I look at
| Area | What I’m assessing |
|---|---|
| Architecture & code quality | Is it built to scale, or built to demo? What needs rewriting, and what’s fine as it is? |
| Team & key-person risk | Does the knowledge live in the system or in three people’s heads? |
| Security & compliance | Where’s the data, who can reach it, and what will surface in week two after closing? |
| Infrastructure & costs | What does it actually cost to run, and what does that look like at 10x? |
| Scalability | Thousands of users today. What breaks at the next hundred thousand? |
| Roadmap vs. reality | Which promises in the deck are funded, feasible, and staffed? |
What you get
One document: a Technical Due Diligence Report with findings ranked by risk and impact, the questions you should be asking (or answering), and my judgment in writing on whether the technology helps or hurts the deal.
Not a checklist audit. Diligence teams can find issues; I tell you which ones matter, what they’ll cost, and what to do about them.