Bus factor: what every non-technical founder should know when one developer holds the codebase
Carla was three hours into a client trip in Austin when the WhatsApp came in. Her only developer, Vinicius, was in an emergency room with a ruptured appendix. He was going to be fine. The Tuesday release was not. There was a payment bug in production that he had been quietly fixing on the side. There was a pull request open on a feature she had committed to a customer for the following week. There was a database migration he had scripted that nobody else in the company had ever looked at. Carla, COO and co-founder of a 14-person legaltech, sat in the back of a Lyft and tried to figure out who, on her team, could even open the codebase.
Nobody could. The answer was nobody.
That is what bus factor measures. The bus factor of a piece of software is the number of people on the team who would have to disappear, simultaneously, for the project to grind to a halt. The classic version of the question is morbid (the bus). The honest version is mundane: the developer takes a job at Anthropic, goes on paternity leave, gets appendicitis, or simply rotates onto another client and now answers your Slack three hours late. In all those cases the bus factor of your product is the same number, and for most early-stage startups built around a single engineer, that number is one.
This article is for the non-technical founder reading the previous paragraph with the precise feeling of dread that comes from recognising oneself in it. It does three things. It tells you what bus factor actually measures inside your company, separately from what an engineering blog will tell you it means. It explains why the obvious fix (hire a second developer) usually makes the dependency worse before it makes it better. And it gives you a four-step plan you can run this quarter without doubling your headcount.
What bus factor really means, in one paragraph
Bus factor is the minimum number of people on a project who, if they suddenly stopped contributing, would leave the work unable to continue. The term first surfaced in programming communities in the 1990s as gallows humour about key-person risk. A project with a bus factor of one is a project where exactly one person can move the code forward. A project with a bus factor of three is a project where three people would have to vanish at the same time before the work stops. Higher is safer. Lower is more fragile. For a non-technical founder, the working definition is simpler still: bus factor is the question of how many people in your company can ship a fix to your live software tomorrow morning, with no notice, and without breaking the rest of it. For most startups with a single developer, the answer is one. The answer being one is not unusual. The answer being one and you not knowing it is the actual problem.
Three problems hiding inside one question
When a founder says “I’m worried about what happens if my developer quits,” they are actually worried about three different things and they get conflated. Separating them is the first move, because each one is solved by a different intervention.
Knowledge concentration
The first problem is that the live software is a working system, but the explanation of why it works the way it does lives in one person’s head. Why is the payments table denormalised? Why does the auth flow have a 90-second timeout? Why is there a Cloudflare worker that rewrites the URL on Tuesday nights? The code shows you what is happening. It does not show you why. Reasoning, trade-offs, and the long catalogue of “we tried that and it broke production” decisions are tacit knowledge. They never make it into the repo. When your one developer leaves, the code is still there. The reasons it is shaped like that are not.
The signal that this is your problem: you can read who wrote which file, but you cannot find a single document, comment, or recorded meeting that explains the architecture choices you have already paid for.
Operational continuity
The second problem is that even if the system kept running on autopilot, you have no one who can change it. A small production fix on Tuesday morning is a different animal from rebuilding the system from scratch. The first asks: can someone you trust open the project, find the bug, ship a patch, and not break the rest? If the answer is no, then a routine inconvenience (a developer on vacation, a flu, a delayed return from holiday) becomes a customer-facing outage. This is the bus factor problem in its narrowest, most immediate sense, and it is the one most founders feel first.
The signal that this is your problem: a feature has been “almost ready” for two months and nobody but the original developer can answer where it stands.
Strategic ownership
The third problem is more abstract and the one founders rarely see until they are deep into it. Who decides what the codebase becomes next? When the only person who fully understands the current system is also the only person able to credibly tell you what is and is not buildable in the next six months, your product roadmap is implicitly being co-authored by that one person. Their incentives and your incentives may overlap perfectly. They may not. Either way, a roadmap with a strategic single-point-of-failure is a fragile roadmap.
The signal that this is your problem: when you bring product ideas to your dev, every answer is shaped as “we would have to rebuild X” or “we already tried Y” and you cannot independently evaluate whether those framings are accurate.
These three problems answer the same surface question. They do not get fixed by the same intervention. A common founder mistake is to try to solve all three by hiring a second developer at once, and that move tends to fail by addressing none of them in particular.
Why your bus factor is probably 1 and you don’t know
Most non-technical founders, when asked, will say they think their bus factor is probably 1, but they don’t actually know. Three confusions are usually responsible.
The first is counting people who have touched the repo. A founder with one developer and a part-time contractor will count the contractor. The contractor has shipped four pull requests this year, all of them small, all of them inside parts of the system the contractor already knew. The bus factor is not the number of people who have touched the repo. It is the number of people who could open the laptop tomorrow and fix the bug in production that the founder cannot describe. That number is almost always one.
The second is mistaking “having backups” for “having redundancy”. Backups protect data. Redundancy protects continuity. The codebase is in GitHub. The infra runs on AWS. Every secret is in 1Password. That is data redundancy, and it is good. It says nothing about whether anyone else in the company can take the bus factor up from one. A backup is a frozen photograph of the system. Redundancy is a second person who can drive the car.
The third is mistaking “we have documentation” for “we have transferable knowledge”. A wiki page that says “the auth flow is in /src/auth” is technically documentation. It does not transfer the knowledge of why the auth flow times out at 90 seconds. The test of documentation is not whether it exists. The test is whether a competent new developer, given the docs and the codebase, could ship a routine fix in their first week without the original author present. That bar is much higher than most founders realise.
The common fix that makes the problem worse
The most common founder reaction to discovering a bus factor of 1 is to hire a second developer. This is sometimes the right move and usually executed wrong. You hire Developer Two. You bring them on, give them access to everything, point them at the codebase, and ask them to “ramp up”. For the next two months, Developer Two writes some code, learns the system, and asks Developer One for context constantly. Developer One, who is already at 110% utilisation, becomes the bottleneck on Developer Two’s learning, and so the company goes from one productive developer to a hair under one productive developer plus a more expensive payroll.
At month three, one of two things happens. Developer Two has internalised enough of the system to be useful and your bus factor is now 2. Or Developer Two has internalised the surface of the system but not the reasons, and so your bus factor is still 1, just hidden by the existence of a second person who can plausibly answer “I’ll look at it.” This second outcome is more common and harder to detect because the headcount has doubled.
The deeper issue is that “hire a second developer” confuses payroll with redundancy. Two developers who both depend on the same single person to explain the codebase are a bus factor of 1, no matter how many people are on the team. The redundancy you want is not in headcount. It is in transferable knowledge. The headcount only becomes useful once the knowledge has been externalised.
The right sequence is externalise first, then hire. The remainder of this article is the playbook for doing it in that order.
Five questions to ask if you have a sole developer
Before you make a single move, run the five-question diagnostic. Each answer is a paragraph, not a yes or no. The point is to get a clear-eyed picture of your real exposure.
1. Could a new developer, given the repo and the docs, ship a routine bug fix in their first week without your current developer present? This is the practical test of how much knowledge is captured in writing versus how much lives in a head. If the honest answer is “no”, you have a knowledge-concentration problem, not a hiring problem.
2. Can your current developer go on vacation for ten days and your business not stop? This is the operational-continuity test. If a normal vacation feels risky, you have a continuity problem. The fix may not be a second person. It may be process: a documented release procedure, a customer support playbook for known bugs, a clear rule for what gets postponed versus what gets escalated.
3. When you bring product ideas to your developer, can you independently evaluate the technical answer they give you? This is the strategic-ownership test. If every “we can’t build that because…” is impossible for you to push back on, you do not have a roadmap problem with your developer. You have a roadmap problem with yourself, and the answer is independent technical advice, not a second hire.
4. If your current developer left tomorrow with two weeks notice, what would the handover document need to contain for the company to function? This is the most useful single exercise in this article. Most founders, when asked, realise the document does not exist and cannot easily be written. The exercise of writing the document is the externalisation.
5. Are you funding software because it is core to your business, or because you cannot afford not to be? This is the question nobody asks. Some companies have one developer because that is genuinely the right shape for the stage. Other companies have one developer because they wandered into custom software and now feel locked in. The latter case sometimes resolves not by raising the bus factor but by reducing the surface area of custom code (see how to create software when you don’t write code for the diagnostic that distinguishes the two).
The answers to these five questions tell you which of the three problems above is yours, and that determines what you do next.
Four steps to raise your bus factor without doubling headcount
If the diagnostic confirms you have a bus factor problem and not a roadmap problem or a process problem, here is the sequence that actually works.
Step 1: Externalise the highest-risk knowledge first
The first move is not a hire. It is a writing exercise. Sit with your developer for two hours a week, every week, for four weeks, and produce a small set of documents written for a new developer who does not yet know the codebase. Not autogenerated docs. Real prose. The set is short.
A one-page system map: what the major moving parts are, what they do, what calls what. A one-page operational runbook: how releases happen, where alerts go, what to do at 3am when the payment gateway is down. A one-page architectural decision log: the four or five decisions that constrain the system today, why each was made, and what was considered and rejected. An “if I had to leave tomorrow” handover document, written by the developer in their own voice, listing the open loose ends, the half-finished features, the parts of the code they would not want a junior engineer to touch without guidance, and the explicit list of things they have been meaning to fix but have not.
If your developer pushes back on this exercise, that is itself a finding. Some developers resist documentation because the implicit contract has been “you do not need to know what I know”. That is not always conscious and it is not always malicious, but it is a signal worth noticing. Bring it up directly: this work is for the company, not for you, and it will help when they go on holiday too.
Step 2: Buy down the dependency in commits, not in headcount
The lowest-cost, highest-leverage move available to a non-technical founder with a sole developer is to bring in a second pair of hands part-time, not as a peer hire, but as a knowledge-transfer mechanism. Three options work in practice. A fractional senior engineer who does code review and pair-programming for four hours a week. A small partner team (a focused software house or a trusted contractor pair) who picks up one bounded workstream and ships it themselves while running questions through your current developer. Or a single senior engineer hired specifically to shadow and absorb, with the explicit mandate that their first six weeks are learning, not shipping.
The reason this works better than a peer hire is that the explicit goal is knowledge transfer, not headcount growth. The contract is short. The cost is low. The bus factor moves from 1 toward 2 in commits, slowly, and what you are buying is a second person who has actually touched the production code. For a deeper comparison of these structures, the in-house vs outsourcing decision covers the same ground from the other direction.
Step 3: Convert tacit knowledge to explicit specs, one workstream at a time
While Step 1 is producing the foundational documents and Step 2 is bringing a second pair of hands into the codebase, the third step is to start converting the inflow of new work from “developer-led” to “spec-led”. Every new feature gets a one-page spec before it is built. The spec is written collaboratively. It explains the business problem, the proposed solution, the trade-offs considered, the alternatives rejected, and the acceptance criteria. The point is not bureaucracy. The point is that the reasoning behind every new addition to the codebase enters the company’s memory at the moment it is built, instead of having to be excavated later.
This works best when the founder writes the first draft of the spec and the developer marks it up. The friction of that exchange is exactly the friction you want. It forces the founder to ask why and the developer to write the answer down. After three or four cycles, both of you will be faster at this than you were on day one.
Step 4: Run the “vacation week” test
The single most powerful diagnostic for whether the previous three steps have worked is to put your developer on vacation for one full working week, with no laptop and no Slack. Not as a punitive test, as an actual paid holiday they have earned. While they are out, your second pair of hands (from Step 2) is your front line for any production issue. Your customer support team has the documented runbook from Step 1. Your spec backlog from Step 3 is sitting there for the second person to pick from.
If a normal week passes without an incident your team cannot handle, your bus factor has moved. If the week falls apart, you have learned exactly which of the three sub-problems (knowledge concentration, continuity, ownership) is still alive. The honest version of the vacation test is also a wellbeing decision for your developer, who has probably been carrying invisible on-call duty for a long time. The hidden cost of a bus factor of 1, often forgotten, is the cost paid by the developer who has no way to ever genuinely disconnect.
What good looks like
A reasonable bus factor for an early-stage startup is two or three. Not ten. The cost of pushing it higher than three before the company is large enough to justify it is wasted on duplicated context that nobody is reading. Most companies under thirty people are well-served by a bus factor of two, with the second person being either a partner team, a fractional senior engineer, or a co-founder who has chosen to keep their hands close enough to the code to be useful in an emergency.
A bus factor of one is not always wrong. It can be a deliberate, time-limited choice. The founder of a five-person company with one developer and runway for nine months may genuinely be making the right call. The mistake is treating that condition as permanent. The right framing is that the bus factor of one is a state with a known expiry date, and every quarter you should ask whether it should still be one.
The deeper point is that the bus factor is not really a number. It is a question about who else inside the company has the keys to the system, in their head and on paper. Once you have built the documents, brought in a second pair of hands, and put your developer on vacation without the world ending, you have stopped being a single point of failure in your own company. That is what the question is actually asking.
FAQ
What is a bus factor of 1? A bus factor of one means a single person on the project holds the knowledge required to keep it running. If that person stops contributing for any reason (illness, vacation, new job, family emergency), the work cannot continue without significant disruption. For most early-stage startups with a sole developer, the bus factor is one, even when the team is several people.
How do you calculate the bus factor? The honest calculation is not a formula. It is a thought experiment. Pick the one critical piece of your live software (the payment flow, the auth system, the data model that everything else depends on) and ask: how many people on the team could open the code tomorrow morning and ship a routine fix to that piece without breaking the rest? The answer is the bus factor of that part of the system. The bus factor of the whole project is the smallest of those answers across the critical paths. Various research groups have proposed automated metrics based on commit history, but for a founder, the thought experiment is more useful than the formula.
What is the bus factor in practice? In practice the bus factor shows up not as a catastrophe but as a series of small frictions: a developer on holiday and a fix you cannot ship; a feature that nobody but the author can explain; a roadmap implicitly co-authored by the only person who can evaluate the technical answer. These daily frictions are the lived experience of a low bus factor, long before anyone actually gets hit by a bus.
What is an example of a bus factor? A real example: a 14-person legaltech with one senior developer and one part-time contractor. The senior developer wrote the original codebase, owns the deployment pipeline, holds the production keys, and is the only person who has ever touched the payment integration. The contractor has shipped four bug fixes, all inside areas the contractor already understood. The company has full code in GitHub, secrets in 1Password, and infrastructure on AWS. The bus factor is one. The CEO is not entirely wrong to feel exposed, and what would actually help is the four-step plan above, not a second peer hire.
How do you increase the bus factor? By externalising knowledge before adding headcount. Documents first, second pair of hands second, spec-led inflow third, and a real vacation week as the test. Adding people without first externalising the knowledge they would need to absorb does not raise the bus factor; it just spreads the dependency across more salaries. The cheapest way to go from one to two is almost always to start with a writing exercise, not a hire. The same logic shows up in the long-term cost of maintaining custom software: the line items that look like they should scale with headcount usually scale with documented knowledge instead.
Once a non-technical founder has done that work, the original anxiety changes shape. The question stops being “what if my developer quits” and becomes “which part of the system is the next single point of failure to take down”. That is a far better question to be asking.