Key-person risk in the technology: what a reviewer looks for

Every software company has a person the others go to when something odd happens in production. In a small company that person is often the founder who wrote the first version. Sometimes it is a contractor who has worked on the product for years and knows the billing integration better than anyone on the payroll. Sometimes it is the only engineer whose laptop can push a release.

None of this is a sign of a badly run company. It is how most products get built. In a deal it becomes a question with a price attached: how much of the system lives in one or two heads, and what happens to the product when those heads are no longer available every day?

This article is for buyers, sellers and their advisors. It covers how a technical reviewer finds key-person risk in the technology, what evidence counts, how it is rated, what it tends to do to deal terms, and what a seller can do in the months before a sale to bring it down.

Key-person risk, read as a system property

The general version of this problem is about the business: the founder who holds the key accounts, the pricing calls and the vendor history. Our engineering partner PERETZ covers that side in Founder Dependency: The Discount Nobody Puts in the Deck, where the founder becomes a discount in the valuation. A technical reviewer looks at a narrower and more checkable slice of it.

In the technology, key-person risk exists when a critical part of the system can only be understood, changed, released or recovered by one or two people, and the company has no tested way to do it without them. The test is not whether someone is important. It is whether the product keeps running and keeps changing if that person is unavailable for a few months.

It sits in the sixth of our six layers, Team & knowledge, but it touches the others. Admin rights held by one person are also a Security & access finding. A deploy that runs from one laptop is also an Infrastructure finding. Credentials that live in a personal account can become an Ownership problem, the subject of ownership gaps that stop a software deal. The reviewer's job is to see the pattern across all of them, not to count it six times.

Three kinds of people tend to sit at the center of it:

• The founder-CTO, who designed the architecture, wrote most of the early code and still makes every structural decision.
• The long-time contractor, often on a monthly agreement with short notice, who owns a hard integration or a legacy module in practice if not on paper.
• The operator, the one engineer who can deploy, restore a backup, renew a certificate or answer when production fails at night.

Where the evidence comes from

A seller will usually say the team is strong and knowledge is shared. Both may be true. A reviewer looks for the traces the work leaves, under the access protocol: read-only, named accounts created by the company, for the period of the review.

Commit history

The repository shows who changed which parts of the system, and when. A reviewer maps authors to the critical areas: billing, sign-in, data access, integrations, the deploy pipeline. As a rough rule of thumb, when one author made most of the changes to a critical area over the last year, and nobody else has touched it in months, that area has a knowledge concentration worth asking about.

Commit data needs care. Squash merges hide who did the work. Pair programming leaves one name on two people's work. An agency may commit through one shared account. Old email aliases split one person into three. The numbers start the questions; the interviews answer them.

Admin rights and release rights

Who can do what is visible in settings. The reviewer reads the admin lists of the cloud account, the identity provider, the code host, the domain and DNS, the app store accounts, the payment processor and the password manager. Then the release path: who can merge to the main branch, who can approve a deploy, where the deploy runs from, and which secrets it needs. A common finding is a pipeline that works only with a key or a signing certificate kept on one person's machine.

Runbooks, on-call and recovery

Documentation counts when it is current and used. The reviewer asks for runbooks for deploys, rollbacks, restores, certificate renewals and the recurring incidents, and checks their dates against the systems they describe. The on-call schedule, the paging tool and the incident history show who actually answers. If every incident in the last year was closed by the same person, the schedule on the wiki does not matter much.

Undocumented integrations

Integrations with partners, payment providers, logistics systems or a customer's own software are where tribal knowledge collects. The contract terms, the field mappings, the retry logic and the one manual step every month often exist only in someone's memory. The reviewer lists every integration, asks who set it up and who maintains it, and looks for anything that runs on a schedule nobody else can see, such as a cron job on a server only one person can log into.

Chat and ticket history

Team chat is where a lot of real documentation lives. A searchable channel where decisions are explained is a strength, even if it is messy. A pattern where every question ends with the same person's name, or with "I'll handle it", tells the reviewer where the knowledge sits. We read what the company chooses to share, in place, and never copy personal data out of it.

Interviews and a walkthrough

The interviews are where the picture comes together. Useful questions are specific. What would you not touch without asking someone first? Who do you call when the billing run fails? When did someone other than the usual person last release to production? Where the timeline allows, we ask the company's own team to walk through a release or a restore on their own systems, with someone other than the usual person driving, while we observe. We never operate production ourselves.

Signals, checks and typical severity

The table below is a guide, not a formula. The same signal can rate differently depending on whether the person is staying after closing, whether they work under a proper contract, and how central the affected part is to the product the buyer is paying for.

How the rating is decided

Our severity scale has four levels. Critical can stop the deal or should be resolved before closing. High is likely to affect price or terms and needs a plan in the first 90 days. Medium raises the cost of owning the product. Low is hygiene. Key-person findings land mostly in High and Medium, and two questions decide which.

The first is exposure: if the person left next month, what would stop working, and for how long? A product that cannot be released for weeks is in a different place from one where a second engineer would be slow for a month but would get there.

The second is control: can the company fix it with the people and accounts it already holds, or does the fix depend on the goodwill of the key person? A founder who is staying and wants the deal to close is a manageable dependency. A former contractor with the only copy of a signing key, who knows the deal now depends on them, is not.

The deal thesis matters too. If the buyer plans to keep the founder in the role for two years, the same concentration rates lower than if the founder steps back at closing. We write the assumption into the finding, so the rating can be read against the plan. The severity stays ours; the assumption is visible.

Every finding in the report carries a cost and time to fix. For key-person risk that usually means engineer weeks for documentation, shadowing and a second person trained on each critical path, priced at market rates. Each estimate states what it assumes, most often that the key person cooperates and has time to do it alongside the deal.

What it does to deal terms

A reviewer does not negotiate and does not give legal advice. The report gives counsel and the deal team facts and a cost; they choose the instruments. The ones that tend to come up for key-person risk in the technology:

• Retention. A stay agreement or retention bonus for the key engineers, sometimes paid in parts over the transition period. Counsel will ask who exactly must be retained; the review names the roles and the parts of the system they hold.
• Earn-out or deferred payment tied to handover. Some buyers propose that part of the price depends on documented handover milestones, not only on revenue. Milestones work when they are specific and checkable: a second engineer has released to production, the integration runbook exists and has been used.
• Transition services or consulting. A defined period in which the founder or the contractor stays available, with a scope and a number of hours. The review can list what the agreement needs to cover technically.
• A handover package as a deliverable. In effect an escrow of knowledge: runbooks, architecture notes, credentials moved to company accounts and recorded walkthroughs, delivered before closing or as a condition of a later payment.
• Conditions before closing. Access moved to company accounts, signing keys stored with the company, a second admin on every system. These are facts that can be checked, so they fit closing conditions well.
• Price or holdback. Where the dependency cannot be reduced in time but its cost can be estimated, it can show up in the price or in a holdback.

The general flow from findings to terms is covered in technical due diligence for buyers. One point is specific here: retention keeps a person, it does not transfer what they know. A buyer who pays for two years of a founder's time and gets no documentation at the end has bought a delay, not a solution.

Reducing it before a sale

This is the part of key-person risk a seller controls most, and the part that takes longest. Knowledge does not move in a week. A second engineer needs to do a release several times, ideally with something going wrong, before the skill is real. That is months of work alongside running the business, which is why it belongs well before a process starts, not inside exclusivity.

It also cuts against habit. The key person is usually the fastest at the task, and handing it over slows the team down for a while. That slowdown is the cost of making the company transferable, and a buyer can see the difference.

A checklist for the months before a sale

• List the critical paths: release, rollback, restore, certificate and domain renewal, billing run, each external integration, incident response.
• Name at least two people for every path, and have the second person do it for real, more than once.
• Move every admin right, credential and signing key to company accounts and a company password manager, with at least two admins on each system.
• Remove any deploy or scheduled job that depends on a personal laptop or a server only one person can reach.
• Write short, current runbooks for each critical path, and date them. A one-page runbook that was used last month beats a long wiki nobody opens.
• Document every integration: the partner, the contract, the data flow, the credentials, the manual steps and who to call.
• Put contractors on written agreements with clear IP terms and a notice period long enough for a handover.
• Spread on-call across more than one person, and keep the incident history.
• Record walkthroughs of the hard parts of the system, explained by the people who built them.
• Run a handover rehearsal: the key person steps away for a week or two, and the team runs the product. Write down what broke and fix it.

The rehearsal is the most honest test and the one most often skipped. It turns a claim into evidence a buyer can read. The results belong in the technical section of the data room, alongside the runbooks and the access lists.

What cannot be fixed in time can still be disclosed plainly, with a plan and a named person for each step. A known dependency with a credible handover plan reads very differently from one the buyer finds in the commit history in the third week of exclusivity.

What to do next

If you are selling, start with the critical paths and the admin lists, and plan the rehearsal well before a process begins. Exit readiness tracks this work month by month, six to eighteen months before a sale, and ends with a mock review. Once a process is close, vendor due diligence puts the facts in front of buyers on your terms.

If you are buying, ask early in exclusivity who can release, who holds admin rights and who answers incidents, and ask to see it, not hear it. Technical due diligence reads the team and knowledge layer in full alongside the other five, with each finding rated and costed. A red-flag memo answers the narrower question first: is there a dependency here that the deal cannot carry?

Questions