Solo Founder SaaS Acquisition: Key Person Risk Due Diligence, How to Price It and Structure Around It

Short answer: in a solo founder SaaS acquisition, key person risk due diligence means proving how much of the business is the person rather than the product. Run eight checks before you sign: who has spoken to the top ten accounts, who ships code, who answers support, who holds the credentials, what is documented, what the founder's real weekly hours are, whether anyone else can deploy, and what happens to renewals if they stop replying. Founder dependency is the single most common reason a small software deal is repriced in diligence. Last updated September 2026. Educational only, not financial or investment advice.

It is also the risk buyers price most crudely. Concentration in customers gets a spreadsheet; concentration in people gets a gut feeling. That asymmetry is strange, because a one-person software company is the most common thing on a marketplace and the easiest thing in the world to overpay for. The useful move is to treat founder dependency as something you measure before you make an offer, because what you can measure you can structure around, and the four structures at the end of this page are the ones that actually hold.

Everything below is written for the buy side of a small US deal, the kind where the seller is one person and the purchase price is somewhere between $50,000 and a few million. If you are financing with an SBA 7(a) loan, read the section on lenders carefully: founder dependency is not just a pricing question there, it is an underwriting question, and it is where these deals die.

What is key person risk?

Key person risk is the exposure created when a single individual holds knowledge, relationships or authority that the business cannot replace quickly. It is not about whether someone is talented. It is about whether the operation degrades if they stop answering messages. In a small SaaS business the founder often is the product roadmap, the only person who has ever spoken to the top ten accounts, and the only one who knows why a particular cron job must run before billing.

For an acquirer the question has a narrow, cash-shaped form: if the founder disappears ninety days after close, what breaks, how fast, and what does fixing it cost? Everything else is commentary.

What is key man risk?

Key man risk is the same concept under an older name, still common in lending and insurance documents. You will see key person risk, key man risk and key person dependency used interchangeably in deal paperwork. There is no technical difference between them. If a lender or an insurer uses the older phrasing, they mean exactly what the term above means.

How do you assess key person risk before buying?

Work through what the person actually does rather than what the org chart says. The questions below are the ones that reliably separate a business that runs from a business that is being carried.

What you check	The answer that stops the deal
Sales	The founder closes every real account
Customer relationships	Customers have his or her mobile number
Code and infrastructure	One committer, no runbook
Vendor and platform accounts	On a personal email nobody else opens
Institutional knowledge	All of it is in the founder's head
Time to run	Full-time effort described as passive
Deployment access	Nobody else has pushed to production
Renewals	Nobody else owns a renewal conversation

The other half of that table is what a healthy answer looks like, and it is worth stating because it is what you are buying rather than what you are avoiding. Sales should be inbound or self-serve with a documented funnel. Support should run through a shared desk or inbox with named account owners rather than a personal phone. More than one person should have deployed code in the last quarter. Vendor and platform accounts should be company-owned and sitting on a shared credential system. Runbooks, onboarding docs and recorded decisions should exist. And the hours per week the seller claims should be independently plausible against the commit log, the support queue and the invoices.

Solo founder SaaS acquisition: what key person risk due diligence actually asks for

Ask for six artifacts and read them rather than the listing. The commit history with author names for the last twelve months. The support desk export showing who replied. A list of the top ten accounts with the name of the person each one deals with. The credential inventory, showing which accounts sit on a personal email. Any runbook or onboarding document that exists. And the founder's own calendar for a normal month. Six documents, and between them they answer the question the seller's narrative cannot.

The reason this matters more on a one-person software business than anywhere else is that the financials look identical either way. A $20,000 a month product with one owner and a $20,000 a month product with a team of four produce the same profit and loss statement, and only one of them survives the owner walking away. That is also why the tax code stumbles into the same problem from the other direction: section 1202(e)(3)(A) denies the qualified small business stock exclusion to any trade or business whose principal asset is the reputation or skill of its employees, which is key person risk written into the QSBS rules.

Two of these deserve extra weight because they are cheap for a seller to fix and therefore telling when unfixed. Vendor accounts on a personal email are a transfer problem you will inherit on day one. A single committer with no written runbook means the first incident after close is an emergency rather than a ticket. If the founder was also the only person watching the systems, budget for the monitoring layer they never needed: someone has to notice when a pipeline silently stops delivering data, and inheriting a stack where nobody is alerted when a data feed goes stale is a common and avoidable surprise in the first quarter.

The lean team paradox

Here is the tension that makes this risk hard to price. Efficiency and key person risk are the same fact viewed from two sides.

A tiny team producing real revenue scores brilliantly on every efficiency measure. Private SaaS companies run a median of $141,125 of revenue per employee, and AI-native startups have been reported in the $2M to $4M range. Those numbers get quoted as proof of a superb business, and often they are. But revenue produced by three people is revenue that depends on three people. The same leanness that lifts margin concentrates knowledge.

So when a listing boasts about how few staff it needs, read it as two claims at once: the cost base is genuinely low, and the replacement cost of any single person is genuinely high. Both are true. Only one of them is in the pitch.

How do you mitigate key person risk in an acquisition?

You cannot remove it before closing. You contain it with structure, and structure is what most of the negotiation is really about.

A transition period with defined deliverables. Thirty days of vague availability is worth very little. A written handover covering deployment, billing, the top twenty accounts and every vendor credential is worth a lot. Specify the deliverables, not the hours.

An earnout or holdback tied to what you are actually worried about. If the concern is that the founder's relationships carry the revenue, tie a portion of consideration to retention over the following two to four quarters. This is the same tool used for customer concentration risk, applied to people instead of accounts, and it works for the same reason: it moves the risk back to the person who knows whether it is real.

A consulting agreement with a real scope. Useful when you need the founder's technical knowledge but not their time. Price it properly and keep it short. An open-ended arrangement tends to preserve the dependency rather than unwind it.

Documentation as a closing condition. The cheapest mitigation available. Make runbooks, credential transfer and an architecture overview conditions of close rather than post-close promises. A seller who resists this is telling you something useful.

Does keeping the founder on affect SBA financing?

Yes, and it catches buyers out. If you structure a partial change of ownership so the founder keeps equity, which is a common way to hold a key person in place, the SBA's SOP 50 10 8, effective 1 June 2025, requires personal guarantees from all equity holders for at least two years. That means the founder personally guarantees your acquisition loan. Some founders accept it; many refuse once they understand it, and the deal has to be restructured late.

A complete change of ownership works differently: guarantees are not required from investors holding under 20%. If you are financing with an SBA 7(a) loan, decide early whether the founder is staying on as an owner or as an employee, because those are different transactions to a lender. The wider mechanics are covered in our guide to using an SBA loan to buy a SaaS business.

What is key person insurance and does it help?

Key person insurance is a policy the company holds on an individual, paying out to the business if that person dies or becomes disabled. It is genuinely useful and frequently misunderstood, because it covers the two things least likely to happen. It does not pay out when a founder gets bored, takes a job, starts a competitor or simply stops caring six months after being paid.

For acquisition purposes, insurance is a backstop for catastrophe and contract is the tool for everything else. Non-compete and non-solicit terms, a defined transition, and consideration held back against retention do more practical work than a policy will. Buy the policy if a lender requires it or if one person truly is irreplaceable, and do not treat it as having solved the problem.

Does key person risk reduce the valuation?

It changes the structure before it changes the headline number. Sellers tend to expect a discount and instead meet a deferral: the multiple survives, but a slice of the money moves behind an earnout or a holdback. That is usually the right outcome for both sides, because the seller keeps their price if the business performs and the buyer stops paying today for continuity that has not been demonstrated.

Where it does hit price directly is in financed deals. A lender assessing a business that depends on one person will look harder at the debt service, and a buyer who has to service acquisition debt cannot absorb a bad first year. If you are working out what a business should be worth before you get into structure, our SaaS valuation calculator and the current SaaS valuation multiples give you the baseline that this risk then adjusts.

What should a seller do about it?

Reduce it before you list, because it is one of the few risks a seller can genuinely fix in a quarter. Move vendor accounts to company-owned credentials. Write the runbook. Get a second person deploying. Route customer email through a shared inbox rather than your personal one. Record how you actually make the decisions you make.

None of that changes revenue, and all of it changes how the business reads in diligence. The work also shortens the process, which matters more than sellers expect given how long these transactions take. Buyers can only move quickly on businesses they can understand quickly, and the rest of the diligence sequence is set out in our SaaS due diligence checklist.

The honest summary

Key person risk is the one item in SaaS diligence with no benchmark to hide behind. There is no published percentage, no median, no threshold that separates acceptable from unacceptable. What exists is a set of observable facts about who does what, and a set of structures that shift the exposure back onto whoever is best placed to judge it. Gather the facts, pick the structure, and price the business on what it does without the person selling it to you.