Por que Next.js es nuestro stack default (y cuando no lo elegimos)

Si miras los proyectos del portafolio de Pair Programming, hay un patrón evidente: casi todos comparten stack. Next.js como framework, React como capa de UI, Supabase como base de datos y backend, Tailwind y shadcn/ui para estilos. No es casualidad, ni pereza. Es una decisión de arquitectura consciente. Vamos al porque.

El criterio: lo que valoramos en un stack

Antes de defender el stack, los criterios que usamos para elegirlo:

1. Tiempo de entrega: qué se pueda salir a producir rápido.
2. Mantenibilidad: qué en 18 meses, otro developer pueda entender y modificar.
3. Costo operativo: qué no tenga un piso mensual obligatorio alto.
4. Performance percibida: qué el usuario final sienta el producto rápido.
5. SEO friendly: para productos públicos, fundamental.
6. Ecosistema: qué cuando aparezca un problema, ya este resuelto en algún lado.

Por qué Next.js

Cubre los 6 criterios mejor que cualquier otro framework hoy:

Rendering híbrido. Next.js permite que cada página decida si renderiza en el servidor (SSR), si se genera estaticamente al build (SSG), o si es totalmente cliente (CSR). Esto es enorme: el home y las landings van estáticas (rapidísimas, SEO perfecto), el dashboard interno va SSR con auth, los componentes muy interactivos van cliente. Una sola codebase, modos distintos por página.

App Router con Server Components. Desde Next.js 13+ con el App Router, los componentes son server por default. Eso significa menos JavaScript al cliente, mejor performance, y la posibilidad de hacer queries a la base directamente en el componente sin armar una API.

Imagen, fuentes y scripts optimizados de fabrica. next/image hace lazy loading, srcset, formatos modernos automáticamente. next/font carga fuentes sin layout shift. next/script controla el orden de ejecución. Cosas que en otro stack serian semanas de optimización, en Next.js vienen gratis.

SEO de primera clase. La estructura del framework está pensada para sitios indexables: metadata API por página, sitemap.ts dinámico, robots.ts, rewrites y redirects en config, structured data fácil. Hicimos SEO programático con cientos de páginas indexables sin pelear contra el framework.

Deploy en Vercel. Cero configuración, edge network mundial, escalado automático, preview por pull request. El costo arranca en USD 0 y solo subís cuando el proyecto demuestra tráfico real.

Por qué Supabase como compañero

React por si solo no es suficiente: necesitas datos, auth, storage. Las opciones son: armar todo a mano (lento), AWS desde cero (complejo), o usar un BaaS (backend-as-a-service). Entre los BaaS, Supabase gana por:

• Postgres real, no una pseudo-base como Firebase. SQL, relaciones, transacciones, lo que esperarias.
• Auth completa incluida, con magic links, OAuth, social logins.
• Row Level Security a nivel base de datos, crítico para multi-tenant.
• Storage para archivos con CDN.
• Open source, podés self-hostear si las cosas se ponen serias.
• pgvector disponible para embeddings y IA (lo usamos en Tontin).
• Edge functions para lógica server-side custom.

El stack en acción: 4 proyectos diferentes

Lo bueno del stack es que sirve en contextos muy distintos sin pelearse:

Mi Seguro de Auto: producto público, alto tráfico SEO, integraciones con aseguradoras. Next.js renderiza páginas programáticas optimizadas para Google, Supabase guarda cotizaciones y leads. Cada página pesa poco y carga rápido en mobile (que es donde el 80% de los usuarios cotizan).

La Carolina: CRM interno, no necesita SEO pero si auth robusta, multi-tenant y performance en operaciones complejas. Mismo stack, distinto enfoque: server components para data fetching, RLS para aislamiento, sync bidireccional con Google Calendar via edge functions.

Tontin: plataforma con IA pesada, embeddings, multiple LLMs en fallback chain. Next.js orquesta el frontend y la API, Supabase guarda conversaciones y embeddings con pgvector, edge functions manejan llamadas a modelos.

Zweifel Capital: sitio premium para family office en Londres/Buenos Aires/Nassau. Estaticos puros, diseño cuidado, multi-idioma. Next.js + Tailwind, deploy estático en Vercel. Cero base de datos, cero backend, todo edge. Otra cara del mismo stack.

Cuándo NO elegimos Next.js

Hay casos donde otra opción es mejor:

• Backend pesado sin UI: si lo que necesitas es una API pura sin frontend, Fastify o NestJS son mejores.
• Apps mobile nativas: React Native es otra cosa. Y si necesitas performance nativa real, Flutter o Swift/Kotlin directos.
• Aplicaciones realtime complejas: para algo como un editor colaborativo tipo Figma o un juego multiplayer, necesitas más peso en cliente con stacks tipo Vue + Pinia + WebRTC o equivalente.
• Sitios extremadamente simples: una landing de un solo producto puede armarse en Astro o incluso HTML/CSS plano. Next.js es overkill.

El argumento más fuerte: aburrimiento

Lo mejor de elegir un stack consistente es el aburrimiento positivo. No estamos cada proyecto eligiendo de nuevo, evaluando alternativas, debatiendo. El equipo conoce las herramientas, los patrones se reutilizan, los problemas comunes ya están resueltos. Eso libera energía para resolver el problema del cliente, qué es lo que importa.

Conclusión

Next.js + React + Supabase + Tailwind cubre casi todo el espectro de aplicaciones web modernas. No es el mejor para todo, pero es lo suficientemente bueno para todo lo común y sobresaliente para lo más frecuente. Esa combinación de versatilidad y madurez es lo que lo hace el default razonable hoy.

Si estas decidiendo stack para un proyecto nuevo o evaluando migrar uno existente, hablemos. Te ayudamos a pensar la decisión técnica considerando tu producto, tu equipo y tu timeline.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.