Guide // Technical due diligence
What a technical due diligence actually asks.
Somewhere between the term sheet and the money, an investor sends someone technical to look at what you have built. It is usually a couple of calls and some access, it is rarely adversarial, and it is almost never the thing founders prepared for. Here is what gets asked, and where people come unstuck.
The questions
Grouped the way a reviewer works through them. None of these are trick questions. The point is not to catch you out, it is to find out whether the thing is real and whether you understand it.
Architecture
- Draw the system. Where does a request go, and what does it touch?
- What happens when this has ten times the traffic?
- What here would you rebuild if you started again, and why?
Security and data
- How is one customer's data kept away from another's? Show me the code that enforces it.
- Who on the team can read production data, and is that logged?
- Where do secrets live, and who has had access to them?
- What personal data do you hold, on what legal basis, and can you delete it on request?
Delivery
- How does a change reach production, and how long does it take?
- What stops a bad change getting there?
- How do you know when something is broken, and how did you find out last time?
The team
- If one named person left tomorrow, what stops?
- Who has written the majority of this, and are they still here?
Ownership
- Do you own the code? Contractors, agencies and previous co-founders all need assignment in writing.
- What licences are in your dependency tree, and are any of them copyleft?
- Whose terms cover the models you call, and are you allowed to use the outputs commercially?
Where AI-built products fail this
A product assembled quickly with Lovable, Bolt, Cursor or Claude Code is not worse by default, and reviewers know that. But it fails in a recognisable pattern, and it fails in the places a demo never touches.
- Authorisation that was never really thereThe product checks whether you are signed in and not whether the record belongs to you. It passes every demo, because in a demo there is one customer.
- One environment wearing two hatsDevelopment and production sharing a database, or the same keys in both. A reviewer finds this in about four minutes and it colours everything after it.
- Secrets in the client bundleKeys shipped to the browser because the tool made it easy. Anyone with dev tools has them, and rotating them is not the fix if the model was wrong.
- Nobody can explain the codeThe most damaging one. If a founder cannot explain why something is built the way it is, a reviewer stops assessing the product and starts assessing the team.
The last one does the most damage. A reviewer can live with an imperfect architecture, because everything at your stage is imperfect. What they cannot get past is a founder who cannot say why it is built that way, because at that point they stop assessing the product and start assessing whether anyone here could fix it.
The fortnight before
If diligence is coming and you have two weeks, this is the order I would do things in. It is deliberately short, and it is ranked.
- 01Write the architecture down on one page. Most of the value of this is that you find the answer to question three yourself.
- 02Write one test that proves a second customer cannot read the first customer's data. If you write nothing else, write this.
- 03Separate development from production, properly, including the keys.
- 04Get code ownership in writing from every contractor and former collaborator.
- 05Read your own dependency licences.
Related, and more detailed on the data-isolation point: row-level security is your authorisation layer, which is the single most common finding.
If you are the investor
I do these reviews. A couple of calls with the team, a read of the codebase, and a written answer to the only question that matters: whether this is a real system, whether the people who built it understand it, and what it would cost to make it safe.
Useful before a cheque, and just as useful after one, when a portfolio company is about to hire its first engineers and nobody has looked under the bonnet. Email louis@quezzies.com.
If diligence is coming and you're not ready
Technical due diligence readiness is part of The Founding Engineer: 8 weeks, 5 founders, £2,500. The architecture written down, the boundaries actually tested, and someone senior who can tell you what a reviewer will find before one does.