Bus factor: lo que todo founder no técnico debe saber cuando un solo developer sostiene el código

Carla llevaba tres horas en un viaje de cliente en Austin cuando entró el WhatsApp. Su único developer, Vinicius, estaba en una sala de emergencias con un apéndice roto. Iba a estar bien. El release del martes, no. Había un bug de pagamento en producción que él había estado arreglando por su cuenta, un pull request abierto en una feature que ella le había prometido a un cliente para la semana siguiente, y una migración de base de datos que él había escrito y que nadie más en la empresa había mirado. Carla, COO y co-fundadora de una legaltech de 14 personas, se sentó en el asiento trasero de un Lyft y trató de pensar quién, en su equipo, podía siquiera abrir el repositorio.

Nadie podía. La respuesta era nadie.

Eso es lo que el bus factor mide. El bus factor de un software es el número de personas en el equipo que tendrían que desaparecer, al mismo tiempo, para que el proyecto se detenga. La versión clásica de la pregunta es mórbida (el bus). La versión honesta es mundana: el developer acepta un puesto en Anthropic, sale de licencia de paternidad, tiene apendicitis, o simplemente rota a otro cliente y ahora responde Slack tres horas tarde. En todos esos casos el bus factor de tu producto es el mismo número, y para la mayoría de las startups en etapa temprana construidas alrededor de un solo ingeniero, ese número es uno.

Este artículo es para el founder no técnico que leyó el párrafo anterior con la sensación precisa de miedo que viene de reconocerse en él. Hace tres cosas. Te dice qué mide realmente el bus factor dentro de tu empresa, separado de lo que un blog de ingeniería te dirá que significa. Explica por qué la solución obvia (contratar un segundo developer) suele empeorar la dependencia antes de mejorarla. Y te da un plan de cuatro pasos que puedes correr este trimestre sin duplicar tu headcount.

Qué significa realmente el bus factor, en un párrafo

Bus factor es el número mínimo de personas en un proyecto que, si de repente dejaran de contribuir, dejarían el trabajo sin posibilidad de continuar. El término surgió en comunidades de programación en los años 1990 como humor negro sobre el riesgo de persona clave. Un proyecto con bus factor de uno es un proyecto donde exactamente una persona puede mover el código hacia adelante. Un proyecto con bus factor de tres es un proyecto donde tres personas tendrían que desaparecer al mismo tiempo antes de que el trabajo se detenga. Más alto es más seguro. Más bajo es más frágil. Para un founder no técnico, la definición funcional es aún más simple: bus factor es la pregunta de cuántas personas en tu empresa pueden subir un fix al software vivo mañana por la mañana, sin aviso, sin romper el resto. Para la mayoría de las startups con un solo developer, la respuesta es uno. Que la respuesta sea uno no es inusual. Que la respuesta sea uno y tú no lo sepas es el problema real.

Tres problemas escondidos dentro de una pregunta

Cuando un founder dice “me preocupa qué pasa si mi developer renuncia,” en realidad está preocupado por tres cosas distintas y se mezclan. Separarlas es el primer movimiento, porque cada una se resuelve con una intervención diferente.

Concentración de conocimiento

El primer problema es que el software vivo es un sistema que funciona, pero la explicación de por qué funciona así vive en la cabeza de una persona. ¿Por qué la tabla de pagos está desnormalizada? ¿Por qué el flujo de auth tiene un timeout de 90 segundos? ¿Por qué hay un Cloudflare worker que reescribe la URL los martes por la noche? El código te muestra qué está pasando. No te muestra por qué. Razonamiento, trade-offs y el largo catálogo de “ya intentamos eso y rompió producción” son conocimiento tácito. Nunca entran al repo. Cuando tu único developer se va, el código sigue ahí. Las razones por las que tiene esa forma, no.

La señal de que ese es tu problema: puedes ver quién escribió cada archivo, pero no puedes encontrar un solo documento, comentario o reunión grabada que explique las decisiones de arquitectura que ya pagaste.

Continuidad operacional

El segundo problema es que aunque el sistema siguiera funcionando en piloto automático, no tienes a nadie que pueda cambiarlo. Un fix pequeño en producción un martes por la mañana es una bestia distinta de reconstruir el sistema desde cero. El primero pregunta: ¿puede alguien en quien confías abrir el proyecto, encontrar el bug, subir un patch y no romper el resto? Si la respuesta es no, una inconveniencia rutinaria (un developer de vacaciones, una gripe, un regreso atrasado de feriado) se convierte en una caída visible para el cliente. Ese es el problema del bus factor en su sentido más estrecho e inmediato, y es el que la mayoría de los founders sienten primero.

La señal de que ese es tu problema: una feature lleva “casi lista” dos meses y nadie más que el developer original puede responder dónde está.

Propiedad estratégica

El tercer problema es más abstracto y el que los founders raramente ven hasta estar metidos en él. ¿Quién decide en qué se convierte la base de código a continuación? Cuando la única persona que entiende completamente el sistema actual es también la única que puede decirte con credibilidad qué es y qué no es construible en los próximos seis meses, tu roadmap de producto está siendo implícitamente co-escrito por esa persona. Sus incentivos y los tuyos pueden superponerse perfectamente. Pueden no hacerlo. De cualquier modo, un roadmap con un punto único de falla estratégico es un roadmap frágil.

La señal de que ese es tu problema: cuando le llevas ideas de producto a tu dev, toda respuesta llega en forma de “tendríamos que reconstruir X” o “ya intentamos Y” y tú no puedes evaluar de manera independiente si esos encuadres son precisos.

Estos tres problemas responden a la misma pregunta de superficie. No se resuelven con la misma intervención. Un error común del founder es intentar resolver los tres contratando un segundo developer de una vez, y ese movimiento tiende a fallar al no abordar ninguno en particular.

Por qué tu bus factor probablemente es 1 y no lo sabes

La mayoría de los founders no técnicos, al preguntarles, dirán que creen que su bus factor probablemente es 1, pero no lo saben de verdad. Tres confusiones suelen ser las responsables.

La primera es contar a gente que ha tocado el repo. Un founder con un developer y un contractor part-time va a contar al contractor. El contractor ha subido cuatro pull requests este año, todos pequeños, todos dentro de partes del sistema que el contractor ya conocía. El bus factor no es el número de personas que han tocado el repo. Es el número de personas que pueden abrir el laptop mañana y arreglar el bug en producción que el founder no puede describir. Ese número casi siempre es uno.

La segunda es confundir “tener backups” con “tener redundancia”. Los backups protegen datos. La redundancia protege continuidad. El código está en GitHub. La infra corre en AWS. Cada secreto está en 1Password. Eso es redundancia de datos, y está bien. No dice nada sobre si alguien más en la empresa puede subir el bus factor de uno a dos. Un backup es una foto congelada del sistema. Redundancia es una segunda persona que puede manejar el coche.

La tercera es confundir “tenemos documentación” con “tenemos conocimiento transferible”. Una página de wiki que dice “el flujo de auth está en /src/auth” es técnicamente documentación. No transfiere el conocimiento de por qué el flujo de auth hace timeout en 90 segundos. La prueba de la documentación no es si existe. La prueba es si un developer competente, nuevo, con la documentación y el código en mano, puede subir un fix rutinario en su primera semana sin el autor original presente. Esa vara es mucho más alta de lo que la mayoría de los founders se dan cuenta.

La solución común que empeora el problema

La reacción más común de un founder al descubrir un bus factor de 1 es contratar un segundo developer. A veces es el movimiento correcto y casi siempre se ejecuta mal. Contratas al Developer Dos. Lo subes a bordo, le das acceso a todo, lo apuntas al código y le pides que haga “ramp up”. En los siguientes dos meses, el Developer Dos escribe algo de código, aprende el sistema y le pide contexto al Developer Uno constantemente. El Developer Uno, que ya está al 110% de utilización, se convierte en el cuello de botella del aprendizaje del Developer Dos, y entonces la empresa pasa de un developer productivo a un poco menos de un developer productivo más una nómina más cara.

En el mes tres, una de dos cosas pasa. El Developer Dos ha internalizado lo suficiente del sistema para ser útil y tu bus factor ahora es 2. O el Developer Dos ha internalizado la superficie del sistema pero no las razones, y entonces tu bus factor sigue siendo 1, sólo escondido por la existencia de una segunda persona que puede plausiblemente responder “lo voy a mirar”. Este segundo desenlace es más común y más difícil de detectar porque el headcount se duplicó.

El problema más profundo es que “contratar un segundo developer” confunde nómina con redundancia. Dos developers que ambos dependen de la misma persona para que les explique el código son un bus factor de 1, no importa cuántas personas haya en el equipo. La redundancia que quieres no está en headcount. Está en conocimiento transferible. El headcount sólo se vuelve útil después de que el conocimiento ha sido externalizado.

La secuencia correcta es externalizar primero, contratar después. El resto de este artículo es el playbook para hacerlo en ese orden.

Cinco preguntas para hacerte si tienes un solo developer

Antes de hacer un solo movimiento, corre el diagnóstico de cinco preguntas. Cada respuesta es un párrafo, no un sí o no. El punto es tener una imagen lúcida de tu exposición real.

1. ¿Un developer nuevo, con el repo y la documentación en mano, podría subir un fix rutinario en su primera semana sin tu developer actual presente? Esta es la prueba práctica de cuánto conocimiento está capturado por escrito versus cuánto vive en una cabeza. Si la respuesta honesta es “no”, tienes un problema de concentración de conocimiento, no un problema de contratación.

2. ¿Tu developer actual puede irse diez días de vacaciones sin que tu negocio se detenga? Esta es la prueba de continuidad operacional. Si unas vacaciones normales ya se sienten riesgosas, tienes un problema de continuidad. El arreglo puede no ser una segunda persona. Puede ser proceso: un procedimiento de release documentado, un playbook de soporte para bugs conocidos, una regla clara de qué se pospone versus qué se escala.

3. Cuando le llevas ideas de producto a tu developer, ¿puedes evaluar de forma independiente la respuesta técnica que te da? Esta es la prueba de propiedad estratégica. Si todo “no podemos construir eso porque…” es imposible de cuestionar para ti, no tienes un problema de roadmap con tu developer. Tienes un problema de roadmap contigo mismo, y la respuesta es asesoría técnica independiente, no una segunda contratación.

4. Si tu developer actual se fuera mañana con dos semanas de aviso, ¿qué tendría que contener el documento de traspaso para que la empresa siga funcionando? Este es el ejercicio individual más útil de este artículo. La mayoría de los founders, al preguntárselo, se dan cuenta de que el documento no existe y no es fácil de escribir. El ejercicio de escribir el documento es la externalización.

5. ¿Estás financiando software porque es central para tu negocio, o porque ya no puedes dejar de financiarlo? Esta es la pregunta que nadie hace. Algunas empresas tienen un solo developer porque esa es genuinamente la forma correcta para el estadio. Otras empresas tienen un solo developer porque entraron en software custom y ahora se sienten atrapadas. El segundo caso a veces se resuelve no subiendo el bus factor sino reduciendo la superficie de código custom (ver cómo crear un software cuando no eres el programador para el diagnóstico que distingue los dos).

Las respuestas a estas cinco preguntas te dicen cuál de los tres problemas de arriba es el tuyo, y eso determina qué haces a continuación.

Cuatro pasos para subir tu bus factor sin duplicar headcount

Si el diagnóstico confirma que tienes un problema de bus factor y no un problema de roadmap o un problema de proceso, esta es la secuencia que de verdad funciona.

Paso 1: Externaliza primero el conocimiento de mayor riesgo

El primer movimiento no es una contratación. Es un ejercicio de escritura. Siéntate con tu developer dos horas a la semana, todas las semanas, durante cuatro semanas, y produce un pequeño conjunto de documentos escritos para un developer nuevo que aún no conoce el código. No documentación autogenerada. Prosa real. El conjunto es corto.

Un mapa del sistema de una página: cuáles son las piezas principales, qué hace cada una, qué llama a qué. Un runbook operacional de una página: cómo pasan los releases, a dónde van las alertas, qué hacer a las 3 de la mañana cuando el gateway de pago cae. Un log de decisiones arquitectónicas de una página: las cuatro o cinco decisiones que restringen el sistema hoy, por qué se tomó cada una, y qué se consideró y se descartó. Un documento de “si tuviera que irme mañana”, escrito por el developer en su propia voz, listando los cabos sueltos, las features a medias, las partes del código que él no dejaría que un ingeniero junior tocara sin orientación, y la lista explícita de cosas que ha querido arreglar y no ha arreglado.

Si tu developer se resiste a este ejercicio, eso ya es un hallazgo. Algunos developers se resisten a la documentación porque el contrato implícito ha sido “no necesitas saber lo que yo sé”. Eso no siempre es consciente ni siempre es malintencionado, pero es una señal que vale la pena notar. Plantéalo directamente: este trabajo es para la empresa, no para ti, y va a ayudar también cuando él tome vacaciones.

Paso 2: Compra la dependencia en commits, no en headcount

El movimiento de menor costo y mayor apalancamiento disponible para un founder no técnico con un solo developer es traer un segundo par de manos a tiempo parcial, no como una contratación par a par, sino como un mecanismo de transferencia de conocimiento. Tres opciones funcionan en la práctica. Un ingeniero senior fractional que hace code review y pair programming cuatro horas por semana. Un equipo socio pequeño (una software house enfocada o una dupla de contractors de confianza) que toma una línea de trabajo acotada y la entrega solo mientras corre dudas con tu developer actual. O un único ingeniero senior contratado específicamente para acompañar y absorber, con el mandato explícito de que sus primeras seis semanas son de aprendizaje, no de entrega.

La razón por la que esto funciona mejor que una contratación par a par es que el objetivo explícito es transferencia de conocimiento, no crecimiento de headcount. El contrato es corto. El costo es bajo. El bus factor se mueve de 1 hacia 2 en commits, lentamente, y lo que estás comprando es una segunda persona que de hecho ha tocado el código de producción. Para una comparación más profunda de estas estructuras, la decisión entre equipo in-house y outsourcing cubre el mismo terreno desde el otro lado.

Paso 3: Convierte conocimiento tácito en specs explícitas, una línea de trabajo a la vez

Mientras el Paso 1 produce los documentos fundacionales y el Paso 2 trae un segundo par de manos al código, el tercer paso es empezar a convertir el flujo de trabajo nuevo de “guiado por el developer” a “guiado por spec”. Toda feature nueva recibe una spec de una página antes de ser construida. La spec se escribe en colaboración. Explica el problema de negocio, la solución propuesta, los trade-offs considerados, las alternativas rechazadas y los criterios de aceptación. El punto no es burocracia. El punto es que el razonamiento detrás de cada adición nueva al código entre en la memoria de la empresa en el momento en que se construye, en vez de tener que ser excavado después.

Esto funciona mejor cuando el founder escribe el primer borrador de la spec y el developer lo marca encima. La fricción de ese intercambio es exactamente la fricción que quieres. Obliga al founder a preguntar por qué y al developer a escribir la respuesta. Después de tres o cuatro ciclos, ambos van a ser más rápidos en esto de lo que eran el primer día.

Paso 4: Corre la prueba de la “semana de vacaciones”

El diagnóstico más poderoso para saber si los tres pasos anteriores funcionaron es poner a tu developer de vacaciones por una semana laboral completa, sin laptop y sin Slack. No como una prueba punitiva, como unas vacaciones pagadas reales que él ya se había ganado. Mientras está fuera, tu segundo par de manos (del Paso 2) es tu primera línea para cualquier incidente de producción. Tu equipo de soporte tiene el runbook documentado del Paso 1. El backlog de specs del Paso 3 está ahí para que la segunda persona elija de dónde tomar.

Si una semana normal pasa sin un incidente que tu equipo no pueda manejar, tu bus factor se movió. Si la semana se cae, aprendiste exactamente cuál de los tres sub-problemas (concentración de conocimiento, continuidad, propiedad) sigue vivo. La versión honesta de la prueba de vacaciones también es una decisión de bienestar para tu developer, que probablemente ha cargado guardia invisible durante mucho tiempo. El costo escondido de un bus factor de 1, a menudo olvidado, es el costo que paga el developer que no tiene manera de desconectarse genuinamente.

Cómo se ve “lo bueno”

Un bus factor razonable para una startup en etapa temprana es dos o tres. No diez. El costo de empujarlo por encima de tres antes de que la empresa sea lo suficientemente grande para justificarlo se desperdicia en contexto duplicado que nadie está leyendo. La mayoría de las empresas de menos de treinta personas se sirve bien con un bus factor de dos, donde la segunda persona es o un equipo socio, o un ingeniero senior fractional, o un co-fundador que ha elegido mantener las manos lo suficientemente cerca del código para ser útil en una emergencia.

Un bus factor de uno no siempre está mal. Puede ser una elección deliberada y por tiempo limitado. El founder de una empresa de cinco personas con un developer y runway para nueve meses puede genuinamente estar tomando la decisión correcta. El error es tratar esa condición como permanente. El encuadre correcto es que el bus factor de uno es un estado con fecha de vencimiento conocida, y cada trimestre deberías preguntarte si todavía debería ser uno.

El punto más profundo es que el bus factor no es realmente un número. Es una pregunta sobre quién más dentro de la empresa tiene las llaves del sistema, en la cabeza y en papel. Una vez que has construido los documentos, traído un segundo par de manos y puesto a tu developer de vacaciones sin que el mundo se caiga, dejaste de ser un punto único de falla en tu propia empresa. Eso es lo que la pregunta de verdad está preguntando.

FAQ

¿Qué es un bus factor de 1? Un bus factor de uno significa que una sola persona en el proyecto tiene el conocimiento necesario para mantenerlo funcionando. Si esa persona deja de contribuir por cualquier razón (enfermedad, vacaciones, nuevo trabajo, emergencia familiar), el trabajo no puede continuar sin una disrupción significativa. Para la mayoría de las startups en etapa temprana con un solo developer, el bus factor es uno, incluso cuando el equipo tiene varias personas.

¿Cómo se calcula el bus factor? El cálculo honesto no es una fórmula. Es un experimento mental. Toma una pieza crítica de tu software vivo (el flujo de pago, el sistema de auth, el modelo de datos del que todo el resto depende) y pregúntate: ¿cuántas personas en el equipo podrían abrir el código mañana por la mañana y subir un fix rutinario a esa pieza sin romper el resto? La respuesta es el bus factor de esa parte del sistema. El bus factor del proyecto entero es la menor de esas respuestas a lo largo de los caminos críticos. Varios grupos de investigación han propuesto métricas automatizadas basadas en el historial de commits, pero para un founder, el experimento mental es más útil que la fórmula.

¿Qué es el bus factor en la práctica? En la práctica el bus factor aparece no como una catástrofe sino como una serie de pequeñas fricciones: un developer de vacaciones y un fix que no puedes subir, una feature que nadie más que el autor puede explicar, un roadmap implícitamente co-escrito por la única persona que puede evaluar la respuesta técnica. Esas fricciones diarias son la experiencia vivida de un bus factor bajo, mucho antes de que alguien sea realmente atropellado por un bus.

¿Cuál es un ejemplo de bus factor? Un ejemplo real: una legaltech de 14 personas con un developer senior y un contractor a tiempo parcial. El developer senior escribió el código original, es dueño del pipeline de deploy, tiene las llaves de producción y es la única persona que ha tocado la integración de pagos. El contractor ha subido cuatro fixes, todos dentro de áreas que el contractor ya conocía. La empresa tiene todo el código en GitHub, secretos en 1Password e infraestructura en AWS. El bus factor es uno. La CEO no está totalmente equivocada al sentirse expuesta, y lo que realmente ayudaría es el plan de cuatro pasos de arriba, no una segunda contratación par a par.

¿Cómo se aumenta el bus factor? Externalizando conocimiento antes de añadir headcount. Documentos primero, segundo par de manos segundo, flujo guiado por spec en tercer lugar, y una semana de vacaciones real como prueba. Añadir personas sin antes externalizar el conocimiento que necesitarían absorber no sube el bus factor; sólo reparte la dependencia entre más sueldos. La forma más barata de ir de uno a dos es casi siempre empezar con un ejercicio de escritura, no con una contratación. La misma lógica aparece en el costo a largo plazo de mantener software custom: las líneas de presupuesto que parecen escalar con headcount, en realidad escalan con conocimiento documentado.

Una vez que un founder no técnico ha hecho ese trabajo, la ansiedad original cambia de forma. La pregunta deja de ser “¿qué pasa si mi developer renuncia?” y se convierte en “¿cuál parte del sistema es el próximo punto único de falla a derribar?” Esa es una pregunta mucho mejor para estar haciéndose.