Key person risk: did you buy a product or a person?

In a startup acquisition, key person risk is the question that decides what you actually bought. If two engineers hold the system in their heads and both leave in month three, the product you paid for starts degrading on a schedule. The code stays. The ability to change it walks out.

Most diligence processes treat this as an HR topic: an org chart, a list of employment contracts, a retention budget set by convention. We treat it as a technical question with a technical method, part of every technical due diligence we run. You cannot price key person risk until you know, component by component, who can actually rebuild the thing.

Mapping key person risk: who can rebuild the system

The exercise is concrete. List the components that matter: the data pipelines, the model integration layer, the eval sets, the deployment machinery, the legacy module everyone routes around. For each one, ask three questions. Who built it. Who changed it last. Who gets paged when it breaks at 2am.

Then the harder question: if that person resigned tomorrow, who could rebuild or materially change this component within a quarter, and what would they need to do it.

The answers cluster fast. In a healthy team the map is boring: most rows carry two or three names, and documentation carries part of the load. In a risky one, the same name appears on every critical row, and the second name is nobody.

Self-reporting flatters, so we verify the map against the repository: commit history shows who really works where. On-call rotations and incident reports show who actually debugs production. And the vacation test is real: ask what happened the last time the most-cited engineer was offline for two weeks. If the answer is "we waited", you have your finding.

AI systems concentrate knowledge harder

Classic software spreads knowledge through artifacts. Code, tests, schemas and migrations let a competent senior engineer read their way in. AI systems keep more of their logic outside the artifacts. Why the prompt is phrased that way, why retrieval filters what it filters, why the eval threshold sits at 0.82 rather than 0.9, which data cleaning approaches were tried and abandoned: that reasoning usually lives in one person’s memory of a hundred experiments.

This has a consequence buyers underestimate. You can inherit a working AI system and still be unable to improve it, because every change requires relearning why the current configuration wins. We have seen a team lose the one engineer who understood their retrieval setup; the system kept running for months, but every attempted improvement made it worse, until a rebuild became the honest option.

So for AI components the map gets extra columns. Who understands the eval sets well enough to change them safely. Who knows the failure modes without looking them up. Who has actually rerun the experiments behind the current design. "The model does the work" is not an answer; someone chose everything around the model.

What the map means for price and terms

Retention terms should follow from the map, not from the org chart. If the map says the product is substantially two people, the deal should say so: retention packages sized to the real risk, vesting that covers the rebuild horizon (the time a new team would need to reach the same understanding), and a knowledge transfer plan that starts before close, not after.

A map with one name on every row does not necessarily kill a deal. Sometimes you are knowingly buying the person, and that can be the right trade if it is priced as one: a hire with a product attached. What hurts later is pretending otherwise: paying product multiples for an asset that rides the elevator down every evening.

Mitigation is cheap relative to the risk. A funded documentation and pairing sprint between signing and close, recorded walkthroughs of the pipelines and eval sets, a second engineer shadowing on-call: none of this removes the risk, and all of it shortens the rebuild horizon you are exposed to.

Questions that surface it in an hour

• For each critical component, who besides the author has ever modified it in a meaningful way
• Show the on-call rotation for the last six months, and one incident where the usual person was unavailable
• Which experiments produced the current prompt and retrieval configuration, and where are they written down
• What happened the last time your lead engineer took two consecutive weeks off
• If we funded two weeks of documentation and pairing before close, what would you put in them first

We ask several of these in the CTO session, which is often where the map stops matching the org chart. Evasion here is itself data, the same way it is for the red flags that actually matter.

Small technical teams are still worth buying; the map just has to reach the terms before signing. A risk register without names attached to systems is incomplete.