Cómo estructurar un proyecto frontend sin perderte en el camino

Cuando empiezas en frontend, una de las dudas más comunes no es solo qué tecnología usar, sino cómo organizar el proyecto para que no se vuelva un caos después de unas semanas.

La realidad es que no existe una única estructura perfecta. Pero sí hay una regla bastante útil: si el proyecto está ordenado, será más fácil de mantener, escalar y entender, tanto para ti como para cualquier otra persona que toque el código.

¿Por qué importa tanto la estructura?

Al principio, casi cualquier proyecto parece manejable. Tienes pocas pantallas, algunos componentes y un par de estilos. El problema llega cuando empiezas a crecer:

• aparecen más vistas,

• repites lógica,

• no recuerdas dónde está cada archivo,

• y mover algo pequeño termina rompiendo varias cosas.

Una buena estructura no evita todos los problemas, pero sí reduce mucho la fricción del día a día.

El error más común al empezar

Muchos developers junior organizan el proyecto “como vaya saliendo”. Eso suele terminar en cosas como:

• componentes mezclados con utilidades,

• archivos con nombres poco claros,

• estilos repartidos sin criterio,

• lógica de negocio dentro de la UI,

• y carpetas que crecen sin ninguna regla.

No pasa por falta de capacidad. Pasa porque al inicio nadie te enseña que ordenar también es parte de programar bien.

Una estructura simple y útil para empezar

Si estás trabajando con React, Next.js o incluso proyectos similares, una base bastante clara podría ser esta: src/ components/ ui/ layout/ features/ pages/ hooks/ services/ utils/ styles/ types/

¿Qué va en cada carpeta?

components/

Aquí van los componentes reutilizables de la interfaz.

• ui/: botones, inputs, cards, modales.

• layout/: navbar, footer, sidebar, wrappers.

• features/: componentes ligados a una funcionalidad concreta, como login o buscador.

pages/ o app/

Las vistas principales o rutas del proyecto.

Ejemplo:

• Home

• About

• Dashboard

• Blog

hooks/

Custom hooks como:

• useTheme

• useFetch

• useDebounce

Esto ayuda a separar lógica reutilizable de la UI.

services/

Funciones para consumir APIs o conectarte con servicios externos.

Ejemplo:

• getUsers.ts

• authService.ts

• postsService.ts

utils/

Helpers pequeños y reutilizables.

Ejemplo:

• formatear fechas,

• validar emails,

• transformar texto.

styles/

Estilos globales, variables, mixins o temas.

types/

Interfaces y tipos de TypeScript que se comparten en varias partes del proyecto.

Una regla clave: agrupa por responsabilidad

Una buena pregunta para decidir dónde va un archivo es esta:

¿Cuál es la responsabilidad principal de esto?

Si renderiza UI, probablemente va en components. Si hace una petición HTTP, probablemente va en services. Si transforma datos, seguramente va en utils.

Parece obvio, pero este criterio evita muchas carpetas “misc” o archivos mal ubicados.

Intenta que cada archivo tenga una sola intención

Otro error muy común es crear componentes o archivos que hacen demasiadas cosas al mismo tiempo.

Por ejemplo, un componente que:

• renderiza la interfaz,

• llama a la API,

• transforma datos,

• maneja validaciones,

• y además contiene estilos complejos,

termina siendo difícil de leer y mantener.

Lo ideal es separar responsabilidades:

• UI por un lado,

• lógica por otro,

• acceso a datos por otro.

Nombres claros > nombres “creativos”

La estructura también depende mucho de cómo nombras las cosas.

Malos ejemplos:

• data.ts

• helpers.ts

• componentFinal.tsx

• newCode.ts

Mejores ejemplos:

• formatDate.ts

• LoginForm.tsx

• getUserProfile.ts

• SidebarLayout.tsx

Si el nombre explica bien qué hace el archivo, ya estás mejorando la mantenibilidad.

No sobrearquitectures demasiado pronto

Este punto es importante: ordenar no significa complicar.

A veces, por querer “hacerlo profesional”, se crean demasiadas capas, carpetas o patrones desde el inicio. Y para un proyecto pequeño eso puede ser innecesario.

Empieza con una estructura simple. Luego, cuando el proyecto crezca, refactoriza con criterio.

Señales de que tu proyecto necesita reorganización

Estas pistas suelen indicar que hace falta mejorar la estructura:

• tardas demasiado en encontrar archivos,

• duplicas lógica en varias partes,

• un componente supera fácilmente las 200 líneas sin razón clara,

• hay carpetas llenas de archivos sin relación entre sí,

• mover o cambiar algo pequeño cuesta demasiado.

Si te pasa esto, no significa que estés haciendo todo mal. Significa que el proyecto ya te está pidiendo más orden.

Una recomendación práctica para juniors

Si todavía no tienes mucha experiencia, usa esta idea como guía:

1. separa UI, lógica y datos

2. pon nombres descriptivos

3. evita carpetas genéricas

4. mantén consistencia

5. refactoriza cuando el crecimiento lo pida

No necesitas una arquitectura enorme para trabajar mejor. Muchas veces, con una estructura simple pero coherente, ya mejoras muchísimo.

Conclusión

Estructurar un proyecto frontend no se trata de seguir una moda ni copiar la carpeta de otro repo. Se trata de crear un sistema que te permita entender, mantener y escalar el código sin sufrir cada cambio.

Si eres frontend junior, esta es una muy buena habilidad para desarrollar pronto. Porque no solo mejora tu código: también mejora tu forma de pensar como developer.