The first message about your death might not come from a person. It could come from a billing system. Something like Your payment method was declined, sent to an inbox nobody is reading. A week later there's another, written more firmly. Then a third, with a word that sounds procedural and is in fact final: suspended. By the time your sister thinks to ask what happened to the app you built, the servers that ran it may already be getting wiped clean. Nobody chose that. It happens because the grief and the billing cycle run on different clocks.

This piece is about one idea that most solo founders have never said out loud: your infrastructure stays alive only as long as your payment method does. It isn't kept alive by your code, your backups, or your good intentions. It's kept alive by a card number. And a card belonging to someone who has died doesn't stay usable for long.

The card is the life-support machine

When a bank learns that an account holder has died, it usually freezes the accounts and cancels the cards. That's the bank doing its job and protecting the estate from fraud. But a cloud provider sees only one fact: the recurring charge failed.

The order varies by provider and changes over time, so read your own provider's current terms. The general pattern holds across the industry, though. A failed payment triggers notices, then restricted access or suspension, and if nobody fixes it, the account is closed. After closure, many providers keep your data for a limited window and then delete it for good. AWS, for example, has documented a post-closure period after which content in the account is removed. In practice your family has a deadline they don't know about, and the only warnings go to your email.

There's a quieter version of the same failure that runs the other way. Say your hosting is billed to a joint card or a business account that someone keeps funding. Then nothing gets suspended. The instances keep running, the managed database keeps charging, the forgotten GPU experiment keeps costing money, and all of it drains an estate that nobody can audit. One outcome is deletion and the other is a slow leak. Either way, nobody is making decisions, because the person who understood the bill is gone.

Why you can't see this risk in your own stack

If this feels obvious, notice that you've probably never acted on it. Psychologists have a precise name for the reason: the curse of knowledge. Once you know something, it's hard to imagine not knowing it. Economists Colin Camerer, George Loewenstein, and Martin Weber described the effect in 1989, and it shows up anywhere experts try to predict what beginners will understand.

You look at your AWS console and see a system. You know the RDS instance is the important one. You know the three EC2 boxes tagged old- can go. You know the S3 bucket with the unhelpful name holds every customer upload since launch. To you, the stack is readable.

To someone who loves you and has never opened a cloud console, it's a wall of regions, ARNs, and line items. And they'll be seeing it for the first time while grieving, under deadline pressure, without your root password, and without the hardware key on your keyring that they don't even know is an MFA device.

The curse of knowledge doesn't just make you underestimate how hard this will be for them. It makes the problem invisible to you. You can't feel a gap you've never stood on the other side of.

The root account problem

Cloud accounts are usually built around a single all-powerful identity. On AWS it's literally called the root user. It's tied to an email address and, if you've followed good security practice, to multi-factor authentication. That's correct design, and it's also why the account is so hard to inherit.

Your executor's legal authority doesn't create a login. A death certificate and letters testamentary can open a conversation with a provider's support team, but that conversation tends to be slow and limited. It isn't built to hand a non-technical relative the keys to a production environment in the window before a suspension turns into a deletion. In the meantime, your customers' data sits in a system your family legally inherits and practically can't touch.

I'm not suggesting you weaken your security. The goal is to plan a deliberate, documented path for someone else to reach the controls, so the account doesn't stay perfectly locked against the people who need it.

Buy time first, then explain

The most useful reframe is that your family doesn't need to understand your infrastructure right away. They need time, and then they need triage.

Time comes from billing. If the account keeps getting paid for a few months after your death, every other problem goes from an emergency to a chore. Someone can find a technical friend, hire a contractor, or contact a buyer, and nothing has been deleted while they did it.

Triage comes from a short, plain-language map. It doesn't need to document your architecture, which would be the curse of knowledge in another form. It needs to sort things into three piles: this keeps the business alive, this holds data that matters, and this can be switched off today. A stranger with no context can act on those three piles.

People skip this kind of planning because they picture a giant runbook. What protects your family is much smaller: a funded account, a second person who gets the warnings, and one page that says what's safe to turn off.

Your next moves

  • Open every cloud billing console you use today and write down the card behind each one. That means AWS, plus any of Vercel, DigitalOcean, Hetzner, Cloudflare, Render, and whatever you signed up for at 2 a.m. and forgot. Note each card's expiry date and whether it's a personal card that would be cancelled at your death or a business account that someone could keep funding.
  • Add a second person as an alternate contact. AWS lets you set separate billing, operations, and security contacts on an account. Put a trusted person's email on billing so the payment declined warnings reach someone alive. Check whether your other providers offer a team member or secondary billing email, and use it.
  • Set a budget alert that goes to that same person. A simple monthly spend alert, like AWS Budgets, does two jobs. It warns someone when charges stop, and it warns them when charges climb with nobody watching.
  • Create a documented emergency-access path instead of sharing your root password. For example, set up a separate least-privilege identity that can view billing and stop or snapshot resources. Store its credentials and MFA recovery steps in a sealed, encrypted location your executor knows how to open. Write down where your physical security keys live and what they are.
  • Write the one-page keep/back-up/kill list, and tag your resources to match. Ten lines in plain English is enough: which service runs the product, which database and bucket hold customer data, what can be shut off immediately. Then export one current database backup to a place your executor can actually reach.

None of these takes more than an afternoon. Together they turn a silent deadline into a visible one.

The part only you can do

Everything above is about one thing: making the invisible parts of your business visible to someone who's walking in cold. That's the gap Heirloom was built for. It's a death binder for solo founders, with a vault for the credentials and recovery steps, a handoff plan that tells your executor what to do first, and named beneficiaries so the decisions land with the people you chose. You can do all of this with a notebook and a locked drawer, and if that's your route, do it this week. If you'd like a place that keeps the billing contacts, the emergency-access notes, and your keep/back-up/kill list together and current, you can start at heirloom.lumenlabs.works.