Risk
Aug 07, 2026
The 'Bus Factor' Myth: Why Relying on One Person Isn't the Risk You Think It Is
The bus question assumes that risk lives in headcount. Risk lives in whether anyone can pick up your project and continue it, and headcount has surprisingly little to do with that.
Somewhere in the second call, usually from the most sensible person in the room, the question arrives: what happens if you get hit by a bus? It is a fair question, asked in good faith, and it deserves a better answer than reassurance. The trouble is that the question quietly assumes agencies solve the problem it describes, and they mostly do not. What follows is the honest version, including the parts that argue against me.
Agencies have a bus factor too, it just has a nicer name
The person who understood your project at an agency leaves, and the word used is turnover rather than tragedy. Your project manager changes twice in six months. The designer who made the original decisions rolls onto a bigger account. The junior developer who wrote your custom module resigns in March, and the knowledge in their head leaves with them, exactly as it would in the bus scenario. The difference is that nobody schedules a call to tell you about it. Continuity in an agency looks like a stable logo on an invoice, while underneath, the people who know your project are quietly rotating.
Fragmented ownership is its own risk
More hands means more places where knowledge can be lost, because knowledge lives in people rather than in org charts. When five people touch your project, the reasoning behind any given decision sits with whichever one made it, and finding out why something works a certain way becomes an archaeology exercise. Onboarding a replacement mid-project costs weeks, and it costs them from your timeline. There is also the accountability problem: when everyone owns the outcome, the answer to "why did this ship broken" is a meeting rather than a person.
What actually reduces risk
Documentation you can read without a translator. Written decisions rather than files alone. If the reasoning is on paper, the next person inherits it.
A component system rather than forty bespoke pages. Anything defined once can be understood once, by anyone competent.
Code in a repository you own, from day one, with your name on the account. Ownership of the work is worth more than the number of people who touched it.
Deployment access in your hands. If you cannot put a change live without your supplier, you have a dependency far more dangerous than any bus.
Staged payments tied to delivery, commonly thirty at kickoff, thirty at a working build, forty at launch. Incentives aligned to shipping beat promises about redundancy.
Standard tools over clever ones. A project built on ordinary technology can be continued by thousands of people. A project built on somebody's favorite experiment cannot.
How to evaluate a supplier on this
Ask to see the documentation from a finished project, and read it. Ask who holds the repository and the deployment keys, and get the answer in writing. Ask what happens to your source code if the relationship ends badly, and listen for whether the answer is immediate or improvised. Ask, if you like, for escrow, which is a reasonable request that a serious supplier will not find offensive. None of these questions are about headcount. All of them are about whether the work can survive without the person who did it, which is the actual question behind the bus.
The comparison, honestly
One senior specialist with a decade of experience, clean documentation, and your code in your account represents a specific risk: an interruption while you find a replacement, measured in weeks, with the work intact and continuable. A team of mixed seniority with rotating members represents a different risk: gradual erosion of the reasoning behind your product, invisible until it is expensive, with nobody in particular responsible for it. The first risk is visible, sharp, and manageable with contracts. The second is diffuse, slow, and almost impossible to price.
Where the agency answer is genuinely better
Some projects need capacity that no individual has. A platform requiring backend engineering, mobile applications, and a design system maintained across five teams needs an organization, and the coordination cost buys you something real. Procurement rules sometimes require multiple vendors, and that is a constraint rather than an argument. If your project genuinely needs eight people at once, hire the eight, and use the questions above on whoever supplies them.
What to ask instead of the bus question
The productive version sounds like this: if you disappeared tomorrow, what exactly would I have, and could someone else continue from it? A good answer arrives with specifics, because the person has thought about it before you asked. The bus question is really a question about ownership and evidence, dressed up as a question about numbers. If you want to see how continuity is built into a project from the first week, the documentation and the access arrangements are worth a conversation before anything else gets decided.
Senior design, Webflow development, and end-to-end execution. One partner for your brand, website, and launch, no vendor juggling.
