Technical due diligence for investors and founders
An independent assessment of the product, code and team before an investment, a deal, or joining a project. I answer one question: how technically sound is what you're being offered, what are the risks, and what do they cost.
When companies bring me in
- You’re about to invest in or acquire a company and want to know what has actually been built.
- The pitch is convincing, but there's no one to check the technical side.
- You need to know whether the product will withstand the growth in the business plan.
- The team says everything is fine, but you want an independent view.
- The deal is close and you have weeks, not months, to check.
What you get
- A clear conclusion: whether to invest, what the risks are and what they cost.
- Findings sorted by impact on the deal, not by academic correctness.
- An estimate of what needs fixing, on what timeline and at what cost.
- A conversation in business language — no "microservices" or "legacy" where it doesn't affect your decision.
How I work
- First we establish what is critical in your particular deal; that sets the depth and focus of the review.
- I look at five things: the architecture and its ability to carry the planned growth; technical debt and its effect on the pace of change; the team and dependence on key people; processes, infrastructure and security; and whether what is built matches what is claimed.
- I turn the findings into a conclusion: the risks, their cost, what must be closed before the deal and what can be fixed after.
- We go through the result so that you make the decision yourself rather than take my word for it.
- Typical timeframe: from a few days to a couple of weeks, depending on the size of the product.
From practice
-
Cloud platform for fitness club chains — a product that went from a first version to raising investment: it shows from the inside what an investor looks at.
Read case -
Requests and offers matching platform — an architecture that survived a change of market: how design decides a business's fate.
Read case -
Rail ticketing system in a regulated industry — work where requirements and the cost of error are at their highest.
Read case
Format and cost
Cost
from $9,000
The exact figure is set once scope and depth are agreed.
- What's included: an assessment across five areas — the architecture and its headroom for the planned growth; technical debt and its effect on the pace of change; the team and dependence on key people; processes, infrastructure and security; and whether what's built matches what's claimed. The result is a written conclusion with the risks, their cost and priorities.
- Timeline: from a few days to two weeks, depending on the size of the product and the depth required.
- Outcome: a written conclusion and a walkthrough of the findings.
FAQ
- How long does it take?
- From a few days to a couple of weeks, depending on the size of the product and the depth you need.
- Do you need access to the code?
- Preferable, but a lot is visible without it: architecture, processes, the team, and whether the product matches what's claimed. I work with whatever level of access you can give.
- What if the team resists the review?
- That is a signal in itself. Resistance usually fades once it's clear the goal isn't to find someone to blame but to understand the risks.
- What about confidentiality?
- An NDA is standard. Nothing I see leaves the room, including my public materials.
- Will you fix what you find?
- Not necessarily, and I don't push for it: the independence of the assessment matters more than continuing the work.
For more on what I look at, see 'Technical due diligence: what an investor looks at'