A diligence report is not a code review. Here is what the review actually opens, in what order, and why the boring files decide the answer.
Most people picture a technical due diligence as someone reading the code. It is not that, and the difference matters if you are commissioning one: a reviewer who spends two weeks reading source files will produce an opinion about code quality, which is almost never the question that was actually asked.
The question is usually one of three. Can this system do what the plan says it will do? What is under it that has not surfaced yet? And if we are wrong about either, what does that cost to fix? Those get answered by reading a fairly specific set of things, in a fairly specific order, and the order is the useful part.
First: what the system is, from the outside in
The opening pass is architecture and data flows — how requests move, where state lives, what talks to what, and which of those decisions are load-bearing. Not to judge them. To find out which decisions the rest of the review has to be about.
Most systems have three or four choices that everything else is downstream of: the data model, the trust boundary, the deployment shape, and whichever external service the product cannot function without. Everything else is detail that can be changed on a Tuesday. Identifying those first is what stops a review turning into a list of two hundred equally-weighted observations, which is the failure mode of diligence done as a checklist.
Second: security posture, and how safely the AI parts are built
For an AI product this is where the review earns its fee, because the failure modes are newer than most teams' instincts about them.
The specific questions: does anything treat model output as trusted? Can any component be persuaded, through content it reads, to take an action nobody authorised? What is each tool or integration actually scoped to do, and what is the worst case if it is invoked wrongly? Is there a record of what the system did, and would that record survive the thing it was recording going wrong?
Those are architecture questions, not prompt questions, which is why they can be answered by reading a system rather than by testing it adversarially for a month. A product where the answer is "the system prompt tells it not to" has a finding, and the finding is not that the prompt is badly written — it is that a prompt is being asked to do a job that structure has to do. We wrote up the boundary version of this argument separately.
Third: what breaks at scale, and what that costs
Scalability review is frequently mistaken for load testing. It is closer to arithmetic: take the growth the plan assumes, apply it to the current design, and find the first thing that stops working. There is always one, and it is usually not the web tier.
The output that matters here is not "it will not scale" but "at roughly this volume, this specific component becomes the constraint, and moving it costs about this much". A risk without a price attached cannot be traded off against anything, which makes it useless to the person making the decision.
The boring files decide the answer
The most informative reading in a diligence is rarely the application logic. It is the operational surface: how the thing is configured, deployed, and what it does when something is missing.
Three examples from our own codebase, since publishing findings about a client's is not available to us and inventing one would be worse than saying nothing.
What happens when configuration is wrong. This site's backend validates every environment variable once, at startup, and refuses to boot if any required one is missing or malformed — raising a single error that names every offending variable at once, so a deploy with three problems is one fix rather than three restart cycles. It reached that state the hard way: a public URL variable was unset in production for a long time, and a fallback to localhost meant every password-reset email mailed an unusable link. Nothing was broken in a way anyone could see. It just quietly did not work.
So the question a reviewer asks is not "is there config validation" but "what does this system do when it is misconfigured — stop, or keep serving something subtly wrong?" A service that degrades silently produces incidents nobody opens a ticket for, and those are the ones that run for months.
What the deploy actually does, every time. A provisioning script here deleted and re-created the founder's record on every deploy. Every time, it reset the fields the CMS owned and changed the row's id — which was also the identifier the site's structured data used to describe that person to search engines. Nobody noticed, because the site rendered correctly after every deploy. There is now a test that fails if any name appears in both a delete and an insert in that file.
Deploy scripts and migrations are read early in a review for exactly this reason: they are the code that runs unattended, on production, more often than anything else, and they are almost never reviewed with the attention their blast radius deserves.
What the system tells the outside world about itself. This site is a single-page app, so for a long time every URL on the domain returned 200 — including a service page retired months earlier. Search Console eventually showed the cost: the retired page was indexed and ranking at position 4.7, which was the domain's best position, for a page that did not exist. The fix was structural, and it took a request to the backend to answer whether a path was real before the shell could be served.
That one is a good example of a whole class: a system that is technically operating correctly while telling every external consumer something false. Nothing errors, no alert fires, and the only evidence is in a dashboard someone has to think to open.
What you actually get, and who it is written for
Three things: a report, a risk register ordered by what each item would cost you, and a prioritised remediation roadmap with effort estimates.
The report is deliberately written for two audiences in one document. Strengths, risks and what remediation would cost are written for the people making the decision; the engineering detail sits underneath for the team who would do the fixing. That is not a formatting preference. A risk nobody outside the codebase can understand does not get priced into the decision, which means it may as well not have been found.
Practically it runs one to two weeks, given read access to the codebase and infrastructure and an hour or two with whoever built it. The most useful thing a client provides is not access, though — it is telling us which decision the review is feeding. A report written to answer your actual question is more useful than a general audit, and a general audit is what you get by default when nobody says.
Founder or investor, the work is identical
An investor is sizing technical risk before committing. A founder is finding the problems before someone else does — which is a considerably cheaper time to find them, and the reason the second case is often the better-value one.
The only real difference is what happens to the report. An investor uses it to price a decision. A founder uses it as a work plan, which is why the remediation roadmap carries effort estimates rather than just severities.
If either of those is the position you are in, that is what our technical due diligence work is: an independent architecture, security and scalability review, written by people who build the same kind of system rather than only assess it.