I have read a lot of technology due diligence reports, and the weak ones fail in the same way. They describe the system accurately and then stop.
You finish forty pages knowing the languages, the cloud provider, the repository count and the test coverage, and you still cannot say whether the thing in front of you supports the investment case or quietly undermines it.
A report is not an inventory. It exists to help a small number of people make one decision under time pressure. Everything in it should be arranged around that.
What the report is for
Technology is often central to the investment thesis and difficult to assess from the outside. A clean demo can hide a fragile platform. A large engineering team can conceal weak throughput. A credible AI story can amount to little more than a vendor API and a presentation.
So the report has one job: to tell the investor what is real, what is risky, and what can create value. Every section should be readable as an answer to one of those three.
That framing also decides what gets left out. Findings that do not change the decision, the price or the first hundred days belong in an appendix, or nowhere.
The six sections, and what each must answer
The thesis check. Does the technology actually support the investment case being made? If the plan assumes entry into three new markets, the question is whether the platform can be regionalised without a rebuild. If it assumes margin expansion, the question is what drives unit cost and whether it falls with scale. This section is written last and read first, and a surprising number of reports do not contain it at all.
Architecture and scalability. Will this hold at the volumes in the plan, and what breaks first? Good analysis here is specific. It names the component that becomes the constraint, the load at which it becomes one, and roughly what it costs to move that ceiling. Vague reassurance that the architecture is modern is worth nothing; so is vague alarm.
Security, resilience and compliance. What could stop a deal, lose a customer, or trigger a regulator? Separate what is genuinely dangerous from what is merely untidy. An unpatched dependency is a task. Customer data replicated into an analytics environment nobody governs is a finding. If the company sells to enterprises, the security questionnaire they will face next year is a more useful test than any generic checklist.
The engineering organisation. Can these people deliver the plan? Headcount is the least interesting number here. Look at throughput against what was promised, how work actually flows, where the key-person risk sits, and whether there is technology leadership above the team or only within it. A strong team with no senior technology voice will build well and build the wrong things.
AI capability and defensibility. The newest section and the easiest to fake. The question is not whether the company uses AI. It is where the intelligence actually sits, and whether any of it is theirs. A thin layer over a model provider is a feature, not a moat. What can be defended is usually the knowledge, data and feedback loops the company has assembled, and whether those improve with use. Ask what happens to the product, and to gross margin, if the underlying model becomes ten times cheaper or ten times better. If nobody has thought about it, that is your finding.
Cost and technical debt. What does the next two years actually cost? Run rate, but also the work that has been deferred and will now come due, and any inference or licence cost that scales with usage rather than revenue. Technical debt is only worth reporting where it has a price and a date. Everything else is an opinion about tidiness.
How to tell a weak report
A few tells, all of them quick.
- It has no view. Findings are listed without weight, so every issue looks equally important and none looks urgent.
- It grades rather than explains. A maturity score out of five tells you nothing you can act on. What was scored, against what, and what would move it?
- It avoids the people question. Assessing an engineering organisation means forming a view about individuals, which is uncomfortable and necessary. Reports that discuss only systems are usually avoiding it.
- It cannot distinguish severity. If the dependency audit and the single-point-of-failure database appear in the same list at the same weight, nobody read the findings as an investor would.
- Its recommendations have no sequence. Twenty improvements with no order is a wish, not a plan.
The page that matters
The executive summary should be one page, and it should take a position.
Three things belong on it. What is real, stated plainly, including the parts of the company's own story that did not survive contact with the code. What is risky, ranked, with what each risk would cost and when it would land. And what can create value, which is the part most reports skip entirely, because it requires the author to have an opinion about the business rather than only the system.
If that page cannot be written without hedging, the diligence is not finished.
After the deal
The most valuable thing a report can do is survive the transaction.
A diligence exercise builds an understanding of the company that is expensive to acquire and easy to throw away. If the findings are written so they can become a first hundred days plan, with owners and a sequence, the work pays twice. If they are written to close a deal and then be filed, the new owners will rediscover the same issues more slowly and at greater cost.
Write the report so the person holding it in month four still finds it useful.
One caution on the AI section, because it is where the most money is currently being lost. The question of whether a company is genuinely building with intelligence, or has simply bought some, is now the difference between a defensible business and an expensive one. That is worth understanding properly before you underwrite it.