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

Every pre-seed software startup has a person without whom 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, put a fix live, 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 term rather than a reason to walk away.

What is a bus factor?

The bus factor is the minimum number of team members who would have to suddenly disappear before the project stalls for lack of anyone who 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.

The concentration is normal at small scale, 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 most of them would stall 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 put a fix in front of customers, and where are the steps they would follow?" Deployment is the act of making a change live. 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 head, 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 fails first when a founder goes quiet.

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

Because it is the one that turns a good product into no product without anything going wrong with the code.

At pre-seed, the product is small, the architecture is simple, and the security surface is limited. 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 buy. A bus factor of one means that question has a single point of failure.

The standard angel checklists touch this from the management side. 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 price it?

Treat the bus factor as a term rather than a verdict. 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 put a change live. This costs the founder an afternoon and is the cheapest insurance 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 key.
3. A second engineer as a named use of funds. If the round is meant to buy 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 on equity, 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 at a fraction of a person.

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 the one is not on the cap table. 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 hobby project with a valuation.

Everything else is a number to write on the one-page output and a term to put in the round, and most pre-seed deals land there. The pillar page lists this as the second of the three technical risks that decide pre-seed deals, after the demo-versus-production gap and before the AI claim.