Bus Factor of One: How to Tell If Your Business Depends on a Single Developer

Bus factor risk is the chance that your software stops working the moment one specific person is unavailable. The term comes from a blunt question first asked among software teams: how many people would need to get hit by a bus before the project stalls? If the honest answer is one, you have a bus factor of one, and for a growing business that number says more about your risk than almost any other technical metric, because it has nothing to do with how good the code is and everything to do with what happens when that one person is gone, whether they quit, get sick, or take a two week trip somewhere without cell service.

Most owners who run into this never saw it coming. One developer built and ran everything for years, the product worked, and nobody had a reason to ask who else could step in. Then that developer left, and the company found out nobody else could deploy a fix, reset a password, or explain why the checkout page needed one specific environment variable to boot at all.

What bus factor risk looks like

Bus factor is not about how many developers are on payroll. A team of five can still have a bus factor of one if only one of them understands the deployment process, holds the working credentials for the hosting account, or is the only person who has ever touched the payment integration. The number describes how concentrated the knowledge is, not how many people are around.

For a non-technical owner, the clearest sign is usually the simplest one: if your developer disappeared tomorrow with no warning, could anyone else log in, see what is running, and keep the site up for a week? If you are not sure, or if the honest answer is no, you already have your number.

Where this hides in a business that seems fine

A few patterns show up again and again in companies that discover their bus factor the hard way.

Deploys go through one laptop. Not a documented process, not a script anyone else can run, just one person's machine with the right keys and the right muscle memory. When that laptop is unavailable, so is the ability to ship a fix.

Passwords live in one head, or in a notes app on one phone. Hosting, domain registrar, database admin, payment processor: each of these needs a login, and in a bus factor of one situation, the same person holds most or all of them, often without a shared vault backing any of it up.

Nothing is written down. Not because the developer was careless, but because documentation never felt urgent while they were still around to answer questions directly. The knowledge exists, just not anywhere a second person could find it.

There is no second admin. Most small companies never got around to adding a backup owner on the hosting account, the domain, or the code repository, because for years there was no obvious reason to.

Nobody has tested a recovery. Even where backups or documentation exist, nobody has confirmed that a second person can use them to bring the system back up. A backup nobody has restored is a hope, not a plan.

The ten question bus factor check

Answer these honestly, without asking your developer for help first. If you need to ask them, that is itself part of the answer.

1. If your developer became unreachable today, could you log into the hosting account within the hour?
2. Does anyone besides that one developer have admin access to your domain registrar?
3. Could someone else deploy a code fix without calling them first?
4. Is there a password manager or vault a second person can access, or does access live only in one person's memory or personal device?
5. Do you know what triggers a deployment: a manual command, a script, a merge to a specific branch?
6. Is there a written record of what each scheduled job or cron task does, and what breaks if it stops running?
7. Has a second person ever successfully restored a backup, or does the backup exist untested?
8. Do you know which third-party services (payment processor, email sender, external APIs) the product depends on, and who holds those credentials?
9. If a certificate or a subscription tied to the infrastructure expired, would anyone notice before customers did?
10. Could you answer all of the above without your developer sitting next to you?

Two or fewer confident yes answers means you are running with a bus factor of one, whether or not you have called it that before.

Why this happens even when the team looks fine on paper

Small and mid-sized companies build this risk gradually, not on purpose. Hiring a second developer costs money that a working product does not obviously need yet. Documentation takes time away from shipping features, and it is hard to justify writing down what one person already knows by heart. Access controls feel like overhead until the day they are the only thing standing between a business and a locked out production environment.

The businesses that get hurt worst are usually the ones growing fastest, because more customers and more revenue mean more depends on the system staying up, while the underlying setup has not caught up with that growth.

What it costs when the one person is gone

The cost rarely shows up as a single dramatic outage. More often it is a slow bleed: a bug that used to take an hour now takes a week because nobody knows where to look, a scheduled job quietly fails and nobody notices for a month, a client integration breaks and there is no one left who remembers how it was wired together. By the time a company brings in outside help, the immediate problem is often smaller than the accumulated mess around it: undocumented decisions, credentials nobody can find, and a codebase nobody currently working on it understands.

We have covered the acute version of this problem, the fourteen days right after a sole developer resigns, in our guide to what to do when your only developer quits. If you are inheriting a codebase someone else built with no documentation to speak of, our 30 day plan for getting productive on an undocumented codebase covers it from the other side of the handover.

Reducing the number before it becomes a crisis

You do not need to double your engineering headcount to fix a bus factor of one. A shared credential vault, a second admin on every account that matters, and a written record of how deployments actually happen will cover most of the risk on their own. A code quality review can also surface what is undocumented and fragile before it becomes urgent, and our code quality consulting work is built around exactly that: finding out what only one person currently understands, and getting it written down and shared before you need it.

If you want a second opinion on how exposed your business actually is, email us at hello@wolf-tech.io or find more about how we work at wolf-tech.io. A short conversation is usually enough to tell you whether your bus factor is one or something safer.