The honest version of the bus-factor question every solo-operator engagement raises, and the concrete, checkable things that actually mitigate it -- not reassurance, specifics.

---

Hiring one person instead of an agency raises a fair question immediately: what happens to the site or the automation if that person gets busy, raises their rates, or simply isn't reachable next year? An agency's pitch is that it has redundancy -- if one developer leaves, another picks up the account. That pitch is often more comforting than true (the person who actually understood your specific setup is still just one person, agency or not), but the underlying worry is legitimate and deserves a real answer instead of a reassuring one.

The Honest Version of the Risk

With a solo operator, there's no second person who already knows your project if the first one is unavailable. That's real, and no amount of process eliminates it -- it can only be mitigated. The question worth asking isn't "could this ever be a problem," which is always yes, it's "if it became a problem, how expensive would it be to recover, and for whom." That second question has concrete, checkable answers, and they're worth asking about before signing, not after something goes wrong.

Mitigation One: Boring, Standard Technology

This is the actual substance behind "Boring Technology Wins" (see that piece for the full argument) -- not a stylistic preference, but the single biggest lever on recovery cost. A site built on React, Next.js, and Postgres can be picked up by any competent developer on reasonably short notice, because thousands of developers already know that stack. A site built on something obscure or hand-rolled to be clever can only really be picked up by whoever built it. Choosing the boring option isn't just about what's pleasant to build with -- it's what keeps a project rescuable by someone else if it has to be.

Mitigation Two: Standard Hosting, Not Proprietary Lock-In

The code and the infrastructure it runs on both matter here. A site deployed on a mainstream platform (Vercel, for instance) with a standard Git repository behind it can be handed to a new developer by sharing repository access and a couple of environment variables -- there's no proprietary system to learn first, no vendor relationship only the original builder can navigate. That's a deliberate choice, not an accident of what happened to be convenient.

Mitigation Three: You Own Everything, From Day One

The domain, the hosting account, the repository -- all of it should be registered in your name and your accounts, not the developer's, from the start. This is less about any individual developer's intentions and entirely about what happens mechanically if a relationship ends badly or a person becomes unreachable: ownership that already sits with you doesn't need to be transferred under pressure. If a vendor insists on holding any of this themselves "for convenience," that's worth pushing back on regardless of how trustworthy they seem today.

Mitigation Four: Documentation That Assumes a Stranger Reads It

Code comments and a README that explain the non-obvious decisions -- not what the code does, which a competent developer can read for themselves, but why it was built that way -- are what actually save a replacement developer time. "This looks unusual because X" is worth more to a stranger than any amount of tidy code with no context at all.

What This Doesn't Solve

None of this makes the honest risk disappear, and it shouldn't be oversold as if it does. What it changes is the shape of the problem: instead of "only one person on Earth can touch this," the real situation becomes "any competent developer could pick this up, given access to a standard stack and a repository that explains its own decisions." That's a solvable afternoon of onboarding for someone else, not a crisis -- and it's the realistic standard to hold any solo-operator engagement to, this one included.