Un proyecto de portafolio demuestra más que un stack: debe dejar claro qué problema resolviste, para quién, qué decisiones tomaste, cuál fue tu responsabilidad y qué evidencia respalda el resultado. La idea puede ser común; lo que importa es el contexto y la calidad de la explicación.
Publiqué una vez una frase demasiado tajante: “un proyecto genérico en tu portafolio no te consigue trabajo”.
La intención era útil; la formulación, no tanto. Una lista de tareas, una aplicación del clima o un clon pueden enseñar fundamentos. El problema no es que la idea exista antes. El problema es presentarla sin una decisión que revele cómo piensas.
Un proyecto deja de ser genérico cuando puedes explicar por qué existe, para quién lo construiste y qué cambió después de ponerlo frente a una restricción real.
¿Por qué el stack no es la historia del proyecto?
Esta descripción dice muy poco:
Aplicación full stack con React, Node.js, PostgreSQL y Docker.
Enumera herramientas, pero no permite evaluar el trabajo. Compárala con esta:
Sistema de reservas para una academia pequeña. Impide cruces de horario, permite cancelar hasta seis horas antes y conserva una lista de espera cuando se libera un cupo.
Ahora aparecen reglas, usuarios y decisiones. El stack puede venir después como evidencia de implementación.
¿Qué debe responder una buena página de proyecto?
1. ¿Cuál era el contexto?
“Necesitaban una web” no basta. Explica la situación observable.
- ¿La información estaba dispersa?
- ¿El proceso dependía de una hoja de cálculo?
- ¿Las consultas llegaban sin datos suficientes?
- ¿La tarea se repetía de forma manual?
- ¿La persona usaba el producto desde un teléfono y con mala conexión?
El contexto demuestra que miraste antes de construir.
2. ¿Quién tenía el problema?
No escribas “usuarios” cuando puedes decir “instructores que toman asistencia al comenzar una clase” o “productores que consultan servicios desde el campo”.
Una persona concreta obliga a priorizar. Si el producto sirve para cualquiera, suele estar diseñado para nadie.
3. ¿Qué decisión fue difícil?
La parte más valiosa rara vez es instalar el framework. Puede ser:
- dejar una función fuera del primer alcance;
- modelar una regla que tenía excepciones;
- elegir contenido estático en lugar de una SPA;
- degradar una interacción cuando no hay conexión;
- diseñar permisos entre roles;
- reemplazar una animación por una interfaz más accesible.
Una decisión incluye alternativas y costo. “Usé React porque es moderno” es una preferencia, no una decisión argumentada.
4. ¿Qué hiciste tú?
En proyectos de equipo, especifica tu contribución sin apropiarte de todo el resultado. Evita porcentajes imposibles de verificar como “hice el 80 %”. Describe entregables:
- definí el modelo de navegación;
- implementé el flujo de autenticación;
- diseñé los componentes del directorio;
- integré el CMS;
- escribí las pruebas del caso de uso.
La precisión genera más confianza que un título inflado.
5. ¿Cuál es el estado real?
Distingue entre:
- concepto;
- prototipo navegable;
- MVP en validación;
- producto en producción;
- proyecto pausado.
Una interfaz con datos simulados puede ser un excelente prototipo. Pierde valor cuando la describes como una plataforma “empresarial en tiempo real” que todavía no existe.
6. ¿Qué evidencia tienes?
La evidencia puede ser cuantitativa, pero no tiene que inventar métricas:
- enlace al producto;
- repositorio y commits;
- pruebas automatizadas;
- auditoría reproducible;
- capturas del flujo;
- comentarios de una prueba con usuarios;
- antes y después de un proceso;
- incidencias encontradas y resueltas.
Si afirmas “99 en Lighthouse”, enlaza o documenta condiciones y fecha. Si no puedes reproducir el número, explica las decisiones de rendimiento sin convertirlas en marcador publicitario.
¿Cómo transformar cinco proyectos comunes en casos de estudio?
Lista de tareas → coordinación con reglas
No agregues categorías solo para tener más funciones. Elige un contexto: tareas de una casa compartida, mantenimiento de equipos o entregas universitarias. Modela responsables, fechas, repetición y conflictos.
Clima → decisión bajo incertidumbre
En vez de mostrar temperatura, ayuda a una persona a decidir: alertas de heladas para cultivos, condiciones para entrenar o recomendaciones de equipamiento. Diseña estados de API caída, ubicación rechazada y datos desactualizados.
Clon de red social → un mecanismo aislado
No copies toda la interfaz. Profundiza en una parte: moderación, accesibilidad del feed, carga progresiva, relaciones de seguimiento o protección contra abuso.
E-commerce → operación real
Un catálogo visual es un inicio. Añade reglas de stock, variantes, reserva, costo de envío o conciliación de pagos. Si no puedes procesar pagos reales, documenta el límite.
Chat → comunicación confiable
Trabaja estados difíciles: mensajes pendientes, reconexión, orden, duplicados, bloqueo y reporte. “Tiempo real” importa menos que saber qué ocurre cuando deja de serlo.
¿Dónde encontrar un proyecto real para tu portafolio?
Cuando aconsejé reemplazar un clon por la web de un negocio local, la idea no era trabajar gratis. Era encontrar problemas con contexto verificable.
También puedes construir para:
- una organización estudiantil;
- un club deportivo;
- un familiar que repite una tarea;
- tu propia rutina;
- una comunidad open source;
- un conjunto de datos público.
Define alcance, propiedad del código, privacidad y expectativas antes de empezar. “Real” no significa aceptar requisitos ilimitados ni regalar mantenimiento permanente.
¿Qué plantilla usar para escribir un caso de estudio?
## En una frase
Qué cambió y para quién.
## Contexto
Cómo funcionaba antes y qué fricción observé.
## Mi responsabilidad
Qué diseñé, implementé y validé.
## Restricciones
Tiempo, datos, dispositivos, conectividad o alcance.
## Decisiones
Alternativas consideradas y por qué elegí una.
## Resultado
Evidencia disponible, sin atribuir causalidad que no medí.
## Límites
Qué usa datos simulados, qué falta y qué no pertenece al MVP.
## Siguiente paso
La prueba de mayor riesgo que haría después.Esta estructura funciona incluso para un proyecto pequeño. Por ejemplo, ITF App muestra cómo acotar un prototipo y Riego Mendoza muestra cómo convertir un servicio técnico en un recorrido de contacto. Si no puedes completar la plantilla, te muestra qué parte del proyecto todavía necesita pensamiento.
¿Qué señales restan credibilidad?
Adjetivos sin demostración
“Revolucionario”, “enterprise-grade”, “ultrarrápido” y “escalable” no describen comportamiento. Sustitúyelos por decisiones o mediciones.
Resultados causales sin datos
Un botón de WhatsApp no “aumenta conversiones” por existir. Puedes decir que reduce pasos para iniciar contacto. El aumento requiere comparación y datos.
Arquitectura futura escrita en pasado
No presentes WebSockets, colas, Redis o modelos de IA como implementados si siguen en el roadmap. Un apartado honesto de próximos pasos demuestra criterio de alcance.
Capturas sin recorrido
Una imagen bonita prueba diseño visual. No explica qué ocurre antes, después o cuando algo falla. Acompáñala con el flujo principal.
Cinco proyectos con la misma descripción
Si todas las páginas dicen “diseñé una interfaz moderna, responsive y optimizada”, el lector no aprende nada específico sobre ninguna.
¿Qué evalúo ahora en mis propios proyectos?
Después de revisar mi portafolio, uso este control:
- La primera frase explica un resultado, no un stack.
- El usuario y su contexto son concretos.
- Mi responsabilidad está delimitada.
- Existe al menos una decisión con trade-off.
- El estado coincide con el código actual.
- Las métricas tienen evidencia o fueron eliminadas.
- Los límites están visibles.
- El siguiente paso valida riesgo, no solo agrega funciones.
¿La idea de un proyecto tiene que ser original?
Miles de personas pueden construir una lista de tareas. Muy pocas observarán el mismo entorno, elegirán las mismas restricciones, hablarán con las mismas personas y explicarán las decisiones con la misma honestidad.
Tu portafolio no necesita fingir que cada repositorio es una startup global. Necesita demostrar que puedes mirar un problema, reducirlo a un alcance razonable, construir una solución y aprender de lo que todavía no funciona.
Eso es mucho más difícil —y mucho más memorable— que elegir una idea que nadie haya escrito antes.