¿Cuál es la mejor forma de estructurar un proyecto Next.js en 2026?

no existe una forma única "mejor" porque depende mucho del tamaño y tipo del proyecto, pero la mayoría de la gente está usando app router con server components, typescript, y organizando por features en lugar de por tipo de archivo - eso deja todo más escalable y menos un desastre cuando el proyecto crece.

Next.js 2026 está en un punto estable con el app router consolidado, pero la verdad es que mucha gente estructura mal porque no piensa en escalabilidad desde el proyecto uno. Cuando empiezas, es fácil caer en la trampa de mezclar lógica de servidor con componentes client, y después queda un caos intentar refactorizar. Lo que funciona bien es separar las carpetas no solo por features, sino especialmente tener una estructura clara de dónde se fetchean y se procesan las cosas.

Una cosa práctica que pocas personas mencionan: crear un archivo de configuración centralizado para variables de ambiente y endpoints desde el inicio. No es glamoroso, pero evita duplicación monstruosa después. Por ejemplo, en lugar de esparcir URLs de la API en varios archivos, tener un `src/config/api.ts` que importas en todos lados te ahorra horas. También vale la pena pensar temprano en cómo vas a lidiar con caché de datos y revalidation - Next.js ofrece varias opciones (ISR, revalidateTag, etc), pero hay que elegir basado en lo que realmente necesitas, no copiar lo que viste en un tutorial.

La estructura de carpetas en sí puede seguir patrones como `(group)` para rutas relacionadas, `_components` para componentes privados de la feature, y `_lib` para utilidades locales. El punto crítico es mantener server components como estándar y solo hacer client components cuando realmente necesites interactividad - eso resuelve la mitad de los problemas de performance solo.

¿Cuál es el tamaño de tu proyecto, un pequeño MVP o algo que va a crecer? Lo que falta en la conversación anterior es hablar de observabilidad desde el principio - logging, monitoreo de performance, esas cosas que parecen aburridas pero hacen toda la diferencia cuando el proyecto empieza a crecer. La mayoría de las personas solo lo piensa cuando ya tiene problemas, y ahí se pone mucho más complicado refactorizar.

Lo que funciona de verdad es separar la lógica de negocio de la interfaz desde el primer día - creas una carpeta `lib` o `core` con funciones puras que no saben nada de React, y después las reutilizas en server components, client components, API routes, todo. La mayoría estructura todo pegado en el componente y después queda atrapado. Otra cosa práctica: si el proyecto va a crecer, ya metes un schema de validación (Zod, Yup, lo que prefieras) en el medio del camino entre la requisición y la base de datos - ahorras toneladas de debug después cuando estás intentando entender por qué un campo llegó undefined en un lugar aleatorio del flujo.

Cuando estructuro un proyecto, lo que realmente funciona es establecer convenciones claras desde el día uno: carpetas por feature dentro de app, pero con una capa de servicios separada para lógica reutilizable. La gente se queda atrapada discutiendo app router versus pages router, pero el problema real aparece después cuando tienes 50 páginas y nadie sabe dónde poner una utilidad de validación. Mi sugerencia es crear un patrón: `app/(features)/[feature]/(routes)/page.tsx`, `lib/services/` para la lógica pesada, y `lib/utils/` para cosas simples. Después invierte tiempo en configurar un `.env` robusto y validación de variables en el arranque de la aplicación, ¡evita arrepentirte en producción!