Bus Factor: What Happens to Your Product When the Key Person Quits

Somewhere in your company there is a person whose resignation email would stop the roadmap. Developers have a name for this: the bus factor. Most of the writing about it is aimed at engineers and stops at the definition. This article is for the founder on the other side of that risk: what the bus factor actually is, what a low one costs you in money and valuation, and exactly what to do in the first 30 days when the key person hands in their notice.

Key Takeaways

• The bus factor is the minimum number of team members whose sudden departure would stall or sink a project. It is also called the truck factor or lottery factor.
• It is usually low: a study of 133 popular GitHub projects found 46% had a bus factor of 1 and another 28% sat at 2 (Avelino et al., 2016).
• A bus factor of 1 is not an HR problem, it is a valuation problem. Investors and acquirers price key-person risk through retention clauses, escrows, and discounts.
• Raising it is org design, not heroics: living handover documentation, code review as knowledge transfer, deliberate rotation, and a playbook per senior role.

What is the bus factor?

The bus factor is the minimum number of team members who would have to suddenly disappear, hit by the proverbial bus, before a project stalls because nobody left has the knowledge to continue it. A bus factor of 1 means a single person holds critical, unshared knowledge; a bus factor of 5 means the team could lose several people and keep shipping. The same idea travels under other names: truck factor, lottery factor, and in business language, key person risk.

Engineers treat it as a project health metric. As a founder, read it differently: your bus factor is a line item in your company’s risk profile, one that other people will eventually price whether you measured it or not.

How do you calculate your bus factor?

You do not need tooling to get a useful answer; you need an honest hour. List your critical systems and domains: the backend, the deploy pipeline, the data model, the payment integration, the one gnarly module everyone avoids. For each, write down who could operate and change it alone, today, without help. The names that appear on almost every line are your bus factor, and for most early teams there are one or two of them.

The research says your result is normal. When Avelino and colleagues computed the truck factor of 133 popular GitHub projects, 46% had a truck factor of 1 and another 28% had 2, meaning roughly three-quarters of well-known open-source systems depended on one or two people (Avelino et al., 2016). Startups, with smaller teams and more time pressure, are rarely better.

What does a low bus factor actually cost?

The bill arrives in three installments. First, replacement: losing an employee costs between 50% and 200% of their annual salary, and senior technical roles sit at the top of that range once recruiter fees, interview time, and the empty seat are counted (4dayweek.io, 2026). Second, time: hiring alone averages around 68 days (onehour.digital, 2026), and a new senior engineer commonly needs three to eight months to reach full productivity. Third, and largest for a startup: the roadmap. Whatever only the departed person could build now waits for a stranger to learn your codebase.

Why do so many good teams end up here anyway? Because early on it is genuinely the fastest way to build. One brilliant person owning everything is how MVPs ship. A bus factor of 1 is usually a rational early-stage choice; the mistake is not having made it, it is failing to notice when it expired. It expires, roughly, at the moment your company would not survive that person’s notice period.

How do investors and acquirers price key-person risk?

Directly, and earlier than most founders expect. Team evaluation is a standing section of technical due diligence: auditors map who built what, check whether documentation exists beyond one person’s head, and sometimes interview the key engineer specifically to gauge how much of the company walks out if they do.

When the answer is “one person holds it,” the deal does not usually die. It gets repriced. The standard mechanics are retention bonuses tied to earn-out periods, escrow arrangements that hold back part of the price until continuity is proven, and in blunt cases a straight discount. At acquisition, the technical due diligence checklist treats key-person dependency the same way: a finding that reliably survives into the term sheet.

The uncomfortable summary: founders usually discover their bus factor in a data room, at the exact moment it is most expensive to fix.

What do you do in the first 30 days after the key person quits?

Treat the notice period as a project with a deadline, not a countdown to be endured. A typical four-to-eight-week notice is enough to convert a crisis into an orderly handover, if you run it deliberately from day one.

Week 1: triage access and map the unknown.

1. Inventory credentials, deploy rights, vendor accounts, and API keys the person holds, and plan their rotation for the departure date. Leaked and lingering access is not hypothetical: 64% of credentials exposed in 2022 were still valid years later (GitGuardian, 2026).
2. Freeze risky, discretionary changes to the systems only they understand.
3. Sit down with them and list what exists only in their head. You are mapping the undocumented, not the documented.

Weeks 2-3: transfer with structure.

4. Run recorded handover sessions per system, written up into documents afterward. Conversation evaporates; documents survive.
5. Pair the departing person with a named successor for each critical area, working real tickets together, not watching demos.
6. Prioritize ruthlessly by the map from week 1: undocumented and critical first, documented and stable last.

Week 4: re-own everything explicitly.

7. Assign each system a new named owner, even if their first job is “learn it.”
8. Update the knowledge map and decide honestly what cannot be absorbed internally, and whether a contractor, an agency, or fractional technical leadership bridges the gap.
9. Close the loop on access rotation and offboarding.

The single biggest mistake in this window is spending it on the replacement hire instead of the knowledge transfer. The hire takes 68 days on average; the person who can still explain everything is gone in 30.

How do you raise your bus factor without slowing down?

The standard advice, documentation, pair programming, rotation, code review, is correct and usually ignored, because it is framed as overhead. The version that survives contact with a real roadmap treats knowledge distribution as a byproduct of normal work rather than a separate chore:

• Handover documentation as a living artifact, per senior role. Not a wiki graveyard: one document per senior person covering how their systems work, how they decide, and what they would hand over tomorrow. It is the artifact a diligence team asks for and almost nobody has.
• Code review as knowledge transfer, not gatekeeping. The reviewer is the second person who now understands the change. Assign reviews against knowledge silos, not by availability.
• Rotation with a purpose. Not everyone rotates everywhere; the named successor for each critical system works in it quarterly, on real tickets.
• AI-assisted knowledge capture. Sit senior people down with an AI assistant and turn their tacit practices, how we scope, how we estimate, what we check before a release, into written playbooks in hours instead of weeks. The documentation bottleneck was never typing, it was extraction, and that is what changed.

We run these as standing discipline at VeryCreatives, playbooks per senior role, refreshed and reviewed, because an agency’s product is continuity. It is also simply cheaper: an hour a month of playbook maintenance against a 50-200% salary replacement bill is not a close call.

Can an external team lower key-person risk?

Honestly: only if the engagement is designed for it. Handing your product to an agency with its own bus factor of 1 just relocates the risk and adds an invoice. The questions that matter are the same ones you would ask internally: how many of their people hold context on your product, what documentation exists independent of any individual, and what does their handover look like if you part ways.

Done right, though, an external team is a continuity instrument, and there is a hard test for it: acquisition. Our clients’ products have been through acquisition-grade due diligence multiple times, and each time the acquirer examined the code, the documentation, and the distribution of knowledge, then retained VeryCreatives as the technical team after the deal closed. Buyers keep a team when the audit shows the knowledge lives in systems and documents, not in one irreplaceable head. That is the bus-factor test that matters commercially, and it is passable by design.

If your product currently depends on one person, and there is a raise, an exit, or simply a fragile roadmap ahead, book a call. We will tell you honestly where the risk sits and what it takes to distribute it, whether or not that involves us.

Frequently Asked Questions About Bus Factor

What is a good bus factor?

High enough that losing any single person does not stall the product; in practice, 3 or more for the core system of a small team. Research shows most projects are far from this: 46% of popular GitHub projects had a bus factor of 1 (Avelino et al., 2016).

What is the difference between bus factor and key person risk?

The same risk seen from two altitudes. Bus factor is the engineering metric: how many people can leave before the project stalls. Key person risk is the business framing: the exposure a company carries when revenue, knowledge, or operations depend on one individual. Investors use the second phrase and measure the first.

How do I find out my company's bus factor?

List your critical systems, then write down who could operate and change each one alone, today. The names appearing on nearly every line are your bus factor. Tooling exists that estimates it from repository history, but the honest one-hour exercise above finds the same answer for a startup-sized team.

What should I do first when my lead developer resigns?

Triage access and map the undocumented, in the first week. Inventory the credentials and deploy rights they hold and schedule rotation, freeze risky changes to systems only they understand, and list what exists only in their head. Structured, recorded handover sessions come second; the replacement hire, which averages 68 days (onehour.digital, 2026), comes after both.

Does key person risk affect valuation?

Yes, mechanically. Technical due diligence maps who built what, and a bus factor of 1 typically produces retention bonuses tied to earn-outs, escrow holdbacks, or a price adjustment. Losing the person outright costs 50-200% of their salary in replacement alone (4dayweek.io, 2026), and deals price that exposure in.

What is handover documentation?

A living document, maintained per senior role, that records how that person's systems work, how they make decisions, and what they would transfer if they left tomorrow. It differs from a wiki by having an owner, a cadence, and a reader in mind: the successor. It is also one of the first artifacts a due diligence team asks for.

Conclusion

Every company has a bus factor; most just have not measured it. Measure yours with the one-hour exercise, raise it with habits that ride along with normal work, and keep the 30-day playbook current in the hope of never opening it. The pattern we see across every audit our clients’ products have passed: resilient companies make knowledge a property of the system rather than the person. That is a design choice. Make it deliberately, and make it early, because technical due diligence will eventually make it for you.