El año pasado, en una madrugada de insomnio, abrí mi GitHub y empecé a hacer algo que ningún developer debería hacer a las 3 AM: revisar repositorios abandonados.
Veintitrés. Todos privados. Todos míos.
El más viejo era de 2021: un bot de trading con machine learning que iba a "cambiar mi situación financiera." Duró 4 commits y un requirements.txt que depende de una versión de TensorFlow que ya ni existe.
El más reciente — de hacía apenas tres meses — era una plataforma de cursos online para developers latinoamericanos. Ese sí avanzó: 87 commits, diseño completo en Figma, dominio comprado. Pero murió igual, a mitad de camino, sin que nadie lo viera.
Esa noche no dormí. No por culpa — por vértigo. ¿Cuántas horas de mi vida estaban enterradas en esos repositorios? ¿Y qué había construido realmente con todo ese esfuerzo? La respuesta me dio más insomnio que el café de las 5 PM.
El verdadero problema no es la disciplina
Cuando hablamos de proyectos abandonados, la conversación suele ir directo a la falta de disciplina. "Es que no tienes constancia." "Es que te rindes fácil." "Es que no tienes un plan."
No es cierto.
En esos mismos cuatro años aprendí TypeScript desde cero, Kubernetes al punto de certificarme, y lo suficiente de redes para montar un homelab que hace llorar a mi factura de electricidad. Mantuve contribuciones regulares a open source y publiqué artículos técnicos cada dos semanas sin fallar. Publiqué artículos. Di mantenimiento a código legacy en producción. Hice cosas difíciles de manera consistente.
La disciplina no era el problema.
El problema era para qué programaba.
Programar por la dopamina
Aquí va una confesión incómoda: durante años, yo no programaba side projects para lanzar productos. Programaba porque se sentía bien.
El git init. La carpeta vacía. Las posibilidades infinitas. Ese momento en que todo es perfecto porque nada existe todavía. No hay bugs. No hay clientes furiosos. No hay decisiones de arquitectura que lamentar. Solo potencial.
Era adicto a esa fase.
Empezar un proyecto es pura dopamina. Todo es nuevo, todo es emocionante, todo está por delante. Pero mantener un proyecto — cuando ya viste el mismo código mil veces, cuando el bug que persigues no se deja atrapar, cuando te das cuenta de que el 80% restante del trabajo es aburrido — eso no genera dopamina. Genera cortisol.
Y yo, sin darme cuenta, me había convertido en un adicto a los inicios.
Construir solo
El segundo patrón era más sutil.
Todos mis side projects eran secretos. No por estrategia — por vergüenza. "Lo muestro cuando esté más avanzado." "Todavía está muy verde." "No quiero que piensen que soy un desastre."
El resultado era predecible: trabajaba semanas en completo aislamiento, sin feedback, sin accountability, sin nadie que me dijera "eso que estás construyendo no le sirve a nadie" o "esa feature que te va a tomar un mes, nadie la va a usar."
Un proyecto en soledad es frágil. Cualquier obstáculo — un bug stubborn, un domingo sin motivación, un tweet que te hace dudar de tu idea — lo tumba. No hay nadie que te sostenga.
Y lo peor: cuando abandonas un proyecto secreto, literalmente no pasa nada. El universo ni se entera. Esa ausencia de consecuencias hace que abandonar sea la opción por defecto.
La fantasía del ingreso pasivo
El tercer asesino era la monetización prematura.
Cada proyecto que empezaba venía con una proyección financiera imaginaria: "si cobro $29/mes y consigo 200 clientes, son $5,800." Hacía números que no tenían ningún anclaje en la realidad mientras el producto no tenía un solo usuario de prueba.
Peor aún: la expectativa de ingresos mataba la experimentación. Ya no estaba jugando, explorando, aprendiendo. Estaba "invirtiendo tiempo." Y cuando algo se convierte en inversión, la presión lo destruye. Cada hora que no generaba retorno se sentía como una pérdida. Cada día sin lanzar era ansiedad acumulada.
Lo irónico: los proyectos que sí terminé fueron los que empecé sin esperar nada a cambio. Sin un Excel de proyecciones. Sin un plan de monetización. Solo por el placer de construir algo y ver si funcionaba.
Lo que cambió
No fue una regla de productividad. No fue un sistema de hábitos. No fue un bullet journal.
Fue entender tres cosas:
Primero: terminar no es binario. No existe "terminado" como estado final. Existe "suficientemente bueno para salir." Un proyecto está listo cuando resuelve un problema para alguien que no eres tú. Punto. No cuando está pulido. No cuando tiene todas las features soñadas. Cuando alguien más puede usarlo y obtener valor.
Segundo: el feedback es oxígeno. Ahora le cuento a alguien lo que estoy construyendo el mismo día que creo el repo. No espero a que esté "presentable." Lo muestro cuando todavía es feo, cuando todavía me da vergüenza, cuando es poco más que un wireframe funcional. Porque el feedback temprano hace dos cosas: valida que lo que estoy construyendo tiene sentido Y me da la energía de saber que hay alguien esperando verlo terminado.
Tercero: separar exploración de ejecución. No todos los proyectos necesitan ser terminados. Algunos existen para aprender una tecnología, para probar una idea loca, para despejar una duda técnica. Esos proyectos no son fracasos — son ejercicios. Pero si el proyecto tiene la intención de llegar a producción, entonces lo trato diferente desde el día uno: defino cuál es el "terminado" mínimo y pongo una fecha. Si no tiene fecha de salida, es exploración. Y está bien que sea exploración. Lo que no está bien es mentirme a mí mismo.
Tu cementerio no es tu enemigo
Aquí está la parte que nadie dice: esos 23 proyectos no fueron una pérdida.
Entre las ruinas de ese cementerio están los cimientos de todo lo que sé. Aprendí Docker intentando containerizar un SaaS que nunca lancé. Aprendí autenticación con JWT construyendo un dashboard que nunca vio un usuario. Aprendí WebSockets para un chat en tiempo real que usé exactamente yo solo, probándolo entre dos pestañas del navegador.
Cada proyecto muerto me dejó algo. Un patrón. Una herramienta. Un "esto no funciona así" que me ahorró semanas en el siguiente intento.
El cementerio no es el problema. El problema es cuando te convences de que todos tus proyectos van a terminar ahí.
Si tienes 5, 10 o 30 repositorios abandonados, no eres mal developer. Eres un developer que ha explorado. Que ha tenido curiosidad. Que ha intentado cosas. Pero tal vez — solo tal vez — ha llegado el momento de que uno de esos intentos cruce la línea de meta.
No porque sea perfecto. Sino porque ya aprendiste suficiente. Porque ya es hora. Porque el próximo commit puede ser Deploy v1.0.
Y cuando ese proyecto esté en producción — feo, incompleto, vulnerable, pero VIVO — vas a mirar atrás y los 23 cadáveres del cementerio van a parecer lo que realmente son: los escalones que te trajeron hasta aquí.
¿Tú también tienes un cementerio? ¿Cuál es el proyecto que más te dolió abandonar? El mío fue una plataforma de cursos que llegó a 87 commits. Todavía tengo el dominio. Por si acaso.
Top comments (0)