A technical due diligence report should tell you whether the technology supports the business case you've been given, and what it would cost to make it true if it doesn't. If you finish reading it and still can't say whether to proceed, on what terms, or what to ask the founders next, it hasn't done its job.
You don't need to be technical to read a good one. It should be written for the person making the investment decision.
The questions it should answer
Does the product do what the pitch says? The deck describes a platform. The report should say what exists, what's partly built and what's only planned, so you can see the gap between the first two and the third.
Can it be built on? This is the "continue, fix first or rebuild" question, applied to your investment. If the founders will spend your money on rewriting the foundations, you want to know before you wire it.
How exposed is it? Security, data protection and the handling of personal information, in terms of what could actually go wrong and what it would cost, not a list of acronyms.
What does it depend on? A single developer, a single supplier, a single cloud account, a library nobody maintains any more. Concentration of knowledge or control is a risk even when the code is good.
Who owns it? Intellectual property, repository access, licences and third-party components. Your legal advisers will want the detail, and the technical report should flag what they need to look at.
Can the team deliver? This isn't a performance review. It asks whether the people and the way they work can produce what the plan needs.
What will it cost to fix? Not a precise number, but a range and a sequence, so the remediation can be priced into the deal.
Red flags
These are the things that should change a conversation.
One person holds all of it. If the whole system lives in the head of a single contractor, and nobody else can run or deploy it, the business has a key-person risk the cap table doesn't show.
Code or accounts sit outside the company. Repositories in a developer's personal account, or hosting billed to an agency, mean the company doesn't control its own product.
No tests and no repeatable releases. Everything may work today. Nobody can say whether tomorrow's change will break it.
Security that was never looked at. Not necessarily insecure, but unexamined, particularly where the product holds customer data or takes payments.
The pitch and the product differ. Features presented as live that turn out to be mock-ups, or a "proprietary platform" that is mostly third-party components glued together.
Any one of these might be fixable. What matters is how the founders respond when asked about them. Defensiveness is information too.
What a clean result looks like
A clean report isn't one with no findings. Every real system has some.
It looks like this: the foundations are sound, the issues found are ordinary and well understood, the company controls its code and accounts, more than one person can run and release the system, and the remaining risks have a sensible owner and a realistic price. The report says so plainly and doesn't pad itself with filler findings to look thorough.
That's valuable in itself. It tells you the technology isn't what you need to worry about, so you can spend your attention on the market, the team and the terms.
How long it takes
On this site, focused due diligence takes one to two weeks and starts from £8,000. It's a narrower read, aimed at specific risk areas, the quality of the codebase or the capability of the team. Full due diligence takes two to three weeks and starts from £10,000, and covers architecture, security, infrastructure, code quality, technical debt and the team.
Price and timing depend on the stage of the company, the size of the codebase and what the report needs to contain. Delays can come from access, such as waiting for repository permissions or for the founders to make time for questions. Arranging access before the clock starts removes a common source of them.
Ask for the report format before you commission it, and check that it gives a clear recommendation, a ranked list of risks and a summary you can pass to your co-investors.
If you're at that stage, technical due diligence is the service I offer for it. If you're still deciding what you need, get in touch and I'll tell you honestly which scope fits.