My colleagues have performed more than 180 technical due diligence audits over the past decade, and the people who get to read the report are mostly very enthusiastic after doing so. It's brutally honest, it gives a good objective opinion on what the current state of their team and product is.
Most people who commission one of these reports have never actually seen one. You've signed a term sheet, the due diligence clock is ticking, and somewhere in the data room, a document will appear that claims to tell you whether the technology you're buying into is sound. Usually, it's written about code you'll never read yourself. So here is what's actually in that document, and how to tell a report you can act on from a sixty-page checkbox exercise.
Smaller than you'd expect
Our report runs around 25 pages. That surprises people, usually in a good way, because the alternative they've seen is a machine-generated brick of static analysis output that nobody on the cap table will ever open twice.
Those pages are built from two sources: interviews with the people who build the product, from the CEO down to individual engineers, and a deep review of the code they've built. The findings get organised into five pillars: team and leadership, processes, written communication, engineering, and problem-solution fit. Count again: code is one pillar out of five. That ratio is deliberate. Most technical risk lives in the people and habits around the code, and only some of it in the code itself. The startup where everything runs through one brilliant founding engineer is a bigger threat to your investment than any tangled module, and it shows: nearly three in four of the companies we audit carry some version of that key-person risk.
Observations and concerns do different jobs
The structural idea that makes the whole report work is a strict separation between observations and concerns.
Observations are facts. Team size, deployment frequency, what's documented and what isn't, how hiring works, which parts of the system have tests. Before the report is finalised, the audited company fact-checks every one of them. Concerns are the auditor's judgement about what those facts mean, and they are clearly labelled as judgement.
Think of the observations as your blood test results and the concerns as the doctor leaning back in her chair to tell you what she makes of them. You can't argue with your cholesterol value. You can have a genuinely useful conversation about what to do next.
This matters more than it sounds, because a due diligence report has to survive contact with a founder who doesn't like its conclusions. A report built on opinions gets waved away in exactly the meeting where you need it most, the one where the price gets discussed. A concern nobody can dismiss, sitting on a fact everybody has already agreed to, is the whole trick.
It answers your actual questions, not the generic ones
Before the audit starts, the investor and the auditors agree on the specific questions the deal depends on. Can this platform handle ten times the load if the growth plan works? Can this team ship the roadmap they pitched, with the people they have? Is that migration they keep postponing a real risk or a nice-to-have?
The executive summary answers those questions directly, with a yes or a no, before the narrative begins. It's a small feature with a sharp edge: a yes or no leaves nowhere to hide, for the target or for the auditor. If a report you commissioned answers questions you never asked, someone sold you a template.
There is no score, and that's on purpose
Our reports contain no grade, no marks out of ten. People occasionally find this frustrating, but that's usually not for longer than a few hours.
A score invites the wrong conversations. How do we get to a six? Why did that other company get a seven? Six, seven? The numbers become the deliverable and everyone starts negotiating with the thermometer instead of treating the patient. The value of a due diligence report is in specific, fact-checked findings tied to the specific questions your deal depends on, and none of that survives being compressed into a single digit.
What the findings tend to say
A decade of these audits in, the findings are patterns more than surprises. Documentation debt shows up in nearly every report we write. Around 85% of the companies we audit have little or no automated testing. Nearly half have credentials sitting in plain text somewhere in the code. We ran the numbers on the whole dataset and turned them into a bingo card, because at this frequency the patterns deserve one.
Before you conclude that the software industry is uniquely sloppy: point that same lens at our own projects and we'd tick a few squares ourselves. Startups trade polish for speed because that's the game they're in, and an audit that expects pristine code from a company that's been sprinting for three years has misunderstood the assignment.
What a good report does with these patterns is weigh them against your deal. Missing documentation reads very differently when you're extending a runway by twelve months than when you're acquiring a company whose engineers might leave after the earn-out. The finding is the same; the risk is yours.
The report is half the deliverable
Findings without interpretation are just anxiety with page numbers.
A stage profile will tell you the final climb averages eight percent for twelve kilometres. The rider who has trained on it knows those twelve kilometres hide two false flats, a brutal last stretch, and a crosswind that turns against you near the top. The report is the profile. The debrief is the conversation with someone who has ridden the road.
That's why the audit ends with two meetings rather than a PDF in your inbox. First a debrief with the audited company, walking through the top concerns, no ambushes. Then a delivery meeting with you, the client, where you can ask everything the report raised. What would you fix first? How worried should we really be about the database? Would you do this deal? The written report is what you can forward to the rest of the fund. The conversation is where its meaning becomes actionable.
How to spot a checkbox report
Not every due diligence report earns its fee, and you don't need to be technical to spot the ones that don't. Watch for findings so generic they could describe any company ("technical debt was identified"). Watch for concerns with no suggested way out, because a risk without a remediation is an observation wearing a costume. Watch for a big confident score sitting on top of facts nobody verified. And watch for prose that reads like it was written to be defensible in court rather than useful in a boardroom, all passive voice and no opinions.
The test is simple: does the report change what you do on Monday morning? The price you offer, the warranties you ask for, the plan for the first hundred days, or in some cases whether you proceed at all. A report that changes nothing was an expensive ritual.
See one for yourself
The fastest way to calibrate your expectations is to read a real one. We publish a full, anonymised sample of our audit report, and you can download it on our audits page. If you'd rather start with what a good process looks like, our technical due diligence checklist covers the questions worth asking, and we've written before about why the checklist alone is not enough.
The sample has our real structure, our real pillar breakdown, and none of our clients' actual secrets. Those stay where we keep finding them: in the codebase.
