Todo el mundo dice que su MVP estará en seis semanas. Casi ninguno lo está. No porque los equipos sean lentos, sino porque el plazo se estima sobre el desarrollo y se olvida todo lo demás: decidir el alcance, revisar, corregir, probar con usuarios reales y arreglar lo que aparece.
Estos son plazos observados en proyectos reales, con las fases completas incluidas.
Plazos por tipo de producto
| Tipo de producto | No-code | Código a medida |
|---|---|---|
| Landing con proceso de compra | 1–2 semanas | 2–4 semanas |
| Marketplace de dos lados | 6–10 semanas | 14–22 semanas |
| SaaS B2B sencillo | 5–8 semanas | 12–18 semanas |
| SaaS con integraciones | 8–12 semanas | 16–26 semanas |
| App móvil nativa | No aplica | 14–24 semanas |
| Producto con IA integrada | 4–8 semanas | 12–20 semanas |
| Plataforma con tiempo real | Poco viable | 18–30 semanas |
Si un proveedor te promete la mitad de estos plazos, pregúntale qué fases ha eliminado. Normalmente son las pruebas con usuarios reales y la corrección posterior, que es justo donde está el valor del MVP.
En qué se va el tiempo
Un desglose típico de un proyecto de doce semanas:
- Semanas 1–2: definición de alcance. Recorrido principal, perfiles de usuario, qué queda fuera. La fase que más se recorta y la que más retrasos provoca cuando se recorta.
- Semanas 3–4: diseño de flujos e interfaz. No arte: pantallas suficientes para que quien desarrolla sepa qué construir.
- Semanas 5–9: desarrollo. Lo único que la mayoría cuenta al estimar.
- Semana 10: pruebas internas y corrección.
- Semanas 11–12: primeros usuarios reales y ajustes. Aquí aparece siempre algo que nadie previó.
El desarrollo puro es menos de la mitad del calendario. Cuando alguien estima «seis semanas», casi siempre está estimando esa mitad.
Las cinco causas de retraso más frecuentes
1. Alcance que crece durante el proyecto. La causa número uno, con diferencia. Cada funcionalidad añadida a mitad de camino cuesta más que si hubiera estado desde el principio, porque obliga a rehacer decisiones ya tomadas.
2. Decisiones del cliente que tardan. El equipo espera una respuesta sobre el flujo de pagos y pasan cinco días. Multiplicado por diez decisiones, son dos semanas de calendario sin nadie trabajando.
3. Integraciones con terceros. Sistemáticamente subestimadas. La documentación está desactualizada, el entorno de pruebas falla, o el proveedor tarda en dar acceso.
4. Contenido y datos que no llegan. Textos, catálogos, imágenes, datos iniciales. El desarrollo termina y el producto no se puede lanzar porque falta el contenido.
5. Revisiones de diseño en bucle. Tres rondas de comentarios sobre detalles visuales de pantallas que cambiarán en cuanto las use un usuario real.
Cómo acortar el plazo sin romper el producto
- Define qué queda fuera, por escrito, antes de empezar. La lista de exclusiones vale más que la de funcionalidades.
- Nombra a una única persona que decide. Las decisiones por comité en una startup de tres personas cuestan días.
- Bloquea una franja diaria de respuesta. Media hora al día para desbloquear dudas ahorra semanas.
- Prepara el contenido en paralelo al desarrollo, no después.
- Acepta pantallas feas. El MVP tiene que funcionar y enseñar algo, no ganar premios.
- Deja para después lo que pueda hacerse a mano. Altas, facturación, soporte: con los primeros clientes, manual es más rápido.
Qué NO deberías acortar
Las pruebas con usuarios reales. Es la fase que se elimina primero cuando hay prisa y la única que justifica que esto se llame MVP y no «primera versión».
Un producto lanzado sin haber visto a nadie usarlo no es un producto mínimo viable: es una apuesta cara con interfaz.
Plazos y caja: la relación que importa
El plazo del MVP debe caber holgadamente en tu runway, con margen para iterar después. Si tu MVP tarda cinco meses y tienes seis de caja, el problema no es el plazo: es que no te queda tiempo para aprender de lo que construyas.
Regla práctica: el desarrollo no debería consumir más de un tercio de tu runway disponible. Si no cabe, reduce alcance hasta que quepa.
Preguntas frecuentes
¿Puedo acelerar metiendo más gente? Hasta cierto punto, y menos de lo que parece. En equipos pequeños, añadir personas a mitad de proyecto suele ralentizar las primeras semanas por la coordinación que exige.
¿Qué hago si voy con retraso? Recortar alcance, nunca calidad ni pruebas. Lanza con menos funcionalidades pero funcionando bien.
¿Cuándo empiezo a captar usuarios? Desde el primer día del desarrollo. Llegar al lanzamiento sin lista de espera es desperdiciar el momento de mayor atención posible.
Conclusión
El rango realista está entre 5 y 12 semanas en no-code y entre 12 y 26 en código a medida, con las fases completas contadas. Lo que rompe los plazos casi nunca es la tecnología: es el alcance que crece y las decisiones que tardan.
Fija el alcance, nombra a quien decide y protege la fase de prueba con usuarios. Con eso se cumplen la mayoría de calendarios.
¿Quieres acotar el alcance de tu MVP antes de empezar? El diagnóstico inicial es gratuito y sin compromiso. Pedir diagnóstico gratis.
BlackHold Consulting
Contenido editorial de BlackHold Startups sobre emprendimiento, inversión, tecnología y crecimiento empresarial.
