El portafolio backend tiene un desafío fundamental: el trabajo no es visual. No puedes mostrar screenshots bonitos de lo que construiste. Tienes que demostrar competencia de otra manera.
Esta guía explica cómo hacerlo bien.
Por qué el portafolio backend es diferente
Un frontend muestra interfaces. Un backend muestra lógica, estructura de código, decisiones de arquitectura y documentación. El evaluador (cliente o empleador) tiene que entrar al repositorio y ver evidencia de que sabes lo que haces.
Eso significa que el GitHub de un dev backend es su portafolio principal, no un sitio web con screenshots.
Qué proyectos incluir
Proyecto 1: API REST completa
El proyecto indispensable. Debe incluir:
- Endpoints bien organizados y documentados
- Autenticación con JWT o sesiones
- Base de datos relacional (PostgreSQL preferido)
- Manejo de errores consistente
- Variables de entorno correctamente configuradas
- Deploy en producción (Railway, Render, o similar)
El tema del proyecto no importa tanto como la calidad de implementación. Puede ser una API de gestión de tareas, de usuarios, de productos. Lo que evaluarán: estructura del código, seguridad básica, manejo de errores, documentación.
Proyecto 2: Algo que uses realmente
Un script, herramienta o API que resuelve un problema tuyo real tiene más peso que proyectos de tutorial. Puede ser simple: un bot que te notifica algo, un script que automatiza algo que hacías manual, una API que alimenta una app que usas.
La autenticidad del caso de uso comunica criterio y capacidad de resolver problemas reales.
Proyecto 3: Algo más complejo (para semi-senior+)
Para perfiles que aspiran a roles intermedios o senior, un tercer proyecto que demuestre manejo de casos más complejos:
- Procesamiento asíncrono con colas (BullMQ, RabbitMQ)
- Integración con servicios externos (pagos, email, storage)
- Optimización de queries en base de datos
- Testing automatizado con cobertura razonable
La documentación es parte del portafolio
Un proyecto backend sin README bien escrito se ve amateur. El README debe incluir:
- Qué hace — descripción de 2-3 líneas del propósito
- Stack técnico — lenguaje, framework, base de datos
- Cómo instalarlo y ejecutarlo localmente — comandos específicos
- Variables de entorno necesarias — con ejemplo (
.env.example) - Endpoints disponibles — con ejemplos de request/response
- Cómo probarlo — comandos de test si existen
Si el README hace que el evaluador pueda levantar el proyecto en 5 minutos, ya ganaste puntos.
La documentación de API (Swagger / OpenAPI)
Para proyectos que exponen API, tener documentación Swagger interactiva es un diferenciador significativo. En Node.js con Fastify o Express es relativamente simple de agregar. El evaluador puede ver y probar los endpoints sin leer el código.
En producción, exponer /docs con Swagger demuestra pensamiento de producto real, no solo código que “funciona en mi máquina”.
GitHub: el portafolio real del backend
Tu perfil de GitHub comunica más que cualquier sitio web de portafolio:
- Actividad consistente — commits regulares en el tiempo (no un burst de actividad y 6 meses de silencio)
- Código legible — nombres de variables claros, funciones pequeñas, comentarios donde son necesarios
- Historial de commits descriptivo — “fix auth middleware” dice más que “fix”
- Proyectos públicos bien estructurados — carpetas organizadas, separación de concerns
El sitio web de portafolio (sí o no)
Para backend puro, un sitio web de portafolio es menos crítico que para frontend. Lo que sí vale la pena tener:
- LinkedIn actualizado con stack y proyectos
- GitHub con README bien escrito en cada proyecto
- Opcionalmente: una página simple (hasta puede ser una página de Notion pública) que lista tus proyectos con links y una descripción de lo que puedes hacer
No necesitas un sitio web espectacular. Necesitas evidencia de que tu código es bueno.
El proyecto que más impresiona en entrevistas técnicas
Según devs que han pasado por muchas entrevistas: el proyecto que más impresiona es el que tiene testing. Tests unitarios y de integración bien escritos demuestran que entiendes cómo funciona tu código, no solo que funciona “en este momento”.
Agregar una suite básica de tests a tu proyecto principal es una inversión que vale mucho más que el tiempo que toma.
| Elemento del portafolio | Impacto en evaluación |
|---|---|
| GitHub activo con commits regulares | Alto |
| README claro y completo | Alto |
| Deploy en producción accesible | Alto |
| Documentación Swagger | Medio-Alto |
| Tests automatizados | Alto (diferenciador) |
| Sitio web de portafolio | Bajo-Medio para backend puro |
Si tienes un proyecto en GitHub que quieres que alguien revise antes de mandarlo como parte de tu portafolio, en el foro de Nomadaz hay devs que hacen code review informal entre la comunidad. Una segunda opinión antes de mandarlo a un cliente o empleador puede salvar situaciones embarazosas.