What happens if I disappear.

Somewhere near the end of most first calls, the voice changes. The scoping questions are done, the price band has been said out loud, and then, carefully: “and what happens if, you know… you’re not available anymore?” It’s the politest phrasing I’ve heard for what if you get hit by a bus. And it is the single most reasonable question anyone asks me. You’re considering wiring five figures to one person. One calendar, one immune system, one motorcycle. If that person’s availability is a hidden dependency of your business, no discount covers the risk.

So here is my answer in writing, at full length, with the uncomfortable parts included. Not because I plan to vanish — because a plan that only exists in my head fails the exact test it’s supposed to pass.

§1The question behind the question

The software industry has a name for this risk: the bus factor — the number of people who’d have to vanish before a project stalls. A solo developer is a bus factor of one, permanently. I can’t hire my way out of that without becoming the agency I chose not to be. What I can do is change what stalls. A person can disappear. The question is whether anything you paid for disappears with them.

Notice what that sentence doesn’t contain: “don’t worry,” “I’m very reliable,” “I’ve never missed a deadline.” Reassurance is a personality reference, and personality references die with the person. Everything below is architecture instead — checkable while I’m alive, working after I’m not. Q.01 in the transcript on my homepage gives the short version. This entry is the long one.

One more thing before the plan. I’d ask this question too, in your chair — harder than you’re asking it. So nothing below asks you to extend trust. Every claim below is checkable from your side of the table. An account you hold. A file you can open. A test you can run.

§2If I vanish mid-build

Start with the worst timing: not after a tidy handover, but week four of a seven-week build, with milestone three half done. I stop answering email. My phone rings out. What do you actually hold?

More than you’d guess, because none of it was scheduled for the end. The repository has lived in your GitHub account since day one, with every line pushed as it was written. The working habit is in the handover entry, and it means the code on my laptop is never the only copy. You can watch it happening during the build, too: GitHub stamps every push, so “is the project moving?” has a public answer. Silence in the commit log is information days before it becomes a missed call. The milestones you’ve paid for are legally yours already. My contract assigns ownership milestone by milestone, not at final payment. That’s precisely so a disaster in week four can’t reach back and unwind weeks one through three. The server is in your hosting account, on your card. The scope document from the scoping week describes, in plain language, what each remaining milestone was supposed to do. A replacement developer isn’t reverse-engineering intentions from code; they’re finishing a documented plan against a written definition of done.

And the money: you haven’t paid for anything that doesn’t exist. Milestone billing gets discussed as a payment schedule, but it’s really a continuity feature wearing an invoice’s clothes. At any moment, the gap between what you’ve paid and what you hold is at most one milestone of work — bounded, known, and survivable.

What do you lose? Plainly: my momentum, my context, and some calendar. A new developer needs time to read the repo and the scope doc before they’re productive. That’s a real cost, weeks not months, and I can’t engineer it away. What you don’t lose is the system, the code, the data, or the money already spent. The blast radius is a delay, not a crater.

And since the rescue guides never say it concretely, here is the actual to-do list for that week, in order. Revoke my access (repo collaborator, server login) the way §6 of the handover entry describes; it was always yours to revoke. Take a manual backup and a server snapshot, so the bad week starts from a save point. Read the scope document once, start to finish, until you can describe the remaining work in your own words. Then write the job post — §4 tells you what goes in it. Four steps, one afternoon, no panic required.

§3What keeps running without me

Now the calmer scenario: the build is done, delivered, running — and I evaporate. Here the answer is almost boring, and boring is the point. Your system’s daily operation involves me exactly zero times. The application runs on your server. The database backs itself up on a schedule and keeps copies you can restore; you watched one restored, live, at the handover call. The security certificates renew themselves. The domain renews off your card at your registrar. nginx, the web server in front of everything, does not attend funerals.

Software doesn’t stop when its author does; it degrades on a timescale you can read in advance. This week: nothing happens. This quarter: nothing happens, though nobody is applying dependency updates. This year: updates are genuinely overdue, and you should have a developer, any developer, do a maintenance pass. The failure mode of an owned system with no developer isn’t a sudden outage. It’s slow drift, visible in advance, fixable by whoever you hire whenever you hire them. A cold maintenance pass is also a quotable job rather than an exploration. The runbook lists what runs where. A developer meeting the system for the first time can price the work after an hour of reading, not a week of digging. Ask for a fixed quote on “update dependencies, verify backups, refresh the last-verified dates” and you’ll get one. Compare that with what §7 says about the rented version of this risk.

§4The recovery kit

Your next developer, the stranger at the center of this whole entry, opens five things on their first morning. All five have existed since launch:

• The repo, in your GitHub account, full history included. They read code and commits, not tea leaves.
• The README, which takes them from empty laptop to running system. It was tested against exactly this scenario. The fire-me test is a stranger deploying from the README alone, and clients can run it before final payment.
• The operations runbook — logs, backups, schedules, what-to-check-first. Written for a bad day, read on one.
• The decision log, so they don’t spend their first week re-litigating choices that had reasons.
• The walkthrough recording — 60 to 90 minutes of me, screen shared, deploying and restoring and touring the code. Its intended audience was never you. It was always this person, on this morning.

None of this was written as a will. It’s the same handover kit every build produces at launch, which is the trick of the whole plan: continuity isn’t an extra service I sell. It’s what my normal deliverables happen to add up to.

How long until the new person is productive? Reading the repo and the docs is a day or two. The recording is 90 minutes. Genuine fluency arrives over a few weeks of normal work, and the kit can’t teleport that. What it removes is the archaeology — the months a developer spends excavating an undocumented system before they dare change it.

Two notes on actually hiring that person. First, the stack is the job post. The system is React, Node.js, and PostgreSQL — one of the largest developer pools that exists. No niche-specialist hunt, which was the point of choosing boring technology. Second, attach the README and the architecture note to the post itself. Candidates who read them will ask better questions in the first call. The ones who quote you work without reading them have answered a question too.

§5What the enterprise does instead: escrow

Big companies buying software from vendors they don’t fully trust invented a formal fix for this fear decades ago: source-code escrow. The vendor deposits its code with a neutral third party. If the vendor fails (bankruptcy, abandonment, breach), the customer can apply to have the code released. It’s a real industry with real scale: NCC Group bought Iron Mountain’s escrow business in 2021 for a reported $220 million and became the largest escrow provider in the UK and US. Serious people pay serious money for this.

Read the mechanism again and notice what it assumes. Escrow exists because the vendor keeps the source code and the customer doesn’t have it. The entire apparatus (the vault, the deposit schedule, the release conditions, the annual fee) is a workaround for withheld ownership. My clients don’t need the workaround. The thing escrow releases to you in a disaster is sitting in your GitHub account on an ordinary Tuesday. You can’t need a key released to you when the door is already yours. I mention escrow not to mock it; for closed-source vendors it’s often the only option. But it’s the strongest available proof that “what if the developer disappears” is a question the whole industry takes seriously. The difference is where the answer lives: in a vault in Manchester, or in your own account.

One detail from that industry is worth stealing outright. Escrow agreements come in tiers, and the better ones pay the agent to periodically build the deposited code, proving the deposit actually compiles. That’s the fire-me test again — performed by a company in a data center, billed annually. The cheap version is a stranger with your README and two hours.

§6The limits, stated plainly

A continuity plan that claims to cover everything is lying somewhere. Here is what mine does not cover:

• The warranty dies with me. My 60-day warranty (bugs I introduced, fixed free) is a promise from one person. If I’m gone, nobody inherits it. What softens this is the scope document. It defines “working” line by line, so a replacement developer can be held to the same definition. But held by you, at your cost. A care agreement doesn’t patch this either; it’s the same one person on both papers. That’s a genuine hole, and I’d rather name it than have you find it.
• Momentum can’t be escrowed. Mid-project disappearance costs you the weeks it takes to find and onboard a replacement. The artifacts shrink that cost; nothing deletes it.
• The recording ages. The walkthrough is a launch-day snapshot, and systems change after launch. Maintenance passes refresh the written docs’ “last verified” dates, so the paper stays current. A recording can’t be refreshed, only re-recorded — weigh its age accordingly.
• If you need firm-level continuity, hire a firm. An agency’s pitch on this question is real: staff cover for each other, and the company outlives any employee. You pay for that continuity in overhead on every invoice, all year, against an event that probably never happens. But if even the §2 delay would be unacceptable for your business, that trade can be rational. I’d rather lose that client honestly than win them with a promise one person can’t make.

§7Vendors disappear too

One more reframe before the checklist, because this fear gets aimed exclusively at small vendors and it shouldn’t be. Software companies vanish constantly — they call it a sunset. The famous example is Google Reader: announced March 13, 2013, gone July 1, 2013. Three and a half months for millions of users to pack up and leave. That notice came from one of the largest companies on earth, for a product people relied on daily. Google survived. The workflows built on Reader didn’t. And sunsets don’t require failure: products get acquired and folded into the buyer’s roadmap, plans merge, prices restructure. The vendor doing well is not the same as your tool surviving.

Renting software doesn’t remove the disappearance risk. It moves the risk to a company whose roadmap you can’t see and whose support you can’t email. And it adds a deadline. When a SaaS product sunsets, you migrate on their schedule, exporting what their tool allows — the five-year entry’s exit bill, due all at once. The practical move, if you rent anything you’d miss: run the export today, while nothing is wrong, and look at what comes out. An export you’ve never tested is the rented version of an untested backup. When I disappear, nothing about your system changes that week. You hire someone when you’re ready, and the software runs while you look. A vendor vanishes and takes the product along. A developer vanishes and leaves the product behind. The second is the smaller version of the same universal risk.

§8Your half of the plan

Continuity is two-sided, and your side takes about an hour to set up. Six items:

• A named owner inside your business. One person who attended the walkthrough, holds the vault, and knows where things live. Decided before launch, not during a crisis.
• The repo, owned by an organization. A repository under one personal GitHub account has a bus factor of its own. A GitHub organization with two owners (you and your named person) survives either of you losing an account, a phone, or a password.
• Emergency access to the password vault. Password managers have a formal feature for exactly this: Bitwarden’s Emergency Access lets you appoint a trusted contact who can request your vault. If you don’t veto within a wait period you set, access is granted automatically. Ten minutes of setup, and the credentials survive your bus as well as mine. It’s a premium-tier feature — the cost is a few dollars a month against the price of being locked out of your own system.
• Auto-renew, verified. Domain and hosting on auto-renew, against a company card that doesn’t expire quietly. The most common way owned systems actually die has nothing to do with developers: the card behind the domain lapses.
• The recording, findable. The walkthrough video lives where your named owner can locate it in five minutes. Next to the vault, not in an email thread from two years ago.
• The folder. From the ownership entry: signed contract, toolkit attachment, a note of where repo and accounts live. Continuity paperwork and due-diligence paperwork turn out to be the same folder.

And the portable version, for any developer you’re vetting, me included — ask it straight: “Walk me through the week after you disappear.” A real answer names what you hold and when you started holding it. A weak answer describes how reliable they are. You’re not hiring reliability. You’re hiring a system that doesn’t need it. And send the question to agencies too; “we’re a stable company” has a Google Reader-shaped hole in it.

This entry leans on two others. The handover covers every artifact in §4, with the tests each must pass. Who owns the code is why the week-four scenario in §2 ends with a delay instead of a lawsuit. Read those two and this question stops being a leap of faith in either direction.