Cómo estructuro un proyecto Next.js para que escale

La estructura de un proyecto Next.js importa más de lo que parece. Cuando el proyecto tiene tres páginas, cualquier estructura funciona. Cuando tiene veinte componentes, cinco rutas dinámicas y tres integraciones externas, una mala estructura te frena cada vez que tocas algo.

Esta es la estructura que uso en producción y por qué cada decisión existe.

La regla de oro: colocalización

Cada archivo debe vivir lo más cerca posible de donde se usa. Si un componente solo se usa en una página, va junto a esa página. Si se comparte entre varias, sube a components. Si es un util puro, va a lib.

La colocalización reduce la fricción cognitiva: cuando abres una carpeta, ves todo lo que esa feature necesita. No saltas entre carpetas para entender un flujo.

Estructura base

`` app/ → Rutas y layouts (App Router) components/ layout/ → Header, Footer, Navigation sections/ → Secciones de página (Hero, Services, Contact) ui/ → Componentes reutilizables (Button, Card, Reveal) providers/ → Context providers (Theme, Auth) data/ → Datos estáticos y configuración lib/ → Utilidades puras y helpers public/ → Assets estáticos ``

app/ — solo rutas y layouts

El directorio app en Next.js App Router tiene una responsabilidad: definir rutas. Cada carpeta es una ruta, cada page.tsx es un punto de entrada. No pongo lógica de negocio ni componentes complejos aquí.

El layout.tsx raíz define la estructura global: fonts, providers, metadata, JSON-LD. Cada sub-layout puede añadir su propia metadata y estructura.

components/ — tres niveles claros

layout/: componentes estructurales que aparecen en todas las páginas. Header, Footer, y poco más. Si un componente es parte del chrome del sitio, va aquí.

sections/: bloques de contenido de una página. Hero, About, Services, Contact. Cada uno es un componente server-first que recibe datos y renderiza. Son específicos de la página principal pero están separados para mantener page.tsx limpio.

ui/: componentes reutilizables sin lógica de negocio. Button, Card, SectionTitle, Reveal. Son los building blocks que combinan las sections.

data/ — single source of truth

Toda la configuración y datos estáticos viven en data/. Sitio, posts, proyectos, experiencia, skills. Cada archivo exporta constantes tipadas que consumen los componentes.

La ventaja: cuando el cliente dice 'cambia mi email', voy a data/site.ts y lo cambio en un lugar. No busco en templates.

lib/ — utilidades puras

Funciones sin estado, sin side effects, sin dependencias de React. cn() para clases condicionales, formatters, validaciones. Si necesita useState o useEffect, no es un util, es un componente.

Convenciones de naming

• Componentes en PascalCase: Header.tsx, SectionTitle.tsx.
• Datos y utils en camelCase: site.ts, utils.ts.
• Slugs y rutas en kebab-case: web-negocio-familiar-nextjs.
• Un export por archivo para componentes. Facilita tree-shaking y búsqueda.

Conclusión

La mejor estructura es la que no te hace pensar dónde va cada cosa. Si cada vez que creas un archivo dudas entre tres carpetas, la estructura está fallando. Las reglas son simples: colocalizar, separar por responsabilidad y ser consistente. El proyecto crece y la estructura sigue funcionando.