The question nobody on your team can answer
Imagine your company is a single building, and there is exactly one key. You carry it everywhere. You unlock the door each morning, and somewhere along the way you stopped noticing that you are the only person who has ever held it. Then one ordinary afternoon — a car accident, a sudden illness, a family emergency two time zones away — you can't get to the door. The building is full of work that matters. Customers are knocking. And the key is in your pocket, wherever you are.
For a solo founder, this isn't a thought experiment. It's the literal architecture of the business you've built. The Stripe account, the domain registrar, the deploy pipeline, the one vendor who only ever emails you, the password to the password manager itself — all of it routes through a single person. Engineers have a blunt name for this: the bus factor. It's the number of people who would have to be hit by a bus before a project grinds to a halt. For most solo businesses, the bus factor is one.
This article is about lowering that number to something survivable — without hiring anyone, without a lawyer in the room, and without pretending you'll live forever.
Why your brain refuses to plan for this
If the fix were purely logical, every founder would already have done it. The obstacle isn't ignorance; it's a well-documented quirk of how humans handle threatening information.
Behavioral economists call it the ostrich effect — the tendency to avoid information that we expect to make us anxious, even when that information is exactly what we need. The original research looked at investors who checked their portfolios far less often when markets were falling. The instinct generalizes: when a topic carries dread, we don't reason about it. We look away. A continuity plan forces you to picture your own absence, so the mind quietly files it under later.
Layered on top is present bias, the consistent human preference for rewards now over rewards later. The cost of writing a continuity plan is immediate and concrete — an afternoon you'd rather spend shipping. The benefit is distant, abstract, and ideally never collected. Faced with that math, we discount the future steeply and almost always choose to ship.
Naming these mechanisms matters, because it reframes the problem. You're not undisciplined. You're running standard human firmware. And the way to beat firmware isn't willpower — it's a small, concrete structure that doesn't ask you to feel motivated.
The one document, and what actually goes in it
The structure is a single living document. Call it a continuity runbook, an emergency operations memo, an "if I'm not here" file — the name is less important than the discipline of having exactly one. The goal is narrow and testable: a trusted person, who is not you, could keep the business breathing for thirty days.
Not grow it. Not make strategic calls. Just keep the lights on long enough for an orderly decision. That framing keeps the task finite. You're not writing your memoirs; you're writing operating instructions for a machine you happen to run.
A useful runbook tends to cover four things:
Access, described — not stored in plaintext. Where the keys live, not the keys themselves. "Logins are in 1Password; the master password and recovery follow the handoff process below." The point is that someone knows the map even if the treasure stays locked.
The lifelines. The two or three accounts that, if they lapse, the business dies quietly: the domain registrar, the payment processor, the hosting bill, the business bank account. List what auto-renews, what doesn't, and which credit card backs each one. A surprising number of companies don't die from drama. They die because a domain silently expired.
The humans. Your accountant, your lawyer if you have one, key clients, critical vendors, and the contractor who actually understands the codebase. Names, what they do, and how to reach them. A stranger stepping in needs a phone tree, not a guessing game.
The first 48 hours. Plain instructions for whoever opens this file. Who to notify. What to pause. What absolutely must not be touched. What can wait. This is the section people skip, and it's the one that prevents a panicked helper from making things worse.
Write it for a competent stranger
The most common failure mode is writing the runbook for yourself. You already know that "the deploy thing" means the GitHub Action that pushes to production every time main updates. Your sister, or your most trusted contractor, does not.
There's a relevant idea from the study of expertise sometimes called the curse of knowledge: once you know something deeply, it becomes genuinely hard to imagine not knowing it. Experts consistently overestimate how obvious their knowledge is to others. Your entire business is a monument to your own expert intuition, which means the instructions in your head are full of invisible gaps.
So write for a smart, calm person who has never seen your tools. Spell out the acronyms. Say where things are, not just what they're called. The test is simple and a little uncomfortable: could someone who isn't you actually follow this, today, without calling you? If the answer requires you to be reachable, the document hasn't done its job.
Make it survive contact with reality
A continuity plan written once and forgotten is worse than none, because it inspires false confidence. The credentials rotate, the vendors change, the bank card expires. A year-old runbook can send your stand-in confidently through a locked door.
The fix is to shrink the maintenance until it's nearly free. Tie a review to something you already do — when you renew the domain, when you do taxes, on your company's founding anniversary. Fifteen minutes, twice a year, to confirm the map still matches the territory. This is the same logic behind a fire drill: the value isn't the document, it's the confidence that the document still works when it's needed in the dark.
And store it where it will be found. A brilliant runbook encrypted behind a password only you know recreates the exact problem you set out to solve. There has to be a deliberate, secure path by which the right person — and only the right person — can reach it at the right moment.
What you're really protecting
It's tempting to read all of this as being about money or assets. It isn't, really. What a continuity plan protects is the people downstream of you in a bad moment: the spouse who shouldn't have to reverse-engineer your business while grieving, the loyal client left in silence, the contractor who'd gladly help if anyone had told them how. The work of an afternoon becomes a kind of message to the future — I thought about you. I made this easier.
That's a strange and generous thing to build. And it's the rare founder task where the absolute worst outcome is that you spent a quiet afternoon getting organized and never needed it.
Where Heirloom fits
This is the exact problem Heirloom was built to solve — a single, secure place for solo founders to hold the map: the vault of where everything lives, the named beneficiaries who should reach it, and a deliberate handoff so the right person gets access at the right time and no one else, ever. It turns the runbook in your head into something that survives you, without leaving your credentials lying around in a document anyone could open. If today felt like the nudge to finally lower your bus factor from one, you can start the whole thing in an afternoon at https://heirloom.lumenlabs.works — and then go back to building, knowing the lights stay on either way.