Solo, pero no solo
Llevar proyectos como una sola persona suena arriesgado. Para muchos clientes es la primera bandera roja, “¿y si le pasa algo?”, “¿y si desaparece?”, “¿quién lo arregla si se pone enfermo?”. Entiendo esas preocupaciones, yo mismo las tendría antes de probar este modelo en carne propia.
En la práctica, el desarrollo en solitario no es la ausencia de un equipo, es otra forma de organizar el trabajo. En lugar de repartir la responsabilidad entre cinco personas, la concentro en un solo lugar. Menos personas no significa menos competencia. Significa menos fricción.
Además no trabajo en el vacío, uso herramientas, agentes de IA y a veces subcontratistas para tareas muy concretas. La diferencia es que decido yo cuándo y con quién, y no una estructura rígida de empresa que tiene que mantener a gente en movimiento esté o no realmente necesaria.
Menos capas de comunicación
En una agencia clásica, el camino de la información es más o menos así: el cliente escribe al account manager, este lo transmite al project manager, el project manager pregunta al desarrollador, el desarrollador responde al project manager, este vuelve al account manager y solo al final el cliente recibe la respuesta. Cada capa es una oportunidad de distorsionar el mensaje y un día más de retraso.
En mi caso es distinto: la pregunta del cliente -> yo -> la respuesta. Sin traducir los requisitos al “lenguaje de negocio” y luego de vuelta al técnico. Sin perder contexto por el camino. Cuando el cliente escribe “me gustaría que funcionara un poco distinto”, yo sé de inmediato a qué fragmento de código se refiere, porque lo escribí yo mismo la semana anterior.
Esto tiene también una ventaja menos evidente, no hay tentación de diluir la responsabilidad de una decisión entre varias personas. Si propongo algo es porque yo mismo lo respaldo, y no porque lo decidió un equipo en una reunión en la que no participé.
Responsabilidad total
Cuando el código se rompe en producción a las dos de la madrugada, no hay a quién señalar con el dedo. No hay “eso no es mi módulo”, no hay peloteo entre frontend y backend, no hay que esperar a que otro se despierte y reaccione. Solo está la pregunta: ¿lo arreglo ahora o mañana por la mañana, y qué tan rápido?
Suena a carga, y a veces lo es. Pero lo mismo funciona al revés. Cuando el proyecto sale bien, cuando el cliente vuelve con otro encargo o me recomienda, es al cien por cien resultado de mi trabajo. No tengo que repartir el mérito con un equipo que justo tuvo una semana mala, ni explicar que “esa parte no era mía”.
Esa responsabilidad total también cambia la forma en que abordo el propio código. Lo escribo como si supiera que dentro de seis meses tendré que leerlo y arreglarlo yo, porque así es. No hay tentación de dejar algo “para luego” esperando a que lo coja la siguiente persona del equipo.
Más rápido, no más lento
El mayor mito sobre el desarrollo en solitario es que una persona tiene que trabajar más lento que un equipo. En teoría, menos manos, menos horas a la semana. En la práctica cuenta otra cosa: cuánto tiempo va de verdad a construir y cuánto a coordinarse.
Sin daily standups, retrospectivas ni sprint planning queda más tiempo para construir de verdad. No tengo que escribir estados para el project manager, no espero dos días a un code review, no explico decisiones técnicas a alguien que de todos modos no las implementará. Una decisión que en un equipo se tomaría en una reunión de una hora, en mi caso se toma en unos minutos, porque no hay que convencer a nadie, basta con saber que es la buena dirección.
Eso no significa que trabaje sin proceso. Tengo mis rituales, checklists y formas de probar y desplegar. La diferencia es que ese proceso me sirve a mí y no al revés, puedo cambiarlo de un día para otro si veo que algo no funciona, sin tener que acordarlo con nadie.
Para quién tiene sentido
El desarrollo en solitario no es la respuesta universal para cualquier proyecto. En sistemas realmente grandes y de varios años, donde hace falta trabajo paralelo en muchos módulos, un equipo tiene sentido, una sola persona físicamente no puede con todo a la vez.
Pero para la mayoría de proyectos pequeños y medianos, páginas corporativas, aplicaciones para un solo cliente, MVPs que tienen que validar una idea en el mercado, el desarrollo en solitario ofrece algo que un equipo muchas veces no puede: velocidad de decisión, coherencia técnica de la primera a la última línea de código y alguien que conoce de verdad todo el proyecto, no solo su fragmento.