The store doesn't send flowers

When a solo founder dies, the apps usually outlive the news by a few weeks. Friends are still posting tributes, the family is still on the phone with the funeral home, and somewhere in Cupertino a billing system is doing the only thing it knows how to do: waiting for an annual renewal that isn't going to come.

Then one morning the apps are simply gone. Not deleted in anger, not pulled for a policy violation — just removed from sale, the quiet phrase Apple uses when a membership lapses. The reviews stay up like a headstone. The download button disappears. And the people who depended on that software, or hoped to inherit the income from it, discover that the thing they thought of as an asset was really a lease in the founder's name only.

This is one of the most overlooked failure points in a solo software business, precisely because nothing dramatic happens. There's no lawsuit, no seized bank account. The platform just stops recognizing you, because the one person it recognized is no longer renewing.

Why an individual developer account is built to die with you

The Apple Developer Program has two enrollment types, and the difference matters enormously after death.

An organization enrollment is tied to a legal entity — an LLC or corporation with its own D-U-N-S number. The entity can have multiple team members, roles, and an Account Holder who can be replaced. The business is the account; people come and go beneath it.

An individual enrollment is tied to you. Your name, your Apple Account, your identity verification. Apple is explicit that individual memberships are non-transferable. There is no "add my spouse as a backup Account Holder" button, because the account isn't a container for a business — it is a person, in Apple's eyes. When that person dies, there is no role for anyone to inherit, because no role was ever created.

Most solo founders enroll as individuals. It's faster, it's cheaper, it doesn't require forming a company first. And it quietly guarantees that the account cannot be handed off the way you'd hand off a domain or a Stripe balance.

The renewal clock no one is watching

Apple's individual and organization memberships renew annually for ninety-nine dollars. That renewal is the heartbeat of your presence on the App Store. Miss it, and your apps are removed from the store until the membership is restored.

While you're alive, this is a non-event — the card on file gets charged, you barely notice. After you're gone, it becomes a countdown. Maybe the card expires. Maybe it's the card that gets frozen when the bank learns of the death. Maybe the renewal email lands in an inbox nobody can open because it's protected by two-factor authentication tied to a phone that's now in a drawer.

The cruel timing is that the renewal lapse and the legal estate process run on completely different clocks. Removal from sale can happen within weeks. Probate — the court process that might eventually give someone legal authority to act — routinely takes months. By the time an executor has the paper authority to even ask Apple for help, the apps have already been dark long enough that rankings collapse, customers churn, and whatever the business was worth has bled out.

App transfer is a living person's tool

Apple does have a legitimate mechanism for moving apps between accounts: app transfer. A developer can transfer an individual app to another developer's account without losing its reviews, ratings, or existing users. It's how acquisitions and reorganizations happen cleanly.

Here is the catch that undoes it for estate purposes: the transfer must be initiated by the account holder, from inside their account, and both accounts must be in good standing with no blocking agreements or tax forms outstanding. It is, by design, an action only the living, authenticated owner can take.

A dead founder cannot initiate a transfer. An executor cannot log in and do it on their behalf, because doing so means impersonating the deceased through their two-factor authentication — which is both against the terms and, depending on jurisdiction, legally fraught. So the one clean tool that exists is the one tool that becomes unavailable at exactly the moment you need it.

What's left is the slow path: contacting Apple, proving death and legal authority, and asking a human to make an exception. It's not impossible — platforms do accommodate deceased-account requests — but it is slow, discretionary, and running against that ninety-nine-dollar countdown the whole time.

Google Play, and why the second store isn't a backup

If you ship on Android too, don't assume the second store is a safety net. Google Play's economics differ — a one-time twenty-five-dollar registration fee rather than an annual renewal, so there's no membership lapse to immediately pull your apps. But the access problem is identical. The Play Console is locked behind a Google account and its own two-factor protection. Google offers an Inactive Account Manager that can grant a trusted contact access to a Google account after a set period of inactivity, but most developers have never configured it, and it operates on Google's timeline, not your family's.

Two stores means two separate identity walls, two sets of credentials, two recovery processes — and the same single point of failure underneath both: a brain that held the logins and a thumb that cleared the prompts, now gone.

The bus factor was never about buses

Engineers have a grim phrase for this: the bus factor — the number of people who'd have to be hit by a bus before a project is in serious trouble. For most solo app businesses, the bus factor is one. Not because the code is fragile, but because the access is. The software runs fine. It's the keys to the storefront that live in exactly one head.

The fix isn't morbid and it isn't complicated. It's a deliberate decision, made while you're healthy, about how the storefront survives an absence:

  • Know which enrollment you actually have. If you're an individual developer making real money, moving to an organization enrollment under an LLC changes the account from a person into a transferable entity — the single most durable structural fix available.
  • Write down the renewal dates and who pays them. The Apple membership renews annually; whoever steps in needs to know the deadline exists before it's missed, and which card it draws from.
  • Solve the two-factor problem on paper. Recovery keys, trusted phone numbers, and a way for a named person to actually receive the codes — because every recovery path in this story dead-ends at a 2FA prompt nobody can answer.
  • Configure the tools the platforms already give you. Google's Inactive Account Manager and Apple's broader Legacy Contact features won't transfer a developer program by themselves, but they're free, they exist, and an unconfigured safety net catches no one.
  • Name the person and tell them. Knowledge of what to do is worthless if it dies with you; the plan has to live somewhere a specific, named human can reach it.

Don't make grief do the discovery

The hardest part of all this isn't the policy details. It's that every one of these steps assumes someone, somewhere, knows the account exists, knows the renewal is coming, and knows where to find the recovery keys — at a moment when they are least equipped to go looking. Without that, your executor's first task isn't transferring your apps. It's reverse-engineering that you had a developer account at all, usually from a charge on a credit card statement, long after the store has gone quiet.

That reverse-engineering is exactly what a continuity plan is meant to prevent — and it's the gap Heirloom is built to close. It gives a solo founder one place to record what platforms hold the business, which accounts renew and when, where the recovery keys live, and who is authorized to step in — so the people you leave behind inherit a clear handoff instead of a billing mystery and a vanishing storefront. If your apps are worth building, they're worth a plan that outlives you. You can start one at heirloom.lumenlabs.works.