Qué stack elegir para un SaaS B2B en 2026

"Qué stack elegir" es la pregunta favorita de los founders y la peor inversión de tiempo de los equipos. La realidad es que para un SaaS B2B en 2026, hay una respuesta default que sirve para 90% de los casos — y discutirla 3 meses solo retrasa el producto. Lo que vale la pena pensar son las 4 decisiones que sí mueven aguja.

El stack default (sirve para 9 de cada 10 SaaS B2B)

• Frontend: Next.js 15 (App Router) + React 19 + Tailwind CSS + shadcn/ui.
• Backend: Next.js API routes para 80% de endpoints; servicio Node/Express separado solo para jobs largos o WebSockets.
• Database: PostgreSQL en Supabase, Neon o RDS. ORM: Drizzle o Prisma.
• Auth: Clerk o Auth.js. SSO empresarial agregás después con WorkOS.
• Billing: Stripe + Stripe Customer Portal.
• Email: Resend transaccional + React Email para templates.
• Storage: S3 o R2.
• Background jobs: Inngest o Trigger.dev. (No reinventes con BullMQ salvo que ya lo conozcas.)
• Observabilidad: Sentry + PostHog. Logs en Axiom o Better Stack.
• Hosting: Vercel + Supabase. Para más control: Fly.io + Neon.
• CI/CD: GitHub Actions con tests + Vercel deploy preview por PR.

Este stack permite que un equipo de 2–4 personas haga producto comercial en 4–6 meses. Cualquier dev senior con React puede ramp-upear en una semana. Costos operativos: US$80–300/mes hasta los primeros 5.000 usuarios.

Cuándo salirse del default

1. Tu producto tiene compute pesado (procesamiento de video, ML inference grande, simulaciones). Sumá Modal o RunPod para ese módulo, no para todo.
2. Necesitás real-time bidireccional fuerte (colaboración tipo Figma, multiplayer). Sumá Liveblocks o Partykit.
3. Operás en jurisdicción que exige data on-prem. Self-hosted PostgreSQL + Hetzner/OVH/CloudSigma + Coolify o Dokku.
4. Tu equipo viene de Rails/Django/Laravel. No los obligues a migrar. Backend en Rails + frontend en Next.js funciona perfecto.

Las 4 decisiones que sí valen pensarse

1. Monolito o servicios

Monolito modular por default. Servicios solo cuando hay razón concreta: equipo grande que se pisa en el mismo repo (raro en MVPs), o un módulo con requisitos muy distintos (Node + Python ML por ejemplo). La regla: empezar monolítico y desacoplar después cuando duele.

2. Multi-tenant strategy

Tres opciones: una DB por tenant (caro, simple), shared DB con tenant_id (default, suficiente para 95%), DB-per-region pero shared dentro (avanzado). Default: shared con tenant_id y row-level security en Postgres. Documentá la política y aplicala en cada query.

3. ORM vs query builder vs SQL raw

Drizzle es el sweet spot 2026: type-safe, performante, te deja escribir SQL cuando hace falta. Prisma sigue siendo válido pero con TS heavy y schema separado. Knex/SQL raw solo si tu equipo viene de eso. Evitá ORMs que generan migraciones automáticas opacas.

4. Auth provider managed vs DIY

Clerk: 10× más rápido de setup, US$25/mes piso, deja de tener sentido a partir de 10k MAU (precio escala). Auth.js: gratis, más trabajo de setup, vos manejás las sesiones. Para SaaS B2B con SSO empresarial: Clerk + WorkOS combo es default. Para uso intensivo sin SSO: Auth.js.

Comparativa de hosting + DB

Stack hosting	Costo piso	DX	Cuándo elegir
Vercel + Supabase	US$25/mes	Mejor del mercado	Default, 90% de casos
Vercel + Neon	US$20/mes	Excelente	Default alterno si querés branching DB
Fly.io + Neon	US$20/mes	Buena	Más control de runtime, multi-región
AWS Fargate + RDS	US$120/mes	Media	Cuando enterprise lo exige por compliance
Hetzner + Self-hosted	US$8/mes	Baja	Cost-conscious, hay alguien DevOps

Anti-patrones que matan velocidad

1. Microservicios desde día 0. Suma 30–60% de complejidad sin beneficio antes de los 50k usuarios.
2. Kubernetes para 5 usuarios. Vercel/Fly.io es mejor hasta que tengas razón real para K8s.
3. GraphQL "porque suena moderno". REST + tRPC cubre 95% de necesidades. GraphQL gana cuando tenés muchos clientes consumiendo el mismo API con queries variables.
4. Custom UI framework. Tailwind + shadcn/ui te da 90% del valor. Construir un design system propio antes de tener producto es vanity.
5. Server-side rendering everywhere. ISR + edge caching donde no hay personalización. SSR solo para páginas con auth.

Velocidad a producción (típica con este stack)

• Setup inicial (auth + billing + base): 3–5 días.
• Primer feature core: 1–2 semanas.
• MVP defendible: 8–12 semanas.
• Producto comercial v1: 4–6 meses adicionales.

¿No conviene Bun en lugar de Node?

En 2026 Bun es estable para servicios nuevos, pero Vercel todavía optimiza para Node. Si self-hosteás en Fly.io, Bun da 15–30% mejor performance. Si vas a Vercel, quedate en Node.

¿Y Rust / Go para el backend?

Solo si el cuello de botella real es CPU/throughput y ya validaste el modelo. Para 99% de SaaS B2B, Node + Postgres aguanta a 100k+ usuarios.

¿Conviene microservicios para que el equipo escale?

No. La organización del código importa más que la fragmentación física. Monolito modular bien hecho (carpetas por dominio, dependencias controladas) escala mejor que 12 microservicios mal coordinados.

Lo que recomendamos

Si estás arrancando un SaaS B2B nuevo en 2026: empezá con el stack default tal cual lo describimos. No discutas 2 meses cuál ORM elegir — agarrá Drizzle, escribí código, mové. Los detalles los podés cambiar después; el tiempo perdido en la decisión inicial no lo recuperás.

Si ya tenés equipo con expertise distinto: respetá el expertise. Un equipo de 5 senior Rails va a producir 3× más rápido en Rails + Next.js que en Next.js full-stack. La discusión correcta no es "qué stack es mejor en abstracto", es "qué stack permite a este equipo entregar más rápido sin sacrificar mantenibilidad".