Un MVP es una inversión para reducir incertidumbre.
El desarrollo de un MVP consiste en construir la versión mínima que permite validar una hipótesis de negocio con usuarios reales. Incluye discovery, diseño de los flujos críticos, desarrollo, instrumentación y lanzamiento, con el fuera de alcance documentado desde el principio.
Última revisión: septiembre 2026
De discovery a lanzamiento
Seis etapas, una demo en cada hito.
- 01
Discovery
Problema, usuario, hipótesis y fuera de alcance por escrito.
- 02
Definición
Flujos, modelo de datos y evento de activación acordado.
- 03
Diseño
UX/UI sobre los flujos críticos, no sobre pantallas decorativas.
- 04
Construcción
Releases por hitos, con demo funcionando en cada uno.
- 05
Instrumentación
Analytics y eventos antes de abrir el producto a usuarios.
- 06
Lanzamiento
Puesta en producción, traspaso y primera lectura de datos.
Gates de aceptación
No arrancamos sin esto.
Cinco condiciones. Existen para proteger el presupuesto del cliente, no para añadir burocracia.
- 01Problema y usuario definidos, con una hipótesis que se pueda falsar.
- 02Owner de producto en el cliente, con capacidad de decidir en 48 horas.
- 03Scope documentado, con el fuera de alcance explícito y firmado.
- 04Evento de activación y plan de analytics definidos antes de construir.
- 05Presupuesto compatible con iterar después del lanzamiento.
Tipos de proyecto
Alcance típico, duración y complejidad relativa.
- MVP web básico
Alcance típico
Landing, auth, panel simple, analyticsDuración
6-8 semanasComplejidad relativa
Baja - MVP SaaS
Alcance típico
Roles, suscripción, panel, integraciones básicas, trackingDuración
10-14 semanasComplejidad relativa
Media - Marketplace MVP
Alcance típico
Doble lado, matching, pagos, moderación, métricas de liquidezDuración
12-16 semanasComplejidad relativa
Media-alta - App móvil MVP
Alcance típico
iOS/Android, notificaciones, analítica de retenciónDuración
12-16 semanasComplejidad relativa
Media-alta - Plataforma compleja
Alcance típico
Arquitectura avanzada, APIs, automatizaciones, IA opcional, hardeningDuración
14-20 semanasComplejidad relativa
Alta
| Tipo de proyecto | Alcance típico | Duración | Complejidad relativa |
|---|---|---|---|
| MVP web básico | Landing, auth, panel simple, analytics | 6-8 semanas | Baja |
| MVP SaaS | Roles, suscripción, panel, integraciones básicas, tracking | 10-14 semanas | Media |
| Marketplace MVP | Doble lado, matching, pagos, moderación, métricas de liquidez | 12-16 semanas | Media-alta |
| App móvil MVP | iOS/Android, notificaciones, analítica de retención | 12-16 semanas | Media-alta |
| Plataforma compleja | Arquitectura avanzada, APIs, automatizaciones, IA opcional, hardening | 14-20 semanas | Alta |
Presupuesto cerrado por hitos tras el discovery de alcance. Pagos vinculados a entregas.
De qué depende el coste
Los factores, no una cifra.
Alcance funcional
Cuántos flujos críticos entran en la primera versión.
Roles y permisos
Cada rol nuevo multiplica estados, pruebas y casos límite.
Integraciones
Pagos, CRM, ERP o APIs externas con su propio mantenimiento.
Requisitos legales
Tratamiento de datos, auditoría o sector regulado.
Volumen previsto
Arquitectura y coste de infraestructura desde el día uno.
Deuda técnica
Qué hay construido y en qué estado llega.
Trabajamos con presupuesto cerrado por hitos y pagos vinculados a entregas. La cifra se fija después del discovery, cuando el alcance está documentado y el fuera de alcance también.
Preguntas frecuentes
Preguntas frecuentes
¿De qué depende el coste de un MVP?
+
Del alcance funcional, del número de roles y permisos, de las integraciones con sistemas externos, de los requisitos legales o de seguridad, del volumen de usuarios previsto y de la deuda técnica heredada. Se presupuesta tras un discovery de alcance y se cierra por hitos.
¿Qué pasa si el alcance cambia a mitad de proyecto?
+
Se documenta el cambio, se estima su impacto en plazo y hitos, y se decide antes de ejecutarlo. Lo habitual es sacrificar una funcionalidad de menor impacto para mantener la fecha de lanzamiento, en lugar de ampliar el proyecto sin control.
¿Quién es el dueño del código?
+
El cliente. El repositorio, la infraestructura y las cuentas de terceros se crean a nombre de la startup desde el primer día. Al cerrar el proyecto se entrega documentación técnica y traspaso, sin dependencias ocultas con nosotros.
¿Construís el MVP y desaparecéis?
+
El presupuesto debe contemplar iteración después del lanzamiento: un MVP sin iteración es un gasto, no una inversión. Muchos proyectos continúan como Growth Cell o como sprints puntuales, pero no es obligatorio.
¿Trabajáis con un product owner nuestro?
+
Sí, y es una condición. Necesitamos una persona en el cliente con capacidad de decidir sobre alcance y prioridades en menos de 48 horas. Sin ese rol, los proyectos se alargan por bloqueos de decisión, no por desarrollo.