The account that keeps charging
Somewhere right now, a small tool is charging a credit card $19 on the first of the month for a founder who died in March. The product still loads. The login still works. The Stripe webhook still fires on schedule, indifferent to the fact that the one person who built and ran the whole thing is gone. For a while — weeks, sometimes months — nothing looks wrong from the outside.
Then something small breaks. A TLS certificate lapses and the browser throws a warning. A server invoice bounces because the card on file expired. A customer emails support with a question and gets silence, then another silence, then the slow realization that there is no one behind the curtain anymore. The money kept moving the entire time. The trust did not.
Most death planning for solo founders points inward: the will, the password vault, the executor, the assets to be divided. All of it matters. But it quietly skips a second set of people who depend on you — not your family, your customers. They have your data. They built workflows on top of you. They handed you a card number on the understanding that someone would be there. When you plan only for your heirs, you leave your customers to discover your death through a billing statement.
The bus factor nobody applies to themselves
Engineers have a blunt phrase 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. A healthy team has a bus factor of three or four — knowledge is spread, nothing lives in exactly one head. A solo founder is the purest possible case. Bus factor: one.
What's strange is how readily founders apply this idea to other people's code and how rarely they apply it to their own lives. We'll audit a contractor's commits and worry aloud that only one person understands the payments module. Then we'll personally hold the deploy keys, the domain registrar login, the customer database, the support inbox, and the mental model of how all of it fits together — and call it being lean. Lean and single-point-of-failure are the same architecture wearing different clothes.
The consequence isn't only that the business stops. It's that the business keeps going just enough to do harm: billing without service, collecting without delivering, holding personal data with no one accountable for it.
Why you can't picture it
There's a well-documented reason this is so easy to ignore, and it isn't laziness. The psychologist George Loewenstein described what he called the hot–cold empathy gap: when we're in a calm, unemotional "cold" state, we systematically underestimate how a "hot" state — panic, grief, urgency — will actually feel and how it will distort decisions. The gap runs between people, too. Sitting at your desk on an ordinary Tuesday, well-caffeinated and very much alive, you simply cannot generate a vivid model of a stranger trying to refund three hundred confused customers while also planning your funeral.
Related to this is projection bias — the tendency to assume the future, and other people, will look a lot like our present selves. You implicitly imagine that whoever steps in will know what you know, care the way you care, and find things where you'd look for them. None of that is true. The person opening your laptop will have your responsibilities and none of your context. The plan that feels redundant to you is, to them, the only light in the room.
So the task gets coded as abstract and low-urgency, and abstract low-urgency tasks lose every time to the concrete work in front of you. The folder never gets made. Not because you don't care about your customers, but because the part of your brain that would feel the stakes is the part that can't switch on while everything is fine.
Three honest endings
A customer continuity plan does one useful thing: it forces you to choose, in advance, how each product you run actually ends. There are really only three honest endings, and pretending you haven't picked one is itself a choice — the worst one.
It keeps running. Someone you've named maintains the service. This requires the most preparation: documented infrastructure, a successor who can actually operate it, and a realistic answer to who gets paid to care once you're not the one losing sleep over uptime.
It transfers. The product is an asset, and the right ending is a sale or handoff to a buyer who wants it. This means someone needs to know it's sellable, what it's roughly worth, who the likely acquirers are, and where the numbers live. A profitable micro-SaaS with no documentation is worth a fraction of the same business with a clean operating record.
It sunsets. No one continues it, and the right thing is an orderly shutdown. This is the most common ending for a one-person company, and the one founders are most reluctant to plan, because writing it down means admitting the thing you built might not outlive you. It will outlive you a little either way. The only question is whether it does so gracefully or as a slowly failing machine that keeps taking money.
What a graceful sunset actually requires
If the honest ending is a sunset — and for most solo products it is — the order of operations matters more than people expect.
Stop the billing first. Before anyone exports data, before any farewell email, the very first action is to stop charging cards: cancel the recurring subscriptions, turn off auto-renewal, halt the invoices. Every other step can take days without hurting anyone. Continued billing hurts someone immediately, and it's the detail most likely to get missed because it's the one part of the business designed to run without you.
Then the rest. Customers need their data out in a portable form, and they need to be told how and by when. They need a clear date the lights go off, not an ambiguous fade. They need a posture on refunds — even a simple, pre-decided rule like "prorate the unused month" spares your stand-in from agonizing over a hundred individual judgment calls in the worst week of their year. And someone needs the actual keys: the registrar, the host, the payment processor, the support inbox, in a place they can reach without you.
Nnone of this is technically hard. It's just invisible from the inside, because you've never had to do it to yourself.
Write the email now
Here is the single artifact worth more than all the others: the message your customers receive. Write it while you're alive.
Not a template someone fills in under duress — the actual words. The ones that say what happened, plainly and without melodrama; that thank people for trusting a small thing built by one person; that tell them exactly how to get their data and what will happen to their card. Whoever sends it will be grieving or overwhelmed or both, operating squarely in the hot state you can't currently imagine. The kindest thing you can leave them is a door they only have to open, not build.
A customer who gets that email remembers you as someone who closed the loop. A customer who gets a third silent month and a declined-payment notice remembers something else entirely. Same death, same business, opposite legacy — and the only variable is whether you wrote a page while it still felt unnecessary.
Where this lives
This is the part of continuity planning that has nowhere natural to live. It isn't a legal document, so it doesn't belong in your will. It isn't a password, so a vault alone won't carry it. It's instructions, decisions, and a few drafted messages that have to reach a specific person at a specific moment — which is exactly what Heirloom is built to hold. It keeps the keys, the named people, and the handoff in one place, so the plan for your customers sits right beside the plan for everything else, ready for the day someone needs it instead of you.
You don't have to finish the whole thing tonight. You just have to stop your business from outliving you in the one way that helps no one. Start the page your customers will never see you write: heirloom.lumenlabs.works.