The most valuable asset in your company isn't written down anywhere
Think about the last time you fixed something in your business by feel. The staging server hangs, and your hands already know it's the cron job that needs restarting before the cache will clear. A customer emails about a refund, and you remember — without checking — that this particular one signed up under a legacy plan and has to be handled manually. The domain renews through a registrar you set up four years ago, paid for with a card that has since expired, under an email alias you forward to your phone.
None of that is in a document. It lives in the place all of it lives: your head. And for a solo founder, that head is the single point of failure for the entire operation.
We tend to plan for the dramatic version of disappearance — death, a will, who inherits the equity. But the quieter, more common failure is simpler. You're in the hospital for a week. You're unreachable on a flight when the payment processor freezes the account. You burn out and step away, and someone has to keep the lights on. In every one of these, the problem isn't ownership. It's that the operating manual was never anywhere but your memory.
Why the knowledge is invisible to you
The philosopher Michael Polanyi gave this a name. In The Tacit Dimension, he argued that "we can know more than we can tell." A great deal of what we know how to do is tacit knowledge — skill and context we use fluently but could not easily explain on demand. You know how to ride a bike, but you can't write the instructions that would let someone else do it. You know how to run your business, but you've never had to describe it to a stranger, so the description doesn't exist.
Software teams have a blunt phrase for the risk this creates: the bus factor. It's the number of people who would have to be hit by a bus before a project becomes unrecoverable because the knowledge to continue it is gone. For most companies the bus factor is two or three. For a solo founder, it is exactly one. You are the entire institutional memory, the only person who knows which vendor to call, where the backups are, and why that one customer must never be auto-billed.
The cruel part is that tacit knowledge is hardest to see precisely because you use it constantly. It feels like nothing. The steps you'd have to write down seem too obvious to bother with — until they're the steps no one else can guess.
The reason you keep not doing it
If this is so important, why does almost no solo founder have it written down? Part of the answer is behavioral. Researchers in behavioral finance describe the ostrich effect — the documented tendency to avoid information that's expected to cause discomfort. People check their investment portfolios far less often when markets are falling. The information is useful, and we look away anyway, because looking feels bad.
Planning for your own absence is the ostrich effect at full strength. To document what happens when you're gone, you have to sit for an hour and imagine being gone. Terror management theory — a well-supported line of research in social psychology — describes how much effort we spend keeping reminders of our own mortality at a comfortable distance. A "what happens if I disappear" document is a reminder you have to stare at directly. So it slides to next quarter, every quarter.
The trick is not to summon more willpower. It's to make the task small, concrete, and unromantic — less "confront your mortality," more "write down the Wi-Fi password."
How to get it out of your head
The goal of a business continuity plan for solo founders isn't a polished corporate document. It's a single, findable place that lets a competent, trusted person keep your business breathing — or wind it down with dignity — without you in the room. Here is how to externalize the tacit layer.
Follow the money, in and out. Start with the flows that stop the business if they break. What account does revenue land in? What subscriptions and vendors auto-charge, on which card, and what happens when that card expires? Which of these would silently fail — a lapsed domain, a dead API key, an unpaid hosting bill — and take the product down with no warning? Money flows are the easiest tacit knowledge to surface because they have due dates.
Write the access map, not the passwords in plaintext. Someone needs to know that accounts exist before they can ever get into them. List the critical systems — registrar, host, payment processor, email, code repository, bank — and where the credentials are kept. A password manager with a designated emergency contact does the heavy lifting here; your job is to make sure someone knows the manager exists and how to trigger access.
Document the three things only you would think to do. This is the real tacit core. For each critical system, write the one non-obvious fact a smart stranger would never guess: "Restart this service before clearing the cache or it corrupts." "This customer is billed manually — never enable auto-pay." "The backups are real, but the restore script needs this flag or it silently does nothing." These sentences are worth more than any org chart.
Name the humans. Who is the accountant, the lawyer, the key contractor, the one customer who is 30% of revenue? A person who can call your accountant by name on day one is months ahead of a person starting from your inbox.
Say what you'd want to happen. Keep selling? Hand it to a co-founder you've talked to? Refund everyone and shut it down cleanly? Without your intent on the page, even a willing helper is paralyzed, afraid of doing the wrong thing in your name.
Make it a living thing, not a monument
The most common failure of a continuity plan is that it's written once, in a burst of resolve, and then rots. The card on file changes. The vendor gets swapped. The plan quietly becomes fiction, which is worse than nothing because it's trusted.
Borrow a tool from psychology to keep it alive: an implementation intention, the if-then planning shown by Peter Gollwitzer's research to dramatically improve follow-through. Don't resolve to "keep the plan updated." Instead: "When I change a vendor or a payment method, I update the continuity doc before I close the tab." Tie the update to a trigger that already happens, and it stops depending on memory or mood. Reviewing the whole thing once a year — birthday, fiscal close, any fixed date — catches the rest.
A continuity plan is, in the end, an act of respect: for the people who'd have to clean up, and for the years of work you'd be asking a stranger to understand in an afternoon. You're translating the invisible operating system in your head into something another human can run.
Where Heirloom fits
This is the exact problem Heirloom was built for. It's a death-binder for solo founders — a single vault for your access map, your vendors and money flows, your beneficiaries, and the plain-language handoff that says what you'd want done, all in one place instead of scattered across a password manager, a notes app, and your own recall. It's designed so the tacit knowledge has somewhere to live, and so the right person can reach it at exactly the moment you can't walk them through it.
If the honest answer to "what happens to the business if I vanish for a week" is no one would know where to start, that's worth an afternoon. You can see how Heirloom organizes the whole handoff at heirloom.lumenlabs.works — and start getting what's in your head somewhere safe.