Technical diligence for a family office is the read of a system written on a twenty-year horizon, by a reader who is not planning to sell the asset. It asks whether the software will still be operable, defensible, and affordable to maintain after the founders, the original engineers, and the original architecture have all moved on. It is, in that sense, the opposite of a venture diligence, which asks whether the system can survive long enough to reach the next round and the eventual exit.
A family office does not exit on a fund clock. The questions it has to ask of a piece of technology, therefore, are not the ones a venture board has to ask. The two reads can look superficially similar — same code, same architecture diagrams, same engineers in the room — and still arrive at completely different conclusions about whether the asset is sound. We have done both reads. We prefer to be clear about the difference.
What a venture diligence is reading for
A venture board reads a technical system as a vehicle that has to make it to the next milestone. The questions are foreshortened by design. Can this team ship the next two quarters of roadmap. Will the architecture hold under the load implied by the business plan through the next round. Are there any red flags severe enough — a missing core engineer, a regulatory exposure, a security incident still in the recent past — to break the deal or to reprice it.
Those are good questions. They are the right questions for a fund whose own clock is running. The fund will, in most cases, be out of the asset within five to seven years. The system does not have to outlive the fund. It has to outlive the fund's holding period and remain saleable to the next buyer.
The diligence reads the next five years and treats anything past it as the next investor's problem. That is not negligence. It is the structure of the instrument.
What a family office is reading for
A family office is asking a different question, often without realising it has changed the question. It is asking whether the company it has bought will still be operable in twenty years, by people who have not yet been hired, on a budget that has to be predictable enough to live alongside the rest of the portfolio. It is not asking whether the system is exciting. It is asking whether the system is survivable.
Three questions tend to separate the two reads.
The first is replaceability. Who, today, can read this codebase, hold the operational model in their head, and continue the work if the present team disappears tomorrow. In a venture context, the answer is often "the team itself, plus whoever the next round funds." In a family-office context, the team will be replaced at least once and probably twice within the holding period. The diligence has to read the system as it would look to the third generation of engineers who will own it — engineers who are not in the building yet.
The second is replaceable architecture, which is not the same thing as replaceable people. A system built around a single proprietary vendor — one model provider, one cloud, one orchestration layer that has no live competitor — is, on a twenty-year horizon, a long bet on that vendor's continued existence on terms the buyer can afford. A venture board can afford to take that bet. A family office, holding the asset across three or four economic cycles, often cannot. The diligence has to read the contractual surface of the system as carefully as it reads the code.
A family office does not exit on a fund clock. It either keeps the asset or sells it on its own terms. The technical risk profile follows from that, and from very little else.
The third is the cost of holding rather than the cost of running. A venture diligence reads the run-rate of the engineering team and asks whether it is consistent with the next round's plan. A family-office diligence reads the run-rate as a recurring line on a P&L the family will be paying for the next two decades, and asks whether the architecture's implicit headcount is honest. Some systems are cheap to run today because they are leaning on the founders' free judgement; the moment the founders leave, the headcount required to replace that judgement appears, and the run-rate doubles. The diligence has to surface that transition cost before the deal closes, not after.
What the deliverable looks like
The studio's family-office diligence is written as a memo, not as a deck. It is structured around the holding-period questions rather than the exit-period ones. It names the vendors the asset is contractually bound to and the cost, in years and in money, of leaving each one. It reads the headcount the system actually requires, separated cleanly from the headcount the system currently has. It records the architectural decisions that will be expensive to revisit and the ones that can be deferred without harm.
It is short. A senior reader at a family office does not have time to read a sixty-page document, and most of what a sixty-page document contains is, in our experience, the deal team writing themselves into evidence. The memo is read once, archived once, and re-read when a material change in the system or in the vendor landscape makes one of its findings out of date.
We do not invoice for the next phase out of the same engagement. The diligence ends when the memo is delivered. If the family office wants ongoing senior counsel on the asset — quarterly reads, vendor change reviews, architectural pauses before large new builds — that is a separate scoped engagement, written down in its own letter, with its own deliverables. The cleanest diligence is one whose author has no commercial interest in the answer.
That is the studio's stance on family-office technical risk. The reader is reading on behalf of an instrument that does not exit. The diligence has to be written for that instrument and for nothing else.