El año que perdí eligiendo tecnología
2024 fue mi año de la parálisis por análisis. En serio.
Pasé meses evaluando stacks. ¿Next.js o Remix? ¿Prisma o Drizzle? ¿PostgreSQL o intentar algo nuevo con SQLite + Turso? ¿Kubernetes desde el inicio o esperar a necesitarlo? ¿Monorepo o polyrepo? ¿REST o GraphQL o tRPC o gRPC?
Cada decisión técnica se sentía irreversible. Como si elegir mal me condenara a reescribir todo en seis meses.
Spoiler: no construí nada en ese tiempo. Cero. Solo comparativas, benchmarks y create-next-app repetidos como un ritual vacío.
La mentira del stack "correcto"
Alguien en Twitter publica su stack: Next.js, TypeScript, tRPC, Prisma, PostgreSQL, Tailwind, Vercel, Clerk, Upstash, Planetscale. Es elegante. Es moderno. Tiene 3,000 likes.
Lo que no te dice es:
- Su producto tiene 47 usuarios
- El 80% de esas tecnologías son overkill para lo que hace
- Cambió de stack tres veces antes de lanzar
- La mitad de esas herramientas las agregó porque "es lo que se usa", no porque las necesitara
Perseguir el stack "correcto" es perseguir una foto de Instagram. Se ve bien, no refleja la realidad.
Lo que realmente importa
Después de un año de inacción, tomé tres decisiones que cambiaron todo:
1. El stack no es el producto. A tus usuarios no les importa si usas PostgreSQL o MongoDB. Les importa que tu producto resuelva su problema, cargue rápido y no pierda sus datos. La elegancia técnica es para ti, no para ellos.
2. El mejor stack es el que conoces. Suena obvio, pero el FOMO tecnológico te hace olvidarlo. Si dominas Laravel, usa Laravel. Si llevas años con Django, usa Django. La velocidad de ejecución con un stack conocido supera cualquier ventaja teórica de uno nuevo.
3. Migrar no es fracasar. "Si elijo mal, tendré que migrar después." Sí. ¿Y? Migrar un producto con usuarios y tracción es un problema de lujo. Significa que tienes algo que vale la pena migrar. Elegir "mal" y lanzar es mejor que elegir "bien" y no lanzar.
Mi stack actual (sin postureo)
Esto es lo que uso hoy para Guayoyo:
- Frontend: Astro + un poco de React donde hace falta. No Next.js. No Remix. Astro. Porque el contenido es estático y no necesito SSR para todo.
- Estilos: Tailwind. Porque es rápido, no porque sea tendencia.
- Hosting: Cloudflare Pages. Despliegue automático desde GitHub, SSL, CDN, cache, todo incluido. Cuesta $0.
- Backend: n8n para workflows, webhooks ocasionales en Node.js puro. Sin framework. Si el backend son 3 endpoints, no necesito NestJS.
- Infraestructura: K3s en un VPS para lo que requiere cómputo real. Sin EKS, sin GKE, sin vendor lock-in.
- Base de datos: PostgreSQL. Sí, la de siempre. La que funciona desde antes de que existiera ORM de moda.
No es el stack que sale en los tweets virales. Pero está en producción, resuelve problemas reales, y lo entiendo completamente.
La regla que me cambió la cabeza
Solo agrego una tecnología cuando la que tengo me duele.
¿Next.js es mejor que Astro para ciertas cosas? Seguro. ¿Me duele Astro hoy? No. Entonces no cambio.
¿Kubernetes es complejo? Sí. ¿Justifica Docker Compose para lo que tengo? Probablemente. Pero K3s me deja crecer sin cambiar de paradigma cuando llegue el momento.
Cada tecnología nueva es una deuda que adquieres. Paga intereses en complejidad, mantenimiento, onboarding y dependencia externa. Asegúrate de que el retorno vale la pena antes de firmar.
Construir > Elegir
Si estás atrapado en el ciclo de "¿qué stack uso?", mi consejo es brutalmente simple:
Elige lo que ya sabes. Construye. Lanza. Itera.
En seis meses, si tu stack actual te está frenando, cambiarlo será un problema que quieres tener — porque significará que tu producto creció lo suficiente como para que importe.
¿Harto del hype tecnológico? Hay más cada semana. Newsletter o X.
Top comments (0)