BETTUn MVP (producto mínimo viable) no es una versión incompleta de tu producto final — es la versión más pequeña que te permite validar si alguien lo va a usar. La mayoría de los proyectos que se alargan más de 8 semanas fallan por una razón: intentan resolver demasiado antes de saber si vale la pena resolverlo.
Semana 1-2: Descubrimiento y alcance
Antes de escribir código, definimos tres cosas: la funcionalidad núcleo (la única razón por la que alguien usaría el producto), lo que queda explícitamente fuera, y cómo se va a medir el éxito. Si no puedes escribir la funcionalidad núcleo en una sola oración, el alcance todavía no está listo.
- Un flujo de usuario, no cinco. Elige el camino más corto entre el problema y la solución.
- Define qué "funcional" significa antes de construir — no después.
- Documenta lo que decides NO construir. Es tan importante como lo que sí.
Semana 3-5: Construcción del núcleo
Aquí es donde el stack importa. Para la mayoría de los MVPs web recomendamos generadores estáticos o frameworks ligeros con renderizado del lado del servidor solo donde se necesita — no arquitecturas de microservicios para un producto que todavía no tiene un solo usuario. La regla: la complejidad técnica debe ser proporcional a la certeza que tienes sobre el problema.
Trabajamos en sprints de una semana con una demo funcional al final de cada uno. Si algo no se puede demostrar, no cuenta como terminado.
Semana 6-7: Pulido y casos límite
Esta fase suele subestimarse. Manejo de errores, estados vacíos, validación de formularios y rendimiento en conexiones lentas no son "extras" — son la diferencia entre un MVP que alguien puede usar sin ayuda y uno que solo funciona en la demo.
Semana 8: Lanzamiento controlado
Lanzar a un grupo pequeño y real antes que a todo el mundo. Instrumenta el producto para saber qué hacen los usuarios, no solo qué dicen que van a hacer. Esa data es la que decide si el proyecto pasa de MVP a producto.
Errores comunes que alargan el plazo
- Agregar autenticación, roles y permisos completos cuando un acceso simple bastaría para validar.
- Diseñar para escala antes de tener el primer usuario real.
- Cambiar el alcance a mitad de sprint sin ajustar el plazo.
Un MVP bien ejecutado no se siente incompleto — se siente enfocado. Ese es el objetivo de las 8 semanas: no construir menos por construir menos, sino construir exactamente lo necesario para tomar la siguiente decisión con datos reales.