# How To Calculate Your Startup's Bus Factor Before It Costs You

> A startup's bus factor reveals who could break their codebase if they left, and how to fix it without new hires.
- Title: How To Calculate Your Startup's Bus Factor Before It Costs You
- Summary: A startup's bus factor reveals who could break their codebase if they left, and how to fix it without new hires.
- Keywords: bus factor, git blame, codebase, engineering, code review, pairing, documentation, left-pad, azer koçulu, guilherme avelino, github, Startup Fortune
- Source: Startup Fortune — https://startupfortune.com/how-to-calculate-your-startups-bus-factor-before-it-costs-you
- Published: 2026-11-06T15:15:42+00:00
- Read time: 2 min
- Topics: bus factor, git blame, codebase, startups, engineering, code review, pairing, documentation, left-pad, azer koçulu, guilherme avelino, github
## What is bus factor?
Bus factor measures the smallest number of people who, if they quit tomorrow, would leave your codebase unmaintainable.
## Left-pad incident shows bus factor 1 consequences
In March 2016, developer Azer Koçulu unpublished an 11-line npm package called left-pad, breaking builds across the internet.
## 2016 study reveals most projects have bus factor 1 or 2
A 2016 academic study of 133,000 GitHub repositories found most popular projects had a bus factor of just 1 or 2.
## How to calculate bus factor yourself
Run git log for each repository, count contributions weighted by lines changed and commit frequency over the last 12 months.
## Bus factor 1 on critical services is existential
A bus factor of 1 on payments, auth, or deploy infrastructure costs customers or money before morning.
## Why git blame alone understates risk
Commit history shows who touched code but not who understands why it's shaped the way it is.
## Tribal knowledge concentration matters more
Ask engineers to list three systems they'd be nervous handing off with one week's notice and cross-reference answers.
## Mandatory code review reduces risk
Mandatory code review with rotation forces exposure over time without slowing down the team.
## Pairing on critical systems works faster
Pair on legacy billing jobs instead of new features to expose risk faster.
## Documentation prevents knowledge loss
A single README per service answers what it does, why it exists, and who last touched it.
## Prioritize critical services first
Rank services by revenue exposure before running bus factor calculations on top of that list.
## Fix bus factor before it costs you
The calculation takes an afternoon; waiting for a crisis costs more than the time spent.
## Key takeaway

A startup's bus factor measures how many people must leave before code becomes unmaintainable; reducing it prevents costly failures.