Bus Factor as a Startup Survival Risk
It's 11 PM and production is down. One engineer knows why, knows where the logs live, knows which environment variable is lying. Everyone else is refreshing a dashboard and waiting. That scene is the entire concept of bus factor in miniature: how many people would need to vanish before a project or company grinds to a halt because the knowledge to keep it running left with them.
The term comes from software development, where it's also called "truck factor" or "lottery factor." An early reference traces to the patterns literature presented at the first PLoP conference in August 1994, later published in the Pattern Languages of Program Design book in 1995. A bus factor of 1 means a single person holds critical, unshared knowledge, and the project stalls the moment that person is unavailable. A bus factor of 2 or higher means the team can absorb any one departure and keep shipping.
None of that is a judgment on how hard anyone works. Bus factor measures structural resilience, not productivity or individual value. Founders usually hear the concept framed as a grim hypothetical, the "what if your best engineer gets hit by a bus" question, which makes it sound like a freak accident rather than what it actually is: a daily background probability in an industry where engineers change jobs often. The question is whether the system notices someone leaving before it happens.
Why startups generate bus factor 1 by design, not by accident
Bus factor 1 appears in nearly every early-stage company for the same structural reasons. Small teams mean there are fewer people available to share knowledge with in the first place. Rapid iteration means decisions get made faster than anyone can document them. Deferred overhead, the thing that makes a startup fast and cheap to run, is precisely what keeps knowledge locked inside one or two heads.
Culture reinforces the pattern. "Move fast and break things" treats documentation as corporate drag, and the result is process debt: a set of informal fiefdoms where nobody quite knows what anyone else is doing. Hero culture adds a second layer. The engineer who fixes the 2 AM outage gets celebrated, and that celebration quietly rewards knowledge hoarding. Being the only person who can fix the thing confers status and job security, so there's little incentive to spread the knowledge around.
Founders are often the single point of failure themselves. Staying in founder mode, owning architecture decisions, holding deployment access, managing the key integrations personally, just relocates the bus factor problem from the team to the person running the company. And the first technical hire almost always creates bus factor 1 by definition: one engineer, one codebase, one person who understands both. It's the rational tradeoff for speed at a stage where speed is close to the only thing that matters.
The moment bus factor 1 stops being a rational tradeoff and becomes an existential risk
Bus factor 1 is a reasonable early-stage choice. The mistake founders make isn't making that choice but failing to notice when it expired.
That expiration point has a rough marker: the moment the company would not survive that person's notice period. Before that point, losing the key engineer is painful but recoverable, a setback measured in weeks. After it, the same departure can be terminal. Real users on the product, revenue flowing, a roadmap that depends on continuity: these are the signs that the clock has already started.
The MVP-to-production transition is where this expiration typically happens, and it's the exact moment many early-stage teams discover they need specialized help. In MVP mode, one person owning everything is fast and lean. In production mode, that same person becomes the only map to the system: the only one who knows the architecture, the database quirks, the deployment process, the third-party integrations, and the handful of hidden workarounds holding it all together. A startup where the CTO alone deploys has a bus factor of 1 for production, full stop on the mechanism, however fine the rest of the team might be. A CI/CD pipeline and delegated deploy roles fix that specific dependency, but only if someone notices it before the CTO is gone. Product engineering studios that focus on rebuilding MVPs for production reliability often spend this phase explicitly distributing knowledge across the team and documenting architecture, raising the bus factor as a byproduct of making the system resilient. Noticing the expiration date is only the first step. What it actually costs to miss it is the next question.
The real cost of a departure when bus factor is 1
The cost of losing a key engineer under bus factor 1 doesn't land all at once. It arrives in three waves, and each one builds on the last.
The first wave is replacement cost: recruiting, interviewing, and closing a new hire who can do the job. The second wave is time cost: the weeks a new engineer spends simply getting oriented, made worse because there's no one left who can answer basic questions quickly. The third wave is roadmap cost, and for a startup it's usually the largest of the three. Whatever only the departed engineer could build or maintain now sits waiting for a stranger to learn an undocumented codebase from scratch. This is where bus factor 1 diverges sharply from ordinary turnover. Replacing a salesperson or a support rep costs time and money, but replacing the one engineer who held the system in their head costs the system's own legibility.
Recovery from a key engineer's departure on a low-bus-factor system can take up to six person-months, with some subsystems rewritten from scratch. For a bootstrapped startup, the three waves together can approach twice the departing engineer's annual salary, and that's before counting the compounding cost of growth that stalls while the recovery is underway. This is particularly acute for teams that shipped an MVP quickly using AI-generated code or contract developers, where the real issue isn't team size but whether anyone on the founding team fully understands the codebase they inherited, which can put the bus factor in dangerous territory before the company has even made its first engineering hire.
How technical debt and bus factor reinforce each other
Technical debt and bus factor aren't two separate problems sitting side by side. They feed each other: fixing one without the other tends to fail.
Documentation debt is the clearest version: decisions made under speed pressure go unrecorded, so the only person who knows why the system works the way it does is the person who built it. Testing debt compounds it. Without tests, nobody who didn't write the code can safely touch it, which structurally locks in the original developer's monopoly on the system whether anyone intends that or not. Architectural debt adds a third layer. Technology choices made by a single developer often reflect what that person was already comfortable with rather than what the product actually needed, and when that developer leaves, the team inheriting the system can find the architecture actively working against the next phase of the roadmap.
A newer variant tightens this loop further. When code gets generated by AI, committed, and pushed to production without any human fully understanding how it works, the team can reach bus factor zero: no one is the expert, so there's no one to transfer knowledge from even in principle. That's a meaningfully different situation than bus factor 1, where at least one person could, in theory, explain the system to somebody else. Strong tooling doesn't rescue a team from this. A team can run a polished CI/CD setup and still be fragile if the knowledge needed to use that tooling lives in only a few heads, because tooling makes work move faster without making anyone smarter about the system underneath it.
Why nonprofits and open-source ecosystems show the worst cases
Bus factor 1 does its worst damage where there's no commercial incentive pushing anyone to fix it, and it is most visible in open-source infrastructure and nonprofit software.
The left-pad incident is the textbook case. In 2016, a single maintainer pulled a tiny NPM package, and thousands of software builds that depended on it broke overnight, a demonstration of bus factor 1 playing out at the scale of an entire ecosystem. The XZ Utils incident in 2024 made the stakes sharper still: an attacker nearly succeeded in slipping a supply-chain backdoor into widely used compression software by targeting a single, exhausted volunteer maintainer. The bus factor wasn't incidental to that attack. It was the attack surface. OpenSSL, at the time the Heartbleed vulnerability was disclosed, had one full-time developer maintaining code that underpinned a meaningful share of the internet's encrypted traffic, and the remediation cost afterward ran into the hundreds of millions of dollars.
Nonprofits running custom internal tools sit in a similar structural position, usually without the headline-grabbing failure to go with it. When the one developer who built an internal tool leaves, there's often no budget to reconstruct it and no documentation to hand off, so the tool just quietly stops being usable. The pattern generalizes past both of these examples: wherever the person holding critical knowledge has no organizational push to share it, no code review culture, no documentation norm, no budget set aside for redundancy, bus factor 1 persists indefinitely until something forces the issue.
How investors and acquirers price bus factor risk (and when founders find out)
Founders usually learn their actual bus factor in a data room, at the exact point in the process where it's most expensive to fix.
When the honest answer to "who else knows this system" is one person, the deal rarely falls apart outright. It gets repriced instead. Retention bonuses get tied to the earn-out period. Escrow arrangements hold back part of the purchase price until continuity is proven over time. In more direct cases, the buyer simply applies a discount to the offer. The same dynamic occurs earlier, in funding rounds: investors see a company concentrated around one or two engineers as harder to fund, harder to sell, and more exposed to a painful pivot if those people leave. For PE-backed organizations the exposure compounds across an entire portfolio, since each company where critical knowledge sits in one or two engineers carries hidden exit risk on its own, and technical due diligence audits that risk before it turns expensive.
A founder who addresses bus factor ahead of time is solving an engineering problem with a known set of solutions. A founder who discovers it during due diligence is negotiating from a position with no good options left, because the other side has already done the math.
Running a bus factor audit before a crisis forces one
A bus factor audit doesn't require new tooling, outside consultants, or a formal review process. It requires an honest inventory of critical functions and the people who could actually run them without help, and most founders can run a first pass in an afternoon.
List critical functions, not job titles. Billing, deployment, customer onboarding, sales handoffs, investor reporting, CRM hygiene, legal agreements: anything that keeps the business running day to day belongs on the list.
Assign a real person count to each function. For every item, ask honestly who could complete it tonight if the usual person were unreachable. "The instructions are written down in Notion" doesn't count as coverage if nobody has actually read them.
Flag the red zones. Any function with a bus factor of 1 is a red zone. Any critical function that only the founder can perform is a five-alarm fire, regardless of how small the company still is.
Prioritize by impact and probability. Not every red zone carries equal weight. Weigh each one by how much breaks if that person disappears and how long the business would stay broken.
A few supplementary checks surface concentration even without running the full audit. Pull up pull-request review assignments from the last quarter: if one person is consistently the sole reviewer on a critical path, the data shows concentration. Ask a new hire or a junior engineer which part of the system makes them nervous to touch; their answer will usually point straight at a single point of failure they've already bumped into. Check on-call escalation paths too: if the same one or two names appear as the de facto experts across every incident in a given area, act on it. One pass tells a founder where things stand today. Running it quarterly, the way teams revisit test coverage or deploy frequency, tells them whether the number is actually moving.
Structural mitigations that raise bus factor over time
Raising bus factor is a set of structural changes that each redistribute knowledge a little further, building on each other.
Code review requirements are the simplest starting point: if every change needs a second set of eyes before merging, knowledge transfer happens automatically as a side effect of normal work, with no extra meeting required. Pairing and rotation do the same thing deliberately, by making sure more than one person touches each critical system over time instead of letting ownership calcify around whoever built it first. Documentation norms record why decisions were made, since the "why" is usually what's missing when a new engineer inherits a system.
CI/CD pipelines and delegated deploy access directly solve the problem of a single person being the only one who can deploy: once more than one person can safely ship to production, that particular single point of failure closes. Testing coverage does something similar for the fear that keeps systems frozen around one person, since a codebase with real tests can be touched safely by someone who didn't write it, which is exactly the condition testing debt removes.
The roadmap cost described earlier is where bus factor 1 turns genuinely terminal, because what matters is whether the system remains legible, not how many people are on the team. A stranger inheriting an undocumented codebase doesn't just work more slowly. They tend to discover architectural choices or workarounds that were never written down anywhere, which forces either a rebuild just to understand what's actually running or months of guesswork before real progress resumes. Raising bus factor, in the end, is about whether the system itself can be understood by someone who didn't build it, which is the exact condition a formal technical assessment before signing with a development partner is meant to establish up front.