What are you actually buying?

The most useful question in technology diligence is not how the platform performs today. It is whether the team you are buying could rebuild it if they had to — and what the honest answer says about documentation, key-person concentration and the real cost of the next two years.

Revenue, roadmap and headcount are the easy part. Underneath sits an operating model, a set of dependencies and a technical debt position that rarely appears in the information memorandum. The gap between the story and the substance is where value leaks.

A capability described as AI-native may be a thin layer over a third-party model. The tests that matter are proprietary data, workflow depth, model dependency, reproducibility and defensibility. Without them, you may be paying a multiple for something a competent team could replicate in a quarter.

Most diligence starts late, when the timetable is already fixed. There is a great deal you can learn from the outside — product, hiring signals, architecture, security posture — early enough to shape the questions you ask rather than react to the answers you are given.

The actual sequence: thesis-linked scope, the small number of decisions the diligence must inform, the evidence each one requires, who can answer, and what you will do if the answer is bad. Take it and run it yourself.

The full method — the questions, the order to ask them in and how to read the answers. Differentiation is testable. Most of the time the test is simply whether someone else could reproduce it with the same money and the same twelve months.