The engineers already have a word for it
Somewhere in the early days of extreme programming, developers started asking a grim little question about their teams: how many people would have to get hit by a bus before this project fell apart? The number that answered it became known as the bus factor — sometimes the truck factor, or, for the superstitious, the lottery factor. A team with a bus factor of five is resilient; you could lose any one person and keep shipping. A team with a bus factor of one is holding its breath.
The phrase is dark on purpose. It was never really about buses. It was a way to name something that engineers could feel but couldn't easily measure: how much of a system lives inside a single human head, undocumented, unshared, invisible until the day that head stops showing up. Researchers have since built tools that estimate the truck factor of open-source projects by reading their commit histories — mapping which files only one contributor has ever touched. The findings are consistently uncomfortable. A surprising number of projects the whole world depends on turn out to rest on one or two people.
You already know where this is going. If you run a business alone, your bus factor is one. Not metaphorically. Exactly one.
Why a bus factor of one hides in plain sight
The reason this risk stays invisible is that a bus factor of one works beautifully right up until it doesn't. When you're the only person who touches everything, there's no coordination overhead, no miscommunication, no waiting on anyone. Being the single point of failure feels identical to being efficient. The whole thing hums.
So the concentration of knowledge never announces itself as a problem. It compounds quietly. You learn which server the cron job actually runs on. You remember that the payment webhook needs a manual retry when a certain provider hiccups. You know that the contractor in the other timezone has to be paid on the 3rd, not the 1st, or they get anxious. None of this is written down, because writing it down would be writing a note to yourself, and you don't need the note. You are the note.
Every one of those small, unrecorded knowings is a file only one contributor has ever touched. Individually they're trivial. Collectively they're the business.
What actually breaks first is not the code
Here's the thing the software framing gets slightly wrong when you carry it over to a whole company. If you disappeared tomorrow, the code would mostly be fine. It would keep running on the servers you already paid for. The website would stay up. Customers would keep getting charged.
What breaks first is access and authority, not technology. Someone would need to get into the email account that receives every password reset. They'd need to know the business exists in the first place, then which bank holds its money, then who's owed what, then whether that alarming automated email from a vendor is routine or a five-alarm fire. They'd need the standing to make decisions — to cancel, to refund, to tell customers what's happening — and in most solo operations, no one but you has ever had it.
This is why "my spouse knows my passwords" is a comforting sentence that solves almost nothing. Passwords are the code layer. The bus factor problem lives one level up, in the knowledge of what to do and in what order — the operational sense that you've been quietly accumulating for years and have never once had reason to externalize. A password gets someone through a door. It doesn't tell them which of forty rooms matters, or which one is on fire.
Raising the number without hiring anyone
The good news buried in the bus factor concept is that it was invented by people who couldn't just hire their way to safety either. Open-source maintainers can't force volunteers to appear. So the strategies that emerged aren't about adding people — they're about distributing what's in the person you already have. A solo founder can do the same thing, and it takes an afternoon, not a co-founder.
Write down the map, not the territory. You don't need to document every keystroke. You need the index: here is everything the business is made of, here is where each piece lives, here is who or what depends on it. The goal is that a competent stranger — a sibling, an attorney, a hired operator — could stand in your shoes and at least know what the shoes are. Think of it as raising your bus factor from one to "one plus a really good map."
Separate the vault from the instructions. Access credentials and the explanation of how to use them are two different things, and they fail differently. Someone can inherit your logins and still be paralyzed; someone can have brilliant instructions and no way in. A resilient handoff keeps both — the keys and the note about which lock each one opens — and keeps them somewhere a trusted person can actually reach when the moment comes.
Name the authority, not just the assets. Decide, in advance, who is allowed to make the calls. A bus factor of one isn't only a knowledge problem; it's a legitimacy problem. The person who steps in needs to be pre-designated clearly enough that a bank, a customer, or a co-vendor will take them seriously. Otherwise they inherit all your responsibilities and none of your standing.
Rehearse the retrieval. The cruel irony of most contingency plans is that they're never tested until the one moment testing is impossible. If a document exists but no one knows it exists or how to find it, your bus factor is still one. Tell at least one person where the map lives. That single conversation does more for your resilience than another layer of encryption.
The uncomfortable part is not really about the bus
Engineers picked a violent metaphor because the boring version doesn't motivate anyone. But you don't need to get hit by anything for a bus factor of one to hurt. A hospital stay does it. A family emergency that eats a month does it. Burnout that pulls you offline for a season does it. The bus is just the extreme case of a much more ordinary event: you, temporarily or permanently unavailable, in a system that assumed you never would be.
There's a well-documented cognitive tilt behind why we don't plan for this — call it optimism bias, the same mental discount that makes us underinsure and overcommit. We don't model our own absence, because from the inside, our presence feels like a constant. Naming a bus factor is useful precisely because it sidesteps the mortality conversation entirely. You're not planning to die. You're just doing what every serious engineering team does: refusing to let the whole thing depend on one person staying reachable forever.
You raise the number. That's the entire discipline.
Where this becomes a thing you can actually hold
Heirloom exists because raising your bus factor shouldn't require a legal degree or a weekend of dread. It's the death-binder built for solo founders — a single place to hold the vault, the map, and the handoff instructions, with beneficiaries and a designated person who can actually step in. It keeps the keys and the note about which lock each one opens in the same trusted spot, and it makes sure someone knows the spot exists. In bus-factor terms, it's the smallest honest move from one to more than one.
If reading this made you picture the forty rooms only you know about, that's the signal. You can start the map today, in an afternoon, at heirloom.lumenlabs.works — and go back to being the reason it all works, minus the reason it could all stop.