Doce semanas son tiempo suficiente para construir un producto real — y lo bastante cortas como para no poder desperdiciar ni una. La diferencia entre un MVP que sobrevive a su ronda seed y uno que se hunde con los primeros 1.000 usuarios casi nunca es el framework. Son las decisiones que tomas en la primera semana.
Semana 1–2: alcance, no funcionalidades
La primera tentación es listar features. Nosotros hacemos lo contrario: escribimos la única cosa que el producto debe demostrar. Todo lo que no sirva a esa demostración se aparca, no se borra — se aparca.
Un MVP no es un producto más pequeño. Es el experimento honesto más pequeño posible.
Semana 3–8: construir sobre una espina que escala
Elegimos una arquitectura opinada desde el commit cero — auth, pagos, jobs en segundo plano, observabilidad. No porque el MVP necesite todo el día uno, sino porque incorporarlos después del product-market fit es donde los equipos pierden un trimestre.
- Decisiones aburridas en la base de datos, decisiones emocionantes en el producto.
- Feature flags desde el inicio, para que la demo nunca bloquee un deploy.
- Un entorno que refleje producción, aunque sea diminuto.
Semana 9–12: instrumentar y endurecer
El último mes va de confianza. Añadimos tracing, montamos los dashboards que los fundadores van a mirar de verdad, y ejecutamos los flujos como lo haría un usuario real. El pulido ocurre aquí — no antes, cuando habría sido adivinar.
Si no tienes claro si tu producto aguanta la conversación con un inversor, haz el test «¿listo para la ronda?»: te marca dónde estás sólido y dónde te toca apretar antes de la seed.
Si tienes 12 semanas por delante y quieres un segundo par de ojos sobre el plan, hablemos. Una hora de discovery puede ahorrarte un semestre.