The asset nobody lists in the vault
When a solo founder sits down to plan for the worst, the mental inventory is predictable: the domain, the Stripe balance, the source code, the password manager, the App Store account. These are the things you own, and ownership is easy to reason about — it transfers, it has value, it can be handed to someone.
But sitting quietly inside those systems is a different kind of thing entirely. Email addresses. Names. Billing details. Support conversations where a customer told you something personal to get help. IP logs. Maybe health notes, or financial figures, or a child's date of birth, depending on what you built.
You don't own that data. You were entrusted with it. And that distinction is the one your estate plan almost certainly misses.
Custody is a duty, not a possession
Data-protection law draws a line most founders never think about because, day to day, it doesn't matter. Under frameworks like the GDPR — and echoed in principle across US state privacy laws and regimes worldwide — the person or organization that decides how and why personal data gets used is the controller. The controller carries the obligations: keep it secure, use it only for what it was collected for, delete it when it's no longer needed, and, if it leaks, tell the people affected and often a regulator, usually within a tight window.
For a solo founder, the controller is often just… you. Not an abstract company with a compliance department. You, personally, or a single-member entity that has no functioning brain the moment yours stops.
Here is the part that catches people out: the obligation does not evaporate when the controller does. The data is still sensitive. The people it describes are still alive, still exposed, still entitled to have it handled properly. What disappears isn't the duty. It's the capacity to fulfill it. You have created an obligation with no one home to meet it.
Orphaned data is the dangerous kind
Left alone, a live product doesn't gently power down. The servers keep running as long as the card on file keeps clearing. The database keeps accepting signups. The webhook keeps firing. For weeks or months, your service behaves exactly as if you were still there — which means it keeps collecting personal data long after anyone is watching over it.
Security researchers have a plain phrase for systems like this: unmaintained. Nobody is applying patches. Nobody notices the login anomaly, the spike in failed auth, the dependency that just got a critical advisory. A password manager left running is a lockout; a product left running is something worse — a store of other people's data, warm and unattended, at exactly the moment its guardian has gone dark.
Breaches don't wait for a convenient owner. If one happens during that unmanaged window, the notification duty still technically exists, the affected customers are still owed a warning, and there is no one with the access, the knowledge, or the authority to send it. The failure isn't dramatic. It's silence.
Why founders don't see it coming
Part of this is a genuine blind spot in how we frame our own work. Behavioral researchers describe a well-documented tendency to weigh outcomes that affect us more heavily than outcomes that affect others — our attention is drawn to our own losses, our own accounts, our own money. A vault built around "what happens to my stuff" is a vault built around self-interest, and self-interest quietly filters customer data out of the picture, because the risk it carries lands on strangers, not on you.
There's a second bias stacked on top. The curse of knowledge — the difficulty of imagining a mind that doesn't know what you know — means you can't easily picture the person who inherits this mess. You know the data exists, where it lives, what's sensitive and what's harmless. To you it's obvious. To your grieving partner staring at a dashboard they've never seen, it is an undifferentiated wall of strangers' names, with no signal about which fields are radioactive and which are routine.
So the data slips through the plan. Not because founders are careless, but because the mind is built to under-weigh a liability that is invisible, other-directed, and abstract.
Who is actually on the hook
This is where the honest answer gets uncomfortable: it's unsettled, and "unsettled" is its own hazard. When a controller dies, responsibility doesn't cleanly pass to a named successor the way a bank account passes to a beneficiary. In practice it lands, murkily, wherever the business itself lands — with the surviving entity if there is one, with the estate and its representatives if there isn't, with whoever ends up holding the keys.
That person may not know they've inherited a legal duty. They may not know the data exists. They almost certainly don't know that shutting things down badly — dumping a database to a personal laptop to "deal with later," emailing a full customer export to a lawyer over plain mail — can create a fresh breach on top of the one they were trying to prevent. Good intentions with no map are how sensitive data leaks during a wind-down.
The law's expectation and the family's reality drift completely apart. Someone is responsible; no one is equipped.
Planning for the data, not just the accounts
The fix isn't legal wizardry. It's making the invisible thing visible before you're not around to point at it.
Start by naming the data honestly. Somewhere in your handoff instructions, write down what personal information your product actually holds, where it lives, and — crucially — which parts are sensitive. "The users table has emails and names; the intake table has health information; support tickets may contain anything." That single paragraph converts a strangers'-data wall into something a non-technical person can reason about.
Then write the disposition plan. Say what should happen to that data if you're gone: is the product wound down and customers notified? Is it exported securely to a buyer? Is it deleted after a grace period? Give the instruction and the safe method — the encrypted export path, not the improvised one. You are writing the retention-and-deletion policy your absence would otherwise leave blank.
Finally, name a human and give them the authority and the access to act — the same person who can pause the billing, freeze new signups, and, if the worst happens on their watch, actually reach the people affected. Access without instructions is a lockout. Instructions without access are a wish. Custody of other people's data needs both, handed over deliberately.
The last obligation you can still meet
You can't delegate having cared. But you can delegate the ability to keep caring after you're gone — and for the data of people who trusted you, that is the difference between a dignified wind-down and a slow, unwitnessed leak.
Heirloom is built for exactly this handoff: a single place to hold the vault, the beneficiaries, and the plain-language instructions that tell one trusted person what your systems hold, what's sensitive, and what to do about it — so the duty you took on doesn't die unguarded with you. If you're a solo founder carrying other people's data, that's the part of the plan worth writing first. You can start mapping it at https://heirloom.lumenlabs.works.