The plan most founders make assumes time they won't have
Most advice about dying with a business still running treats it as a paperwork problem. Write the will. Name the executor. List the passwords. The quiet assumption underneath all of it is that someone will sit down, calmly, weeks or months later, and work through your affairs the way they'd settle a house or a savings account.
A solo software business does not wait calmly. It runs on autopilot, and autopilot has a fuel gauge. The moment you stop topping it up, a countdown begins — one that started the day you bought the domain and has been quietly resetting itself every year since, without you ever watching it. When you die, the resets stop. What follows is not a slow administrative wind-down. It's a decay window, and most of the damage happens inside the first ninety days, long before any executor has found the right login.
This is the part estate planning skips, because estate planning was built for assets that sit still. Yours don't.
Why digital assets are perishable in a way money isn't
A bank balance is patient. Left untouched, it stays a balance. Property left alone stays property. These are the assets the legal system was designed around, and the system moves at their pace — probate measured in months, sometimes longer, with no penalty for the waiting.
Digital infrastructure is the opposite. It is perishable, and it perishes on contracts you signed and forgot. Your domain is rented, not owned, on an annual lease. Your SaaS tools — the database host, the email sender, the payment processor, the error monitor — are all month-to-month tenancies that survive only as long as a card keeps clearing. Your customer data lives inside those tenancies and inherits their mortality.
The engine that keeps all of it alive is a single recurring charge against a single card. And that card is often the first thing to die after you do.
The first domino: the account freeze
When a bank is notified of an account holder's death, it typically freezes the account. This is normal, prudent, and exactly what you'd want a bank to do — it protects the estate from fraud. But for a solo founder it also severs the artery. The card that auto-renews your domain, pays your server bill, and settles your subscriptions stops clearing.
Nothing announces this. There is no alarm, no call to your next of kin. The first sign is a failed payment email landing in an inbox no one is checking, because the person who checked it is gone. From that moment, every piece of your stack is running on a grace period it never told you it had.
What actually expires, and roughly when
The timelines vary by provider, but the shape is consistent, and it's worth seeing plainly.
Subscriptions fail quietly. When a card declines, most services don't shut you off at midnight. They retry, send dunning emails, and degrade in stages — read-only mode, then suspension, then termination. Each service runs its own clock, so your stack doesn't fall over all at once. It frays, one tool at a time, over weeks.
Domains follow a stricter ritual. A domain that isn't renewed enters an expired state, then a grace period during which it can still be reclaimed, then a redemption period that usually carries a steep recovery fee, and finally release back to the public. This staged process — the Redemption Grace Period is a real, ICANN-defined step — is generous by design. But it assumes someone is watching the calendar and willing to pay. If your domain lapses, your site goes dark, your email addresses stop resolving, and every password-reset link tied to that domain quietly stops working. Lose the domain entirely and someone else can register it.
Data deletes on a retention schedule. This is the part that's truly irreversible. Many providers delete suspended or terminated account data after a defined retention window. A bank account frozen for a year unfreezes intact. A database whose host terminated the account for non-payment does not come back. The freeze is reversible; the deletion is not.
Money waits. Data has a half-life.
Why your password list doesn't beat the clock
The standard fix — a sealed list of logins handed to someone trusted — solves the wrong problem. It assumes the bottleneck is access. The real bottleneck is time-to-action: the gap between your death and the first competent intervention in your systems.
Think about what that gap actually contains. Someone has to learn you've died. Then realize you ran a business that needs tending — not obvious from the outside, since solo founders look like quiet people with laptops. Then find your credentials. Then understand the stack well enough to know that the database host is load-bearing and the newsletter tool is not. Then have the authority and the funds to pay the bills keeping it alive.
Every one of those steps takes days. The decay window doesn't grant them. A perfect password list discovered in week six is a key to a house that already burned down — the domain in redemption, the database past its retention cutoff, the customers long gone.
Build a dead man's switch, not a binder
The concept worth borrowing here comes from engineering, not estate law: the dead man's switch — a control that triggers when the operator stops responding, precisely because the operator can't act anymore. A binder is passive; it waits to be found. A switch is active; it assumes no one is coming and acts anyway.
For a solo founder, building one is less technical than it sounds. It comes down to three honest answers.
Decouple survival from your personal card. The single point of failure is the payment method everything renews against. A business card the business pays, a longer prepaid runway on the domain, or simply a backup payment method on the few truly load-bearing services buys weeks the estate would otherwise never get. You are not trying to fund the business forever. You are buying time for a human to arrive.
Name the load-bearing few. Your stack is not flat. Three or four services hold the data and the domain; the rest are conveniences. Write down which is which, in plain language, ranked by how fast their failure becomes permanent. "If this one lapses, customer data is deleted in 30 days" is the sentence your successor needs first — not an alphabetized list of forty tools.
Pick the trigger and the person. Decide who gets told, how they'll learn in time, and what the first three moves are. The handoff has to reach them while the window is still open, which means someone in your actual life — not a lawyer who learns six weeks later — has to know the switch exists and where it points.
The real deadline isn't legal — it's mechanical
Probate runs on the calendar of the courts. Your infrastructure runs on the calendar of your billing cycles, and the two are not even close to synchronized. By the time the legal process catches up, the perishable parts have already spoiled. That mismatch — slow law against fast decay — is the trap, and it's why a will that perfectly assigns ownership of a business can still hand someone the ashes of one.
The useful reframe is this: you're not planning for your death. You're planning for the ninety days after it, when the autopilot is still flying and no one's in the seat. Win those ninety days and almost everything is recoverable. Lose them and no amount of legal authority gets the data back.
This is the gap Heirloom is built to close. It holds your vault, your beneficiaries, and your handoff in one place — but more to the point, it's designed around the clock, so the people you trust learn what's load-bearing and what to do while there's still time to do it, not after the window has shut. If you've been meaning to write the binder, consider building the switch instead. You can see how it works at https://heirloom.lumenlabs.works — and the most valuable hour you spend on it is the one that maps which of your systems dies first.