Bus factor in a two-person project: check who can recover it

What bus factor means

Bus factor is the number of people who could leave before a project stops. In a two-person project, it is usually one. That is not a problem by itself. It becomes one when you have never checked.

"Leave" does not have to be dramatic. Illness, a new job, a holiday without a laptop or a lost phone with the two-factor app on it all count.

Two different questions

• Knowledge: does the other person know how it works? Where is the code, how is it deployed, which service sends the emails?
• Access: can the other person actually do it? Log in, deploy, renew the domain, pay the bill.

Knowing is not the same as being able to. Read access to a repository does not mean someone can deploy it. Being listed as a backup contact does not mean the provider will let them in. Test the two separately.

Step 1: build the dependency table

List everything the project needs to run or to get paid. Copy this table and fill one row per resource.

Do not write passwords or recovery codes in this table. Write where the recovery route is, for example "password manager, shared vault" or "phone number of A".

Step 2: run a read-only rehearsal

For each row, the second person tries to prove they could take over. Use only steps that change nothing.

1. Log in as yourself. Can you open the admin page of the account with your own login? If you cannot, mark a gap.
2. Find the recovery path. Open the provider's help page and read what recovery needs: a phone, an email address, an ID. Write it down.
3. Check who can see the bill. If you cannot see the invoice, you cannot tell when the renewal is due.
4. Check the date. Write down the next renewal date for the domain and each paid plan.

Do not revoke access, rotate production secrets, change a password or log the other person out. A rehearsal that breaks something is not a rehearsal.

A worked example (illustrative)

Two founders. A set up the domain, the hosting and the payment card. B wrote half the code and has read access to the repository.

All three rows show the same pattern: B knows the project, but cannot act. The next action is to add B as a second admin and to move the billing email to a shared project address. This example is made up to show the method. It is not a real project.

Step 3: close the gaps

• Two admins per account wherever the provider allows it. If it allows only one owner, write down how ownership can be transferred and test that route on a spare account, not on the real one.
• A shared project email for billing and recovery, not one person's inbox.
• A password manager with a shared vault for the accounts that cannot have two admins.
• A short runbook: three lines per resource for how to deploy, how to renew and who to contact.

Step 4: repeat it

Run the table again when someone joins or leaves, when you add a paid tool and before each renewal. Fifteen minutes each time is enough once the table exists.

I run a two-person side project. Below is the list of tools we use, with who signed up and who pays. Do not ask for passwords or recovery codes.
Build a table with these columns: resource, who knows how it works, owner or admin, payer, recovery route (describe, do not invent), second person tested (leave empty), gap and next action.
Then list the five gaps most likely to stop the project if one of us is unavailable for a month.
Tools:
[PASTE HERE]

Frequently asked questions

Related

• Access audit: who could lock you out today?
• Handover checklist for when someone leaves.
• Team charter template: who owns, pays for and can recover each account.
• Who owns the domain when co-founders split