Benchmark de timelines de MVP 2026: cuánto tardaron 30 builds reales

La respuesta útil a "cuánto se tarda en construir un MVP" no es "tres meses". En nuestro benchmark 2026 de 30 builds de MVP de software anonimizados, la mediana desde kickoff firmado hasta el primer release en producción fue de 12 semanas calendario. El build más rápido llegó a piloto controlado en producción en 5 semanas. El más lento tardó 26. La diferencia rara vez fue el framework. Fue la forma del alcance: integraciones, release móvil, decisiones poco claras, acceso a datos, compliance y profundidad de QA.

Este artículo es sobre datos observados de duración, no sobre todo el proceso de MVP. Si buscas un partner de build, empieza por nuestro servicio de desarrollo de MVP. Si quieres el método completo, lee la guía de desarrollo de software. Y si quieres prueba, compara los casos detrás del patrón: PromptID, Twinsoft AI, Scramble Pay y Offlinery.

La respuesta del benchmark

Un MVP de software listo para producción tardó normalmente entre 10 y 14 semanas. Las herramientas internas pequeñas tardaron entre 5 y 12 semanas. Los MVP SaaS B2B tardaron entre 8 y 18. Los builds mobile o web-plus-mobile tardaron entre 12 y 26. Los MVP con IA tardaron entre 9 y 21 porque la velocidad del prototipo se compensó con trabajo de datos, evaluación y seguridad.

Definición de la muestra y exclusiones

La muestra cubre 30 builds de software a medida completados entre enero de 2024 y junio de 2026. Cada build tuvo un release real para usuarios u operadores, datos reales o de piloto realista, autenticación cuando hacía falta, deployment, QA, handover y una decisión de launch. Contamos semanas calendario, no persona-semanas, porque founders y compradores compran time-to-market, no horas en Jira.

Incluimos SaaS B2B, herramientas internas, portales, marketplaces, apps móviles y productos con IA. Excluimos demos no-code, prototipos solo de diseño, discovery sin build, rescues puros de QA, auditorías de smart contracts, pilotos hardware dominados por firmware o procurement, y programas enterprise cuyo primer release estaba enterrado dentro de una roadmap plurianual.

Mediana y rango por tipo de producto

Número de integraciones

Una integración cuenta cuando requiere credenciales propias, sandbox, mapeo de esquema, webhook, rate limits, aprobación o dependencia de producción. Stripe, Google Sign-in, HubSpot, SAP, un proveedor LLM, una vector DB y una publicación en app store son riesgos separados.

Cada integración productiva tiene dos timelines: la de ingeniería para construirla y la organizacional para conseguir acceso, datos, respuestas del vendor, aprobación de compliance y sign-off del área. La segunda retrasó más que la primera.

Móvil versus web

Mobile no tardó más porque React Native, Flutter, Swift o Kotlin sean lentos. Tardó más porque la superficie de release es mayor: location, cámara, background, push notifications, deep links, account deletion, privacy labels, screenshots y copy de store. Google Play advierte que algunas cuentas pueden tener revisiones de hasta siete días o más en casos excepcionales, y Apple App Review sigue siendo un gate real.

IA versus SaaS convencional

El informe DORA 2024 es una advertencia útil: la IA puede mejorar productividad individual y flow, pero empeorar estabilidad y throughput si el sistema de delivery es débil. La investigación también es mixta: un RCT de Google con 96 ingenieros encontró una reducción de alrededor del 21% en una tarea enterprise compleja, mientras que un RCT open-source de 2025 encontró que desarrolladores expertos fueron un 19% más lentos en repos maduros. Nuestra observación de delivery es más estrecha: la IA aceleró el prototipo, pero no eliminó discovery, QA, data governance ni launch.

Discovery, build, QA y launch por separado

Retrasos: cliente versus ingeniería

Por días de retraso, aproximadamente el 58% vino del lado cliente, 29% del lado ingeniería y 13% de plataformas o terceros. El retraso cliente más caro no fue "feedback dos días tarde". Fue ambigüedad de decisión: una feature se implementó y luego fue reinterpretada por un stakeholder que no estuvo en discovery.

Cómo usar este benchmark

1. Empieza por la plataforma. Web-only puede apuntar a 8-12 semanas. Mobile o web-plus-mobile suele empezar en 12-20 salvo que el scope sea mínimo.
2. Cuenta integraciones antes que pantallas. Siete pantallas y seis integraciones son más riesgosas que veinte pantallas y una base de datos.
3. Haz que discovery produzca exclusiones. Si v1 no dice qué queda fuera, la timeline es ficción.
4. Presupuesta QA como fase. Un MVP puede ser pequeño. No puede estar sin test donde hay confianza, dinero, datos o seguridad.
5. Nombra owners de decisión. Cada integración, cuestión legal, bloque de copy, excepción de workflow y asset de launch necesita dueño antes de build.
6. Trata la IA como validación, no solo velocidad. Añade evals, fallback, logging y revisión humana donde un fallo del modelo tenga coste real.

Fuentes y caveat del benchmark

Este benchmark se basa en registros anonimizados y retrospectivas de Wavect, así que es direccional, no una encuesta industrial representativa. La investigación externa refuerza la cautela: una revisión sistemática de prácticas de MVP encontró poca investigación sobre factibilidad técnica y estimación de esfuerzo. DORA también advierte que comparar aplicaciones distintas sin contexto puede ser engañoso. Para mobile, revisa Apple App Review y Google Play publishing. Para IA, ve DORA 2024, DORA metrics, el mapping study de MVP, el RCT de productividad de Google y el RCT open-source de 2025.