Por qué Next.js 16 y Tailwind v4 para todo el stack de VantLabs

Hay un patrón que veo repetirse en studios pequeños: cada producto usa un stack distinto porque "ese problema necesitaba esa herramienta". Suena razonable. En la práctica, mata la productividad. Cuando tienes que cambiar de proyecto, tu cabeza tiene que cambiar de modelo mental: rutas distintas, tipos distintos, convenciones distintas, scripts distintos. Lo que parece flexibilidad es fricción acumulada.

En VantLabs tomé la decisión opuesta: una sola stack web, opinionada, consistente entre todos los productos. Hoy es Next.js 16 + React 19 + Tailwind v4 + TypeScript + Postgres + Prisma + NextAuth. Misma estructura de carpetas, mismas convenciones de nombres, mismo formato de commits. Cuando salto entre el corporativo, ReclamaAI o el dashboard interno, no cambio de mundo.

Por qué Next.js 16 (y no otra cosa)

Probé varias alternativas — Remix, SvelteKit, Astro, incluso volver a Laravel + Inertia. Next.js 16 ganó por tres razones concretas:

• Server Components reales. El modelo mental de "renderizar en el servidor por defecto, hidratar solo lo que necesita interacción" es exactamente cómo escribiría una app si pudiera elegir. Reduce el bundle de cliente brutalmente sin perder DX.
• App Router maduro. En la versión 13 era prometedor pero frágil. En la 16 es robusto: layouts anidados, route groups, dynamic params como Promise, generación estática selectiva, streaming, suspense. Todo funciona junto sin sorpresas.
• Vercel, sin lock-in. Despliego en Vercel porque es lo más fácil, pero el código no depende de Vercel. Si mañana quiero mover todo a un VPS con Node, lo hago. Esa libertad importa.

La parte más controversial: en Next.js 16 los params dinámicos son una Promise. Esto rompe casi cualquier tutorial viejo, y el primer reflejo es quejarse. Después de tres días con la nueva API, prefiero esto. Forzar el await en server components hace explícito que la página puede estar streamando datos. Es más honesto.

Por qué Tailwind v4 (y no v3)

La v4 elimina el archivo tailwind.config.js en favor de un @theme inline dentro de tu CSS, y eso, de entrada, suena como retroceso. ¿Configurar Tailwind desde CSS? ¿En serio?

Después de migrar tres proyectos: sí, en serio, es mejor. Las razones:

1. Tokens en CSS variables. Mi paleta vive en tokens.css como variables nativas. Tailwind las consume vía @theme inline. Resultado: las mismas variables sirven para Tailwind, para CSS puro, para componentes con style, y para librerías externas. Una sola fuente de verdad.
2. OKLCH como ciudadano de primera. Toda la paleta de VantLabs está en oklch(). Eso me da control perceptual del contraste (algo imposible con HSL) y dark-mode-friendly mixing con color-mix(). Tailwind v4 lo soporta sin parches.
3. Build más rápido. El nuevo motor (Lightning CSS bajo el capó) es perceptiblemente más rápido en proyectos medianos. No es la razón principal, pero es bienvenido.

Lo que NO me gustó del cambio

Tailwind v4 todavía no tiene un equivalente oficial a @tailwindcss/typography. Tuve que escribir mis propias reglas para los artículos del blog (selectores descendentes en un wrapper Prose). Funciona bien y es más fácil de personalizar, pero significa más código que mantener.

Por qué no usamos un design system de terceros

shadcn/ui es probablemente la librería más popular del momento y es excelente. La uso en ReclamaAI. Pero para el sitio corporativo decidí no usarla: cada componente lo escribo desde cero. ¿Por qué?

• El sitio corporativo es la cara pública del studio. Necesita un look distintivo, no genérico.
• Son ~25 componentes. Escribirlos a mano me dio control total del visual y reforzó el design system desde adentro.
• No hay actualizaciones de terceros que romper. El día de mañana, si quiero cambiar el radius de un botón en todo el sitio, lo hago en un solo archivo.

El costo real

Unificar el stack tiene un costo: pierdes la libertad de usar la herramienta perfecta para cada problema. Ese costo es real. Lo pago con gusto porque la otra cara — saltar entre proyectos sin cambiar de cerebro — vale más para un solo founder.

Si VantLabs creciera a 5 o 10 personas, esta decisión podría no escalar. Pero ese día no es hoy.