GUÍA / Empleabilidad
Cómo crear un portfolio para desarrollador frontend
Aprende qué debe mostrar un portfolio de desarrollador frontend, cómo presentar proyectos, GitHub, README, deploy y decisiones técnicas.
Introducción: evidencia además de diseño
Un portfolio permite entender qué construiste, cómo lo hiciste y qué puedes explicar. La apariencia ayuda a navegar, pero una captura no demuestra cómo funciona una aplicación. Prioriza proyectos accesibles, repositorios legibles y decisiones concretas; no presentes una colección de tecnologías sin contexto.
Qué aprender y qué preparar
Vas a convertir un proyecto en un caso que otra persona pueda revisar. Necesitas un repositorio que puedas compartir, una versión ejecutable y permiso para publicar el material. Si el proyecto usa datos privados, prepara una demostración con datos ficticios claramente identificados y sin credenciales.
Selecciona de dos a cuatro proyectos
Como criterio editorial, dos a cuatro proyectos bien explicados permiten profundizar más que una lista extensa de ejercicios incompletos. Elige trabajos con responsabilidades distintas: formularios, consumo de API o una interfaz responsive. No es un requisito universal ni una garantía de contratación; conserva solo lo que puedas mantener y defender.
Describe problema, alcance y stack
Para cada proyecto explica quién lo usaría, qué tarea resuelve y qué quedó fuera. Enumera el stack junto con su función: React para componentes, TypeScript para contratos internos, CSS para layout. Evita justificar una herramienta únicamente porque es popular. En un trabajo grupal distingue tu contribución del resultado del equipo.
Ejemplo de caso técnico
En un catálogo de productos, presenta búsqueda, estados de red y detalle del producto. Explica por qué separaste el servicio HTTP, cómo manejaste respuestas vacías y qué prueba comprueba el filtrado. Añade una limitación real, como ausencia de autenticación. Una decisión con sus costes es más útil que afirmar que la arquitectura es perfecta.
Repositorio, README y deploy
Incluye enlaces visibles al código y a la aplicación. El README debe explicar instalación, comandos, variables necesarias sin secretos, pruebas y limitaciones. Usa capturas legibles con contexto. Abre el deploy en una ventana sin sesión: revisa carga, rutas directas y navegación móvil. Si requiere acceso de demostración, publica solo credenciales creadas para ese entorno y sin privilegios sensibles.
Historial de commits y Pull Requests
Un historial comprensible ayuda a seguir cómo evolucionó el proyecto. Si trabajaste con revisión, enlaza un PR que muestre una mejora y explica qué aprendiste. No fabriques conversaciones ni participantes. En un proyecto individual también puedes usar PR para revisar tu propio diff, identificándolo como tal.
Qué evitar y buenas prácticas
No conviertas proyectos académicos en empleos falsos ni atribuyas trabajo ajeno como propio. Identifica tutoriales y contribuciones externas, y explica lo que añadiste. Evita enlaces rotos, pantallas que ocultan fallos y cifras de impacto sin evidencia. No publiques datos de clientes, tokens ni código que no tengas autorización para compartir.
Qué practicar después
Pide a otra persona que abra el portfolio, entienda un proyecto y lo ejecute con el README. Registra dudas, corrige instrucciones y comprueba enlaces. Añade una breve explicación de una decisión técnica y ensaya contarla sin leer el código. Mantén una lista de mejoras pendientes en el repositorio.