¿Cuánto tarda construir un MVP?

Define qué significa terminar antes de estimar

Un MVP no es una cantidad fija de pantallas ni el primer build que puede desplegarse. Describe el usuario, el problema, el resultado acotado y el recorrido completo que debe funcionar. Incluye qué ocurre con una entrada no válida, un acceso denegado o una dependencia caída. Después define qué evidencia permitirá continuar, cambiar de dirección o detenerse. Sin esta frontera, dos equipos pueden usar la misma etiqueta MVP mientras calculan productos completamente distintos.

Separa prototipo, experimento técnico interno y producto que utilizarán personas reales. Un prototipo puede probar texto o interacción sin datos de producción. Un experimento técnico puede reducir incertidumbre sobre una integración. Un MVP publicado puede necesitar también identidad, permisos, recuperación de datos, soporte, observabilidad, privacidad y un responsable operativo. La pregunta temporal solo se vuelve tratable cuando el equipo acuerda cuál de esos estados pretende alcanzar.

Mapea alcance, incertidumbre y dependencias externas

Crea un mapa del recorrido principal, los datos, las reglas de negocio, las integraciones y las responsabilidades operativas. Marca cada elemento incierto en lugar de ocultarlo dentro de una estimación general. Una interfaz conocida sobre datos controlados no equivale a un producto que depende de un sistema heredado sin documentación, un pago nuevo o la aprobación de un proveedor. El mapa debe indicar quién responde cada pregunta y cuándo se necesita la respuesta.

Clasifica el trabajo como conocido, investigable o controlado externamente. Lo conocido puede estimarse desde la implementación y los criterios de aceptación. Lo investigable necesita una prueba acotada antes de ganar precisión. Lo externo necesita propietario, alternativa y una declaración de que el proveedor controla el resultado. Así se evita que una fecha asuma en silencio credenciales, revisión jurídica, contenido, datos o aprobación de una plataforma disponibles de inmediato.

Estima mediante hitos de evidencia

Organiza una secuencia de decisiones. Aprueba primero el brief y lo que queda fuera. Prueba después la hipótesis de producto o técnica con mayor riesgo mediante el artefacto mínimo adecuado. Estima entonces el recorrido vertical con lo aprendido. Antes de publicar, verifica los requisitos de calidad y operación acordados. Cada hito debe nombrar entregable, evidencia de aceptación, responsable de la decisión y posibles salidas.

Expón el nivel de confianza de la previsión. Enumera los supuestos capaces de cambiar el alcance o el orden y decide cuándo se revisará el plan. La información nueva no es por sí misma un fracaso. Puede mostrar que una integración es más difícil, que el recorrido no responde al problema o que falta una salvaguarda. La respuesta responsable es replanificar, reducir sin eliminar el resultado central, o parar, no esconder el hallazgo para proteger una fecha.

Incluye producción, control y transferencia

Que el camino principal funcione en el equipo de un desarrollador no demuestra una salida real. Define el entorno objetivo e incluye, cuando corresponda, configuración, secretos, migraciones, registros, monitorización, errores, copias, recuperación, accesibilidad y revisión de seguridad. Si el producto trata datos sensibles, dinero o acciones relevantes, permisos y comportamiento ante fallos requieren revisión explícita. Una URL de vista previa demuestra menos que un servicio operado.

Nombra quién posee repositorio, cuentas cloud, dominio, medición, soporte y decisiones de incidente. Comprueba que otra persona puede entender la configuración, ejecutar controles e identificar dependencias. La transferencia puede formar parte del MVP aunque sus funciones sean pequeñas. Si IVRYN u otro estudio opera componentes concretos, esa responsabilidad debe constar para el encargo. No puede inferirse de una página general del portfolio.

Protege el resultado útil más pequeño

Cuando la previsión es demasiado grande, elimina primero caminos secundarios, roles opcionales, integraciones o automatización antes de debilitar el resultado central. Un MVP estrecho todavía debe permitir que el usuario objetivo complete una tarea significativa de principio a fin y generar evidencia interpretable. Varias pantallas desconectadas pueden requerir menos código pero enseñar menos. Documenta cada exclusión y la condición que justificaría recuperarla.

Cierra la planificación con un registro de decisiones, no con una duración universal. Guarda alcance actual, supuestos, riesgos, hitos de evidencia, responsable de producción y próxima revisión. IVRYN se presenta como un estudio independiente de producto en París que diseña, desarrolla y opera software focalizado. Esa categoría no determina un calendario estándar. La estimación depende del producto, las decisiones disponibles y los terceros implicados.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.