Seis semanas no es un eslogan: es una restricción de diseño. Cuando el plazo es fijo, la conversación cambia de «¿qué más podría llevar el producto?» a «¿qué es lo mínimo que demuestra que esto funciona?». Esa segunda pregunta es la que valida negocios.
Así estructuramos nosotros un MVP con plazo cerrado, y —más importante— los criterios para decidir qué entra y qué espera.
Por qué 6 semanas y no 6 meses
Un MVP tiene un único trabajo: producir aprendizaje real con usuarios reales. Cada semana extra de desarrollo antes del primer contacto con usuarios es una semana de hipótesis sin contrastar, pagada a precio de desarrollo.
Con 6 semanas hay tiempo de sobra para un producto digno que haga bien una cosa. No hay tiempo para tres perfiles de usuario, un panel de administración exhaustivo y notificaciones configurables. Esa es exactamente la gracia.
Qué recortar sin miedo
- El segundo caso de uso. Si el producto sirve «para restaurantes y también para clínicas», el MVP es para uno de los dos. El que tenga el dolor más agudo.
- El panel de administración. Las primeras semanas, el administrador eres tú con acceso a la base de datos. Duele menos de lo que parece.
- Configuración y preferencias. Decide tú los valores por defecto. Si los usuarios piden cambiarlos, enhorabuena: ya tienes usuarios que piden cosas.
- Login social, modo oscuro, apps nativas. Todo esto es posterior a la pregunta «¿alguien quiere esto?».
- Integraciones “imprescindibles”. Casi siempre hay una manual que funciona: un CSV, un correo, un Zapier provisional.
Qué no se recorta nunca
Aquí es donde muchos MVPs baratos salen caros:
- El flujo de cobro, si el negocio es cobrar. Validar con un producto gratuito un negocio de pago es validar otro negocio distinto.
- Accesibilidad y rendimiento básicos. No es (solo) ética: formularios etiquetados, contraste correcto y una web rápida convierten mejor, y en la UE ya son terreno regulado.
- Analítica desde el día uno. Si no mides activación y retención desde la primera semana, las 6 semanas no producen aprendizaje: producen software.
- Un despliegue serio. Deploy continuo, dominio real, backups. Cuesta un día al principio y evita perder el fin de semana del lanzamiento.
Las 6 semanas, por dentro
| Semana | Foco |
|---|---|
| 1 | Alcance cerrado, flujo principal en papel, arquitectura y diseño base |
| 2–4 | Construcción del flujo principal, demo cada viernes |
| 5 | Integración, datos reales, pulido del camino crítico |
| 6 | Pruebas, accesibilidad, despliegue y handover |
La demo semanal no es ceremonia: es el mecanismo que impide que el alcance crezca en silencio. Lo que no se enseña un viernes tiende a no existir.
Los errores que más tiempo queman
- Construir para «todos». Un MVP con tres audiencias son tres MVPs mal hechos.
- Perseguir la perfección visual antes del flujo. Primero que se pueda completar la tarea; después, que enamore.
- Tecnología exótica. El stack aburrido y probado te deja concentrar el riesgo donde debe estar: en el negocio.
- No hablar con usuarios durante las 6 semanas. El calendario de desarrollo no pausa el de descubrimiento.
¿Listo para construir?
Señales de que sí: puedes describir a tu primer usuario con nombre y apellidos, sabes qué acción suya validaría la idea, y tienes forma de llegar a 10 como él la semana del lanzamiento.
Si es tu caso, nuestro MVP para startups es exactamente esto: alcance cerrado, 6 semanas, demo cada viernes y código que es tuyo desde el primer día. Cuéntanos tu idea — respondemos en 24 h.