The repository is not the business

There is a quiet assumption almost every solo developer makes without noticing they've made it: that the code is the company. That if the worst happened, someone could clone the repo, read the README, and carry on. The code is the artifact you spent years on, the thing you're proudest of, the part you'd point to. So of course it's the part that matters.

It isn't. The code is the easy part. The code is the only part that's actually backed up, version-controlled, and recoverable. What dies with you is everything that turns a folder of source files into a thing that runs — and almost none of that lives in the repository.

This is worth sitting with, because the gap between "my family can get the code" and "my family can run the business" is where most solo founders' continuity plans silently fail.

What GitHub will and won't do when you die

Start with the platform itself, because people get this wrong in both directions. GitHub does have a process for deceased and incapacitated users. An authorized person — typically next of kin, or someone you've named — can contact GitHub Support and, with documentation, request a copy of your private repositories or have the account memorialized or removed. GitHub also lets you designate an account successor who can manage your public repositories after your death.

Notice the precise shape of what that offers. A successor can archive or transfer your public repos. A grieving family member can, after a documented request, obtain a copy of your private code. That is genuinely useful and worth setting up.

But it is not access to your account. GitHub will not hand over your password, your session, or your identity. They will not give your successor the ability to be you. And being you is what's required to keep anything running — because the account is the trust anchor that a dozen other systems point back to.

The keys are not in the repo, by design

Here is the part that surprises non-developers and that developers forget under the assumption that they'll always be around to remember it.

A modern application doesn't run on its source code alone. It runs on a set of secrets that are deliberately kept out of the repository — because putting them in would be a security disaster. Your database connection string. Your Stripe secret key. Your API tokens for email, for storage, for every third-party service. Your signing certificates. The environment variables your deploy reads at build time.

Good engineering practice is to never commit these. So you didn't. They live in:

  • GitHub Actions secrets, or your CI provider's encrypted store
  • Your hosting platform's environment-variable settings (Vercel, Fly, Render, a VPS)
  • A .env file on your laptop that is explicitly git-ignored
  • A password manager, if you were disciplined
  • Your head, if you were like most people

Whoever inherits your repo inherits a car with no keys. The engine is pristine. They can read every line. They cannot start it, because the values that connect the code to the live world were intentionally separated from the code. The same discipline that kept you secure is the discipline that locks your heirs out.

Deploy keys, webhooks, and the invisible plumbing

It goes deeper than secrets. Your repository is wired into a web of automated trust relationships that a fresh copy of the code does not reproduce.

There are deploy keys — SSH keys that grant a server permission to pull your code. There are webhooks that fire when you push, triggering builds and deployments. There are OAuth authorizations connecting GitHub to your hosting, your error monitoring, your project tools. There's a CI pipeline that knows how to take a commit and turn it into a running release, encoded in YAML that references secrets your heir can't see and services they don't know exist.

When your successor clones the repo, none of this comes with it. They have the blueprint of the house. They do not have the wiring diagram showing which breaker controls which room, where the water main shuts off, or that the back bedroom outlet has been on the fritz since you rewired it last spring. A blueprint shows what was built. It does not show how it's currently plugged into the grid.

Why your memory was load-bearing

There's a concept in software teams called the bus factor: the number of people who'd have to be hit by a bus before a project stalls because the knowledge to run it is gone. For a healthy team it might be three or four. For a solo founder it is exactly one. You.

The reason the bus factor is so brutal for solo operators is that an enormous amount of operational knowledge never gets written down — not from negligence, but because writing it down has no audience when you're the only reader. You know the staging deploy needs a manual cache flush. You know the migration script has to run before the build, not after. You know that one cron job is fragile and you babysit it. None of this is documented because documentation is communication, and there was no one to communicate with.

This is the trap inside being good at your job. Competence compresses knowledge into intuition. The more fluent you become, the less you externalize, because externalizing feels redundant when the steps live in your hands. The expertise that made you fast is stored in a format only you can read — and it does not survive you.

You can't write it all down — so write the index

The instinct, once you see the gap, is to document everything. Don't. You'll write a forty-page runbook, exhaust yourself, and abandon it in three weeks — and the next time you change your deploy flow, it'll go stale and quietly become a liability, confidently wrong.

The better move is to write the index, not the encyclopedia. Your heir doesn't need to understand your architecture. They need to know enough to hand the whole thing to a competent engineer — or a buyer — without that person starting from a locked black box. Capture the load-bearing pointers:

  • Where the secrets live. Not the secret values in plaintext — the location. "All production secrets are in 1Password, vault named Production. The master password is handled through my estate vault."
  • What runs where. "Code is on GitHub under this account. It deploys to Vercel. The database is hosted at this provider. Email goes through this service."
  • The one path to running it. A single honest paragraph: to deploy a change, here is what happens, in order, and here is the one thing that always trips people up.
  • Who to call. The name of a developer who knows your stack, or the kind of developer to hire. An inheritor who can find the right person has already won.

This is a couple of hours of work, not forty pages. It converts an unrecoverable mystery into a tractable handoff. That's the entire goal: not for your family to run the business, but for them to be able to give it to someone who can — or sell it as an asset instead of writing it off as a loss.

The point isn't the code. It's the keys.

If you take one thing from this: stop worrying about whether your heirs can get the source. They probably can. GitHub has a process, your code is backed up, and a good engineer can read anything. Worry about the keys — the secrets, the access, the wiring, the one-paragraph map of how it all connects. That's the part that's stored only in places that die when you do, and it's the part that decides whether your years of work become an inheritance or an enigma.

This is exactly the seam Heirloom is built to close. It gives you one place to hold the locations of your secrets, the map of what runs where, the named successor, and the short letter that turns your code from a locked box into something a stranger can pick up and keep alive — without forcing you to document your whole life or expose a single password before its time. The code was always going to survive you. With a few hours of work, the keys to it can too. You can start the map at heirloom.lumenlabs.works.