It's a grim name for a simple, important idea: how many people would have to be hit by a bus before your project is in serious trouble? For a lot of startups the honest answer is one — a single developer who understands the code that runs the whole business. If that's you, you're not doing anything unusual. But it's a risk worth understanding, because it's cheap to see coming and expensive to discover the hard way.
You don't need to be technical to grasp bus factor or to check your own. This is a plain-language explanation of what it means, why it quietly threatens startups in particular, how it happens almost by accident, and what you can do about it.
Bus factor (also called truck factor or lottery factor) is the number of people who would have to suddenly leave a project before the work stalls, because the knowledge to continue it would leave with them. A bus factor of one means a single person holds all the critical knowledge for something important — so one resignation, illness, or dispute can halt it. Higher is safer.
What is bus factor?
Bus factor is a measure of key-person risk in a project — the smallest number of people who could disappear before the project grinds to a halt. The name comes from a morbid thought experiment developers use: "how many of us would have to get hit by a bus before this falls apart?" A bus factor of three means the knowledge is spread across at least three people; a bus factor of one means everything important is understood by a single person. Nobody is actually worried about buses — it's a memorable stand-in for anyone leaving, going on long leave, burning out, or falling out with the company.
Why does bus factor matter for a startup?
Because a low bus factor turns a routine event — one person leaving — into a business emergency. If the only developer who understands your payment system quits, you can't easily fix bugs, ship changes, or even explain to a new hire how it works; you may be paying someone to reverse-engineer your own product. It also shows up where it hurts most: investors doing technical due diligence treat single-person dependency as a serious risk that can lower your valuation or sink a deal, and day to day it slows everyone down, because all questions funnel through one overloaded person. Knowledge concentrated in one head is one of the most common and most under-priced risks a young company carries.
Why do so many startups have a bus factor of one?
Because it happens by accident, through doing everything else right. Early on, speed is survival, and one talented developer moving fast is often the most efficient way to build — so they build everything, and the knowledge naturally pools in one place. The same pattern appears when you outsource to a single contractor, or when one "hero" developer is always the one who dives in and fixes things. None of these are mistakes in the moment. Bus factor is simply the debt they quietly accumulate: the faster one person builds alone, the more of your business lives only in their head.
How do you find out your bus factor without being technical?
You don't need to read code — you need to read the git history, the automatic log every software project keeps of who changed what and when. It shows, plainly, how concentrated the work is: whether one person wrote nearly all of a critical area, or whether several people have touched and therefore understand it. You can also just ask, area by area: "if this person were unavailable for a month, who else could keep the checkout code moving?" A confident second name is reassuring; a long pause is your bus factor answering for you. This is exactly the kind of signal a tool like PulseRepo surfaces from the history, so you don't have to take anyone's word for it.
How do you improve a bus factor of one?
You raise it by spreading knowledge, not by removing people. A few practical, non-technical things to ask your team to do: have a second developer review each change before it ships (code review, which spreads understanding as a side effect); make sure new features arrive with automated tests, so the next person can change things safely; write down how the critical parts work; and deliberately rotate who works on each area so no single person is the only expert. None of this requires slowing to a crawl — it's the difference between a team where knowledge compounds and one where it's trapped.
Is a high bus factor always the goal?
Not exactly — the goal isn't for everyone to know everything, which is impossible past a certain size. The goal is that no single critical area depends on a single person. A bus factor of one on a throwaway internal script doesn't matter; a bus factor of one on the code that processes your customers' payments matters enormously. Focus your attention where the risk is real: the parts of your product the business genuinely can't run without.
What should I do next?
If you're evaluating an outsourced team or your own, bus factor is one of several signals worth watching together — there's a broader, non-technical guide in how to tell if your dev team is doing good work. And to see your actual exposure rather than guess at it, get an independent read of the git history.
That's what PulseRepo does: it reads your project's history and turns it into a short list of plain-language questions worth raising — including where knowledge is concentrated in one person, which is bus factor in practice. Not scores, not a verdict on anyone, not surveillance — just the risks a technical partner would point out for you. You can see a sample report to get a feel for it.