La decisión que los founders sobreestiman y los CTOs subestiman
Cuando un founder me pregunta qué stack debería usar para su producto, la respuesta que quiere escuchar es una lista concreta: "usa esto para el frontend, esto para el backend, esto para la base de datos". Y puedo dársela. Pero antes de llegar a esa lista, hay una conversación más importante que tener.
El stack tecnológico no es lo que determina si un producto triunfa o falla. Lo que determina el éxito es qué tan rápido puedes encontrar un problema real, construir algo que lo resuelva, y llegar a las personas correctas antes de quedarte sin runway.
He visto startups con arquitecturas brillantes que nunca encontraron un cliente. Y he visto productos construidos sobre WordPress que facturan siete cifras. La elección del stack importa, pero importa dentro de un rango razonable, y ese rango es más amplio de lo que la mayoría cree.
Dicho eso: dentro de ese rango razonable, algunas elecciones son claramente mejores que otras según el contexto. Y hacer la elección equivocada no mata el producto, pero sí puede hacerlo significativamente más caro de mantener y escalar. Eso es lo que voy a desarmar en este artículo.
El error más caro: elegir el stack por las razones equivocadas
Hay tres razones malas para elegir un stack, y las tres son más comunes de lo que debería:
"Es lo que más conozco." Si el equipo técnico solo sabe PHP, hacer el backend en PHP es pragmático. Pero si esa elección frena la contratación, dificulta la integración con el ecosistema moderno de herramientas, y genera deuda técnica que va a ser cara de pagar en 18 meses, el costo de aprender algo nuevo ahora es menor que el costo de migrar después.
"Es lo que usa [empresa grande que admiro]." Uber usa Go. Airbnb usa React. Netflix usa Java. Ninguna de esas elecciones fue tomada para un equipo de 3 personas con 6 meses de runway. La escala de esos problemas no es la tuya. Lo que funciona a millones de usuarios por segundo no necesariamente es lo correcto para llegar a los primeros 1.000.
"Es lo más nuevo y moderno." La tecnología de frontera tiene documentación escasa, comunidades pequeñas, y más bugs sin resolver. Para un equipo que necesita moverse rápido, pelear con los problemas de una herramienta inmadura es un lujo que no puedes permitirte. Aburrido y probado generalmente gana.
Las tres preguntas que definen el stack correcto
Antes de hablar de tecnologías específicas, necesito respuestas a estas tres preguntas:
1. ¿Qué tan incierta es la forma del producto?
Si todavía estás validando si el producto resuelve un problema real —si el modelo de negocio no está confirmado, si el flujo principal todavía puede cambiar radicalmente— necesitas un stack que te permita iterar rápido aunque sea técnicamente imperfecto. La velocidad de cambio importa más que la elegancia de la arquitectura.
Si ya tienes validación y estás en modo de escala —crecimiento predecible, problemas de ingeniería bien definidos— puedes permitirte hacer elecciones más pensadas para el largo plazo.
2. ¿Cuántas personas van a construir esto?
Un equipo de una o dos personas con capacidad full-stack necesita un stack que minimice el contexto a manejar. Tener frontend, backend, base de datos, y infraestructura separados por 4 lenguajes distintos es una carga cognitiva enorme para un equipo pequeño.
Un equipo de 8 personas con especialización puede dividir las responsabilidades y optimizar cada capa de forma independiente. Lo que es excesivo para un equipo pequeño puede ser necesario para un equipo grande.
3. ¿Qué tipo de problema técnico es el core del producto?
Un SaaS de gestión con tablas, formularios y reportes tiene requerimientos muy distintos a una plataforma de procesamiento de video en tiempo real, una aplicación de IA generativa, o un marketplace con lógica de matching compleja. El stack correcto para uno puede ser inadecuado para el otro.
El stack que recomiendo para la mayoría de los SaaS B2B en 2026
Con todas las advertencias anteriores claras, hay una combinación que funciona para la mayoría de los proyectos SaaS B2B que un equipo pequeño construye hoy:
Frontend + Backend: Next.js con TypeScript
Next.js con el App Router es hoy el estándar de facto para productos web que necesitan ser rápidos de construir, buenos en SEO, y mantenibles por equipos pequeños. La razón principal no es que sea el mejor framework en términos técnicos abstractos —es que concentra el mayor ecosistema de componentes, documentación, soluciones a problemas comunes, y desarrolladores disponibles en el mercado.
TypeScript sobre JavaScript no es opcional en 2026. La inversión inicial en tipos se paga con creces en la reducción de bugs en producción y en la mantenibilidad cuando alguien nuevo entra al proyecto seis meses después.
Para la mayoría de los SaaS, Next.js como monolito —frontend y API routes en el mismo repositorio— es suficiente hasta los primeros 50.000 usuarios activos. No necesitas microservicios. No necesitas separar el backend en su propio servicio. Añadir complejidad de infraestructura antes de necesitarla es deuda técnica disfrazada de arquitectura.
Base de datos: PostgreSQL
PostgreSQL es la base de datos relacional más capaz que existe hoy y es gratuita. Para el 95% de los SaaS, una base de datos relacional con buen modelado de datos es todo lo que necesitas. Si en algún momento necesitas algo que PostgreSQL no puede hacer bien, sabrás exactamente por qué y estarás en posición de evaluarlo con datos reales, no con especulaciones.
La elección de proveedor depende del contexto:
- Supabase: la mejor opción para empezar. PostgreSQL gestionado + autenticación + storage + APIs en tiempo real. Reduce a cero el trabajo de infraestructura inicial y tiene capa gratuita generosa.
- Neon: PostgreSQL serverless con branching de base de datos. Excelente para equipos que trabajan con múltiples ambientes y quieren costos proporcionales al uso real.
- RDS / Cloud SQL: cuando necesitas SLAs enterprise y ya tienes infraestructura en AWS o GCP.
MongoDB y otras bases de datos de documentos raramente son la elección correcta para SaaS B2B. La flexibilidad de esquema que prometen se convierte en inconsistencia de datos y queries complejas en cuanto el producto tiene más de 6 meses en producción.
Infraestructura: Vercel + Railway
Para el frontend y las API routes de Next.js, Vercel es la opción obvia. Deploy automático desde Git, preview deployments por cada pull request, CDN global, y zero configuración. El costo es razonable hasta escalas medianas.
Para servicios de backend independientes cuando eventualmente los necesites —workers de procesamiento, jobs programados, servicios de integración— Railway es la opción más simple que existe hoy. Un contenedor con variables de entorno, sin necesidad de configurar clusters ni load balancers.
AWS y GCP tienen sentido cuando tienes un equipo de DevOps dedicado o requerimientos de compliance que obligan a elegir proveedores específicos. Para un equipo de 3 a 10 personas construyendo un SaaS, la complejidad operacional de AWS supera sus ventajas.
Autenticación: Clerk o Auth.js
La autenticación es un problema resuelto. No lo construyas desde cero. Clerk tiene la mejor experiencia de implementación del mercado hoy —en 30 minutos tienes login con email, Google, magic links, y MFA funcionando— y su modelo de precios es razonable hasta decenas de miles de usuarios.
Si prefieres algo open source y auto-hospedado, Auth.js (antes NextAuth) es la alternativa estándar para proyectos Next.js.
Cuándo este stack no es el correcto
Hay casos donde esta recomendación no aplica:
Si el core del producto requiere procesamiento de datos pesado. Análisis de ML, procesamiento de imágenes o video, pipelines de datos de alto volumen: Python es imbatible para estas tareas. Un backend en FastAPI para la lógica de ML, expuesto como API y consumido desde Next.js, es una separación limpia que tiene sentido.
Si necesitas latencia extremadamente baja a escala masiva. Go o Rust para los servicios críticos de performance. Pero esto raramente aplica antes de los 100.000 usuarios concurrentes.
Si el equipo ya tiene expertise profundo en otro stack. Un equipo de cinco desarrolladores expertos en Laravel puede construir un SaaS de calidad en PHP más rápido que el mismo equipo aprendiendo Next.js. El costo del cambio importa.
Si hay requerimientos de compliance que dictan la infraestructura. HIPAA, SOC 2, o regulaciones locales pueden forzar decisiones de proveedor independientemente de lo que sea técnicamente óptimo.
La trampa de la sobre-ingeniería temprana
El error que veo más frecuentemente en founders técnicos es diseñar la arquitectura para el problema que van a tener en dos años en lugar del problema que tienen hoy.
Microservicios para un producto con 50 usuarios. Event sourcing para una aplicación CRUD. Kubernetes para un equipo de dos personas. Cada una de estas decisiones agrega carga cognitiva, tiempo de debugging, y fricción de onboarding para nuevos desarrolladores, a cambio de ventajas que no se materializan hasta escala.
La regla que uso: construye el monolito hasta que el dolor de no tenerlo separado sea concreto y medible. No especulativo. Cuando un servicio específico tiene que escalar de forma independiente porque los datos lo confirman, ese es el momento de separarlo. No antes.
Jeff Bezos describió esta idea como "two-way door decisions" vs. "one-way door decisions". Las decisiones que se pueden revertir con costo razonable —añadir un servicio, refactorizar un módulo— no merecen la misma deliberación que las que son difíciles de deshacer, como cambiar la base de datos principal o migrar de proveedor de infraestructura.
El stack para productos con componentes de IA en 2026
Si el producto incluye funcionalidades de IA —generación de texto, análisis de documentos, agentes, búsqueda semántica— hay capas adicionales a considerar:
LLM como API externa: Anthropic, OpenAI, o Google. No entrenes modelos propios a menos que tengas un equipo de ML dedicado y datos propietarios que justifiquen el costo. Las APIs de los modelos frontier son baratas a escala de startup y mejoran constantemente.
Base de datos vectorial para búsqueda semántica: pgvector sobre PostgreSQL es suficiente para la mayoría de los casos hasta millones de vectores. Pinecone o Weaviate si el volumen de búsqueda vectorial es el core del producto.
Orquestación de agentes: n8n para flujos de automatización con LLMs. Vercel AI SDK si los agentes viven directamente en la aplicación Next.js. LangGraph para sistemas de agentes con estado complejo.
Una heurística simple para decidir
Cuando alguien me presenta una propuesta de stack y no sé bien si es la correcta, hago una pregunta: ¿cuánto tiempo tardaría un desarrollador nuevo, con dos años de experiencia, en entender este sistema y hacer su primer deploy productivo?
Si la respuesta es más de una semana, probablemente hay complejidad innecesaria en algún lado. Los mejores sistemas que he visto en producción son los que un desarrollador competente puede entender en su totalidad en un día.
La complejidad que no puedes explicar a alguien en una hora es complejidad que vas a pagar con tiempo de debugging, bugs en producción, y fricción de equipo durante los próximos años.
El stack es una decisión, no una identidad
El error más frecuente que veo en conversaciones sobre tecnología —especialmente en comunidades de desarrolladores— es tratar el stack como una identidad. "Soy de React, no de Vue". "Uso Go, no Node". Ese tipo de lealtades no sirven a los objetivos del producto.
El stack correcto es el que permite a tu equipo específico resolver el problema específico de tus clientes, con la velocidad que requiere el contexto de tu negocio, al costo que puedes sostener. Eso cambia con el tiempo, y cambiar de herramientas cuando el contexto lo justifica no es una señal de inconsistencia —es ingeniería pragmática.
Si estás evaluando el stack de tu producto y quieres una segunda opinión, eso es exactamente el tipo de conversación que tengo en los diagnósticos gratuitos. Treinta minutos para revisar tu contexto, tu equipo, y tu producto, y darte una recomendación concreta con el razonamiento detrás.