🎯 Qué construyes: algo que tú decides, que resuelve un problema real (empezando por el tuyo), desplegado y usado por al menos cinco personas que no seas tú.
Prerrequisitos: todo el libro. Duración: 2-3 meses a tiempo parcial.
🧠 Por qué este proyecto vale más que los cuatro anteriores juntos. En P1-P4 los requisitos te los daban. Aquí los defines tú, y esa es la parte difícil de verdad. Además es el único proyecto con usuarios, y los usuarios hacen cosas que ningún test se te habría ocurrido escribir.
Elegir bien: la parte que más determina el resultado
✅ BUEN PROYECTO ❌ MAL PROYECTO
Resuelve un problema TUYO real "Una red social pero mejor"
Lo usarías aunque no lo hubieras hecho Nadie lo pidió, ni tú
Un caso de uso central claro Doce funcionalidades, ninguna terminada
Se puede lanzar algo útil en 3 semanas El MVP tarda 6 meses
Puedes conseguir 5 usuarios que conoces No sabes a quién se lo enseñarías
Tiene alguna parte técnicamente rica CRUD puro, sin ningún retoTres preguntas para validar tu idea antes de empezar:
- ¿Puedes describirlo en una frase? "Una app donde los grupos de escalada organizan salidas y coordinan quién lleva el material." Si necesitas un párrafo, el alcance está sin definir.
- ¿Quiénes son tus cinco primeros usuarios y cómo se llaman? Si no puedes nombrarlos, no tienes un producto: tienes un ejercicio. (Lo cual está bien — pero sé consciente.)
- ¿Qué es lo mínimo que ya sería útil? Esa es tu versión 1, y casi siempre es más pequeña de lo que crees.
💡 Ideas que funcionan bien como P5, si no tienes una: un gestor de gastos compartidos para tu grupo; una herramienta interna para el trabajo de alguien cercano (una peluquería, un gimnasio, un profesor particular); un agregador de algo que sigues manualmente; un panel para un hobby que llevas en una hoja de cálculo. Lo que empieza como una hoja de cálculo que alguien odia mantener es casi siempre un buen producto.
Reglas del proyecto
R1 · Escribe primero un documento de diseño (capítulo 25), antes de código. Problema, objetivos, no objetivos, propuesta, riesgos y cómo sabrás si funcionó.
R2 · Despliega en la primera semana. Aunque solo diga "próximamente". El despliegue deja de ser un evento aterrador y pasa a ser rutina.
R3 · Rebanadas verticales. Cada semana algo que un usuario pueda usar de punta a punta.
R4 · Consigue usuarios en la semana 4, no en la 12. Con la mitad de las funcionalidades. Su feedback va a cambiar tu plan, y es mejor que lo cambie pronto.
R5 · Mantén un registro de decisiones (ADRs). Al final tendrás el mejor material posible para explicar tu trabajo en una entrevista.
R6 · Mide algo. Aunque sea cuántas personas entran y cuántas vuelven. Un producto sin métricas es una opinión.
R7 · Termínalo. Un proyecto pequeño terminado y usado vale infinitamente más en un portfolio que uno ambicioso al 70%.
Calendario orientativo (12 semanas)
| Semanas | Objetivo | Entregable |
|---|---|---|
| 1 | Definir y desplegar el esqueleto | Documento de diseño + URL viva + CI/CD |
| 2-3 | La rebanada vertical central | El caso de uso principal funcionando |
| 4 | 👥 Primeros usuarios | 5 personas usándolo + lista de feedback |
| 5-7 | Construir según lo aprendido | Las funcionalidades que pidieron, no las que imaginaste |
| 8 | Endurecer | Seguridad, casos límite, manejo de errores, rate limiting |
| 9 | Calidad | Tests, refactor de lo que más duele, cobertura razonable |
| 10 | Producción de verdad | Observabilidad, alertas, backups probados, coste bajo control |
| 11 | Pulido | Rendimiento, accesibilidad, textos, primera experiencia de uso |
| 12 | Cierre | README, ADRs, post-mortem personal, plan de futuro |
Lo que la gente descubre en la semana 4 (prepárate)
- Nadie usa la funcionalidad de la que estabas más orgulloso. Duele y es la lección más valiosa del proyecto.
- La primera experiencia de uso es lo que decide todo. Si alguien no entiende qué hacer en los primeros 30 segundos, se va y no vuelve, por bueno que sea tu backend.
- Los usuarios introducen datos imposibles. Nombres con emojis, textos de 40.000 caracteres, fechas del año 1900, el mismo formulario enviado once veces.
- Alguien intentará romperlo. A veces por curiosidad, a veces no. Si tienes un formulario público, recibirás spam en la primera semana.
- El coste importa. Descubrirás qué te cuesta de verdad servir vídeo, enviar emails o mantener una base de datos gestionada encendida 24/7.
Checklist de "listo para usuarios reales"
SEGURIDAD
□ HTTPS obligatorio, con redirección desde HTTP
□ Contraseñas hasheadas (bcrypt/argon2); nunca en logs
□ Consultas parametrizadas en todas partes
□ Autorización comprobada por recurso, no solo autenticación
□ Rate limiting en login, registro y recuperación de contraseña
□ Secretos fuera del repositorio; rotables
□ Cabeceras de seguridad (CSP, HSTS, X-Content-Type-Options)
□ Validación de subidas por contenido real, no por extensión
DATOS
□ Backups automáticos diarios
□ Restauración PROBADA en una base limpia (no "supongo que funciona")
□ Migraciones versionadas y reversibles
□ Política de borrado de cuenta y datos (RGPD si tienes usuarios europeos)
OPERACIÓN
□ Healthcheck y alerta si se cae
□ Logs estructurados con id de correlación
□ Sabes cuánto te cuesta al mes y tienes un tope
□ Puedes revertir un despliegue en menos de 5 minutos
□ Página de error decente (no un stack trace)
PRODUCTO
□ Alguien que no eres tú lo usó sin que le explicaras nada
□ Hay una forma de contactarte cuando algo falla
□ Sabes cuántos usuarios activos tienesEl cierre: post-mortem personal
Al terminar, escribe un documento honesto de una página. Es la parte que más te va a servir:
## Qué construí y para quién
## Qué funcionó
## Qué NO funcionó (sé específico y honesto)
## Las 3 decisiones técnicas de las que más orgulloso estoy, y por qué
## Las 3 que cambiaría, y qué haría en su lugar
## Lo que aprendí que NO esperaba aprender
## Qué haría diferente si empezara mañana🧠 En una entrevista, este documento vale más que tu repositorio. Cualquiera puede enseñar código que funciona. Muy poca gente puede explicar con precisión por qué tomó cada decisión, qué salió mal y qué aprendió. Eso es lo que se busca cuando se contrata a alguien para tomar decisiones.
🎓 Y ahora qué
Has terminado el libro. El siguiente paso ya no está aquí dentro:
- Lee código ajeno. Elige un proyecto open source que uses y entiende cómo está construido. Aprender a leer código es una habilidad distinta de aprender a escribirlo, y se entrena aparte.
- Contribuye. Empieza por documentación o por un bug pequeño. La primera vez que alguien revisa tu código en un proyecto real enseña más que un mes de tutoriales.
- Escribe sobre lo que aprendes. Explicar es la forma más eficaz de descubrir lo que no habías entendido del todo.
- Profundiza en una cosa. Ya conoces mucha superficie. Elige un tema (bases de datos, sistemas distribuidos, seguridad, rendimiento) y baja un nivel más.
La última idea del libro: las tecnologías de estas páginas habrán cambiado en cinco años. Los frameworks, las versiones y las herramientas caducan. Lo que no caduca es saber hacer las preguntas correctas, entender los trade-offs, medir antes de decidir y escribir para quien viene detrás. Eso es lo que has venido a aprender aquí; el resto era el vehículo.