A technical diligence is not the inspection of a stack. It is the inspection of a set of decisions, taken under specific constraints, by a specific team, in a specific market window. The architecture deck reports the conclusion. The diligence asks how the conclusion was reached, what was rejected to reach it, who in the room had standing to push back, and what is now load-bearing on a single person who could leave between rounds. A clean diagram is not evidence. The reasoning behind it is.
What the deck does not answer
A target's architecture deck almost always answers the same questions: what is in the stack, how it scales, where the data lives, what the SLA looks like. These are the questions a vendor pitch is engineered to answer well. They are necessary; they are also rehearsed. Every diligence we have run has confirmed the deck and then found the engagement underneath it in places the deck did not look — in the reasoning the team can or cannot reproduce, in the alternatives they can or cannot defend the rejection of, in the dependencies that quietly accumulated when nobody had time to write them down.
The quiet questions sit beneath the deck. They are the questions the principal would ask if the principal were senior in the same craft as the team being diligenced. Most principals are not. Most principals are senior in capital allocation, or in operating, or in a domain — not in engineering. The diligence is what closes that gap, in writing, in language the IC can read.
The questions themselves
The list below is not exhaustive. It is the working list we open every engagement with, and it is the one we revise during the engagement as the system reveals where it is actually fragile.
The decision behind the architecture. Who made it. When. Against what alternatives. What the team would change if they were starting today. Whether the answer is we would build it the same way (occasionally true, often a pose) or we would do three specific things differently (almost always the honest answer, and the more useful one for the investor).
The departure question. If the person who built the core were to leave on Friday, what specifically breaks. Not in theory — name the system, name the dependency, name the documentation that does or does not exist, name the second person who could read the code without an introduction. The departure question is the single most predictive question in a technical diligence and the one most teams have not been asked.
The cost envelope under load. Not what the system costs today. What it will cost at three times today's volume, on the existing contracts, with the existing model choices, on the existing infrastructure terms. The unit economics of an AI feature in 2026 are different at scale; the model choice the team made eighteen months ago may have been correct then and ruinous now. The diligence reads the bill, not the boast.
The model and vendor lock-in. Which model is the system load-bearing on. Which vendor terms are negotiated and which are off-the-shelf. What the migration cost would be if the model is deprecated, repriced, or the vendor's terms change. AI vendors are not utilities yet. Treat them as the variable they still are.
The change history of the most fragile system. Pull the commit log of the part of the system the team is most cagey about. Read who has touched it, when, why, and whether the changes are documented. The fragile system is not always the one the team flags; it is sometimes the one the team has stopped touching because the cost of touching it has become invisible to them.
The audit trail. If a regulator, an acquirer, or a senior internal hire asked tomorrow for the rationale behind the three largest architectural decisions of the last twenty-four months, can the team produce it in writing. Not in someone's head. Not in a Slack thread that has since aged out. In a document, with a date, with the alternatives named.
The deliverable
The diligence is a written memo to the principal. It is short, it is specific, and it has a defensible structure: what we found, what we did not find, the risks we would ask the IC to hold, and an explicit list of what the principal is choosing not to know. The last list — what the principal is choosing not to know — is the most important one. Every diligence has it. Most diligences do not name it. We do.
A diligence is not a verdict. It is a written transfer of judgment from one senior reader to another.
The memo is read once by the IC, once by the principal, and possibly a third time by the operator who inherits the engagement. It is written for all three readers. It does not strain to impress. It assumes the reader is also senior, and writes accordingly.
Where this leaves the engagement
A diligence sometimes ends with this is a clean target — proceed. It often ends with this is a clean target with three named conditions — here is what we would ask the company to commit to in the term sheet. It occasionally ends with do not proceed, and when it does, the reasoning is in writing and the principal can defend it to the partner who first liked the deal.
The studio does not also broker the deal. The studio does not have a position in the target's stack. The studio is paid for the read and walks away from it; the principal owns the decision, the documents, and the right to share the memo with whomever they choose to share it with.
That separation is the only reason the read is honest. We would rather lose the engagement to another diligence shop than carry it on terms that compromise the read. A diligence that the principal cannot fully trust is a diligence that has not happened.
If a deal is in front of you and the technical questions underneath it have not yet been asked in writing, write to the studio. We will tell you, in the first call, whether the engagement is one we can answer well — and if it is not, we will tell you who, in our network, would.