The single-developer risk: bus factor at pre-seed

Every pre-seed software startup has a person without whom work on the product stops. Sometimes that person is the founder. Sometimes it is a contractor the founder pays by the hour, or a friend who built the first version for equity and has since taken a job. The single-developer risk is that this person leaves, gets ill, or loses interest, and nobody else can change the code, make a fix available to users, or explain how it works.

This page is about seeing that risk in a screen share, deciding how much it matters in a given deal, and turning it into a condition of the investment rather than a reason to decline the deal.

What is a bus factor?

The bus factor is the minimum number of team members who would have to suddenly disappear before work on the project stops because nobody left knows how it works. The name comes from the question "what if they were hit by a bus". Wikipedia's entry traces an early public use to 1994, when Michael McLay asked on a mailing list what would happen to the Python language if its creator Guido van Rossum were hit by a bus. The same idea appears in the software literature as the truck factor.

A startup with one developer has a bus factor of one. The product's continued existence depends on one person's health, interest and availability.

Depending on one or two people is normal in small projects, and there is a measurement to show it. In April 2016, Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente published an automated method for estimating truck factors and ran it against 133 popular open-source projects on GitHub. Sixty-five percent had a truck factor of 2 or less. These were established projects with public contributors, and work on most of them would stop if two people left. A pre-seed company with one engineer is at the low end of a distribution that is already low.

How does an angel see the risk in a screen share?

You do not need to read code. Two things on screen answer most of the question.

The commit history. Every version control system keeps a log of changes with a name against each. Ask the founder to open it and scroll back three months. Count the names. One name is a bus factor of one, whatever the deck says about the team. Two names where the second appears once a month is still a bus factor of one, with a helper. Two names alternating week by week is a bus factor of two.

Look at the dates too. If the single name has a gap of four weeks in the last three months, ask what happened. Sometimes the answer is a holiday. Sometimes it is that the developer took a contract elsewhere and the product did not change for a month, which tells you what the next gap will look like.

The deployment question. Ask: "If you were unreachable for a month starting tomorrow, who could make a fix available to customers, and where are the steps they would follow?" Deployment is the act of making a change available to users. It is a sequence someone knows. If it is written down, or automated so that pushing a change runs it, a second person can do it. If it is only in one person's memory, the bus factor for deployment is one even when two people can write code.

A good answer is a name and a file. An honest answer is "nobody, and the second hire in this round is an engineer". The bad answer is "it is all in the cloud so it is fine", which describes where the product runs and says nothing about who can change it. The one-hour technical check gives this ten minutes and a written output.

Reveneau's angel review reports bus factor as a number with two parts, one for changing the code and one for deploying it, because the two are different and the second is the one that stops working first when a founder stops responding.

Why is this the most important technical question at pre-seed?

Because it is the one that can stop a good product from being changed at all, even when nothing is wrong with the code.

At pre-seed, the product is small, the architecture is simple, and there are few ways for an attacker to get in. The things a professional technical review spends most of its time on matter less than they will at Series B. What matters is whether the company can keep changing the product for the eighteen months the round is meant to pay for. A bus factor of one means the answer depends on one person.

The standard angel checklists cover this in their management sections. The UKBAA's September 2020 guide asks, in its management section, how well the team know each other and what happens if one of them leaves. Matt Van Itallie's October 2022 prep checklist on TechCrunch, written for founders about to face a technical review, asks companies to list current and former software developers, to identify the most important developers to the product, and, if any have left, to explain how the company managed without them. That last question is the bus factor asked in the past tense, and it is worth asking at pre-seed too: has anyone who wrote part of this product already left, and what happened?

How should an angel account for it in the deal?

Treat the bus factor as a condition of the deal rather than a final decision. Three things reduce the risk, and each can be asked for.

1. Written deployment steps within thirty days. A page that a competent engineer who has never seen the product could follow to make a change available to users. This costs the founder an afternoon and is the cheapest protection in the deal.
2. A second person with access. Someone who can log in to the code, the hosting and the domain, and has done a deployment at least once. This can be a co-founder, an advisor, or a contractor on a retainer. The point is that the founder's laptop is not the only way into the systems.
3. A second engineer as a named use of funds. If the round is meant to pay for eighteen months, ask what month the second engineer starts, and check that the number in the use-of-funds slide covers it.

If the founder is the single developer, the risk is smaller than if the developer is a contractor, because founders stay. If the developer is a contractor or a friend paid in shares, ask to meet them, ask what they are paid, and ask what else they are working on. A single developer who works on the product ten hours a week and holds a full-time job elsewhere is a bus factor of one who gives the product only part of their time.

Evaluating a technical founder covers the case where the single developer is the founder and the question becomes whether that person is good. Assessing the engineering team is the fuller treatment for a later-stage deal, and how to take over a codebase you did not write is what the second engineer will face when they arrive.

When is a bus factor of one a reason to stop?

Three cases.

When the single developer is not in the company. A product built by an agency that retains the code, or by a contractor with no contract assigning the work, has a bus factor of one, and that one person is not a shareholder in the company. The angel checklists cover this under IP ownership, and it is worth checking there too.

When the founder does not know it is a risk. A founder who answers the deployment question with "that is not something I have thought about" has not thought about the next eighteen months either.

When there is no plan to change it. A bus factor of one with written steps and a second hire in month three is a pre-seed company. A bus factor of one with no steps and no hire in the plan is a side project being sold at a company's price.

Everything else is a number to write on the one-page output and a condition to put in the deal, and that is where most pre-seed deals end up. The main guide page lists this as the second of the three technical risks that decide pre-seed deals, after the demo-versus-production difference and before the AI claim.