The system only one person understood — and what happened when that person was me.

The bus-factor story usually gets told as a warning: a critical system depends on one person, that person leaves or gets hit by a bus (the parable's grim namesake), and the organization discovers too late that nobody else understood how any of it worked. It's a real risk and a fair thing to worry about. It's also usually told from the outside, by someone who inherited the mess, rather than from the inside, by the person who was the bus factor the whole time.

For 3.5 years, I was the sole engineer on a safety-critical children's transport platform — live GPS tracking, safeguarding compliance, the entire technical function, built from a blank page and run by one person the whole way through. That's not a confession. It sustained 99.5%+ uptime the entire time. But it only worked because of specific, deliberate disciplines, not because solo systems are inherently fine if you're careful enough — and it's worth being honest about both halves of that.

How solo systems drift toward tribal knowledge

The drift isn't a failure of discipline in the way it's usually described. It's the default direction absent deliberate counter-pressure, and it happens through a series of individually reasonable decisions. You're moving fast, there's no one else to explain a decision to, so you don't write it down — why would you, you already know why you did it. Six months later, a related decision gets made that only makes sense in light of the first one, and that context lives in your head too. A year in, the system contains a web of decisions that reference each other, none of them documented, all of them perfectly clear to the one person carrying the whole picture, and completely opaque to anyone else.

This isn't laziness. It's the natural gradient of solo work — documentation has a real cost, that cost has no immediate payoff when you're the only audience, and the payoff only becomes visible in a future where either you've forgotten, or someone else needs to understand it. Both of those futures feel abstract in the moment you're deciding whether to spend twenty minutes writing something down. The discipline that fights this drift has to be deliberate, because the default genuinely pulls the other way.

The disciplines that kept it safe

Four practices did most of the work, and none of them are exotic — the value was in doing them consistently over 3.5 years, not in any individual practice being clever.

• Boring infrastructure, on purpose. The backend ran on serverless Firebase specifically because it reduced the number of things that could silently depend on memory alone. A scale-to-zero, managed architecture has fewer moving parts that need a human to babysit them — less custom infrastructure means less tribal knowledge required just to keep the lights on, which freed up the documentation effort that did happen for the parts that actually needed a human's judgment, rather than spending it on infrastructure upkeep.
• Docs written at decision time, not reconstruction time. The honest version of this discipline: it wasn't perfect, and no solo effort is. But the habit of writing a short note at the moment a non-obvious decision got made — even a few sentences — beats, overwhelmingly, trying to reconstruct the reasoning eight months later from the code alone. The cost is small in the moment. The value compounds every time that decision gets revisited.
• Runbooks for anything that could break at an inconvenient hour. Safety-critical, real-time systems fail sometimes, regardless of how carefully they're built. The discipline that mattered wasn't preventing every failure — it was making sure that when something did fail, the response didn't depend on remembering the right steps under pressure. A written runbook, even a short one, turns a 2am incident into a checklist instead of an improvisation.
• 99.5%+ uptime as the receipt, not the target. This is the detail worth being precise about: the number wasn't the goal being optimized for directly. It was the natural output of the other three disciplines, sustained consistently over years. Chasing an uptime number directly, disconnected from the practices that actually produce reliability, is how teams end up with dashboards that look good and systems that are still fragile underneath.

The buyer's checklist for vendor bus-factor

If you're evaluating any vendor, freelancer, or internal team where the honest answer to "who understands this system" is one person, that's not automatically disqualifying — but it does mean you should ask specific questions rather than taking reliability on faith:

• "Where does the knowledge live besides your head?" A specific, concrete answer — a wiki, a set of architecture decision records, an onboarding doc — is a good sign. "I just know it" is not necessarily dishonest, but it is a real, quantifiable risk that deserves to be named explicitly rather than assumed away.
• "What happens if you're unavailable for two weeks?" Not a hostile question — a fair one. The answer tells you whether continuity has been thought through or just hoped for.
• "Is there a runbook for your worst-case failure scenario?" If the honest answer is no, that's useful information about where the actual risk sits in the relationship, independent of how good the day-to-day work is.
• "How would a new developer get productive on this if they had to?" This is the vanish-test again, asked directly of a solo vendor rather than an agency — and it's a completely reasonable thing to ask before depending on someone for something that matters.

None of these questions are an accusation. A solo builder who answers them well — with specifics, not defensiveness — has actually done the work to be a responsible bus-factor-of-one. That's a genuinely different situation from a solo builder who hasn't thought about it, even if both look identical from the outside on any given ordinary day.

How West Fork structures engagements so no client depends on one head

The lesson from those 3.5 years shapes how engagements get structured now, directly. Documentation isn't an optional nicety scheduled for "when there's time" — it's built into the delivery process as a deliverable, the same as the code itself. Architecture decisions get written down at the time they're made, not reconstructed later. And the handoff terms in every contract are explicit about exactly what a client would need if any specific person on the engagement became unavailable — which is the same discipline turned outward, applied to a client relationship instead of a solo codebase.

The bus-factor-of-one story doesn't have to end the way the horror-story version does. It ends fine — it did for the full 3.5 years on the platform this post is about — when the person carrying it treats the discipline as load-bearing rather than optional — and any buyer evaluating a similar situation deserves a vendor who can show, specifically, that they've done the same.