¿Te suena la parálisis por análisis?
Seguro que te ha pasado. Tienes una idea increíble para un proyecto personal, algo que te motiva de verdad. Te sientas frente al teclado, abres una terminal y, justo antes de escribir el primer comando, te asaltan las dudas: ¿Debería usar Next.js con el App Router o me lanzo a probar Remix? ¿Vale la pena meterle TypeScript desde el segundo uno o voy más rápido con JS puro? ¿Y si mejor uso esa base de datos vectorial que vi ayer en Twitter?
A mí me ha pasado más veces de las que me atrevo a admitir. Soy Roberto y, durante mucho tiempo, fui un experto en empezar cosas y un completo desastre terminándolas. Me pasaba semanas comparando benchmarks, leyendo hilos interminables en Reddit sobre el estado de Svelte vs Vue, y configurando el entorno de desarrollo perfecto. Al final, cuando tenía todo listo para empezar a picar código de verdad, la energía se me había evaporado. Tenía un esqueleto técnico impecable, pero cero funcionalidad. Mi disco duro era un cementerio de carpetas con nombres como 'todo-app-v5-final' o 'saas-experiment-new'.
Mi experiencia con el síndrome del objeto brillante
Hubo un momento concreto que me hizo clic en la cabeza. Fue hace un par de años, cuando intenté montar una pequeña herramienta para gestionar mis facturas como autónomo. No era nada del otro mundo, pero quería que fuera tecnológicamente 'perfecta'. Pasé tres semanas saltando de herramienta en herramienta. Empecé con una arquitectura de microservicios (para una app que solo iba a usar yo, ¡una locura!), luego me pasé a un monolito, luego decidí que necesitaba aprender GraphQL porque era lo que se llevaba...
El resultado fue frustrante: no tenía herramienta de facturación y había perdido un tiempo precioso. Mientras tanto, un compañero de profesión lanzó una utilidad similar en un fin de semana usando un stack que yo consideraba 'obsoleto': PHP, un poco de jQuery y CSS a pelo. Su app funcionaba, solucionaba un problema y, lo más importante, estaba publicada. Ahí me di cuenta de que mi obsesión por el framework perfecto no era más que una forma sutil de procrastinación. Me sentía productivo porque estaba aprendiendo, pero en realidad estaba huyendo del miedo a lanzar algo que no fuera perfecto.
¿Por qué me parece importante cambiar de mentalidad?
En nuestra industria, nos bombardean constantemente con la idea de que si no usas la última versión de la herramienta X, te estás quedando atrás. Es una presión constante que nos empuja a estar en un estado de 'aprendizaje infinito' que, aunque es necesario en parte, puede volverse tóxico si nos impide ejecutar. He aprendido que al usuario final le importa un comino si tu backend está hecho con Rust o con un script de Python mal optimizado, siempre y cuando la aplicación cargue rápido y haga lo que promete.
La tecnología es un medio, no el fin. Cuando dejas de ver los frameworks como religiones y empiezas a verlos como martillos o destornilladores, tu flujo de trabajo cambia por completo. Priorizar la utilidad sobre la tendencia te da una libertad mental increíble. Ya no me siento culpable por elegir una herramienta que domino bien en lugar de la que está en el top de GitHub esta semana. Al contrario, me siento orgulloso cuando cierro una pestaña del navegador con un mensaje de 'Deployment Successful'.
Lo que he aprendido en este camino
La lección más valiosa que me llevo es el concepto de 'Boring Technology' (Tecnología Aburrida). No me malinterpretes, me encanta experimentar, pero para mis proyectos serios, ahora elijo lo que me da confianza. He aprendido que la velocidad de desarrollo es mucho más valiosa que el potencial teórico de una herramienta nueva. Si sé que con Express y un poco de SQL puedo tener un MVP en dos días, ¿por qué iba a pasarme una semana peleándome con la configuración de un framework experimental?
Otra cosa fundamental es entender que el código es efímero. Si tu proyecto tiene éxito, probablemente acabes reescribiendo partes de él de todos modos. Obsesionarse con la escalabilidad infinita en el día cero es el error más común del desarrollador entusiasta. No necesitas una infraestructura que soporte un millón de usuarios si todavía no tienes ni diez. Ahora mi mantra es: Haz que funcione, hazlo bonito, hazlo rápido. En ese orden estricto.
Reflexiones finales y un consejo de amigo
Si estás leyendo esto y te sientes identificado, mi consejo es simple: la próxima vez que tengas una idea, elige el stack con el que te sientas más cómodo hoy mismo. No pierdas ni un minuto en comparativas. Abre el editor, inicializa el repositorio y empieza por la funcionalidad principal, la que de verdad aporta valor. Salir del bucle del aprendizaje infinito requiere disciplina, pero la satisfacción de ver algo terminado y funcionando no tiene comparación con leer la documentación de diez frameworks distintos.
A día de hoy, sigo probando cosas nuevas, claro que sí, pero lo hago en espacios controlados, como sandboxes o pequeños scripts de prueba. Para lo que importa, para lo que quiero que el mundo vea, elijo terminar sobre perfeccionar. Al final del día, un proyecto mediocre que está online siempre será infinitamente mejor que un proyecto perfecto que solo vive en tu imaginación y en una carpeta olvidada de tu ordenador. ¡A lanzar se ha dicho!