Casi todos los founders preguntan esto con el mismo tono: mitad esperanza, mitad preparándose para una mala noticia. "¿Cuánto tarda un MVP?" Normalmente hay una fecha de ronda detrás, o una demo comercial ya agendada, o una reunión de junta donde alguien va a preguntar "bueno, ¿y el producto?". La respuesta honesta es poco satisfactoria: depende por completo de qué estés llamando MVP. Y casi todos los equipos, sin querer, inflan esa etiqueta hasta que en silencio termina significando "el producto completo, pero apurado".
Hemos estado en suficientes de estas conversaciones para notar el patrón. Alguien empieza con "solo lo básico" y para la tercera llamada de planificación, "lo básico" incluye un sistema de referidos, tres roles de usuario y un dashboard admin con exportación a PDF. Nada de eso está mal en sí — está mal llamarlo MVP.
Qué es un MVP en realidad
Quitando la palabra de moda, un MVP es simplemente la rebanada más pequeña lista para producción que le permite a un usuario real completar un trabajo valioso, de principio a fin, sin que alguien de tu equipo esté arreglando cosas por detrás en silencio.
No es:
- un prototipo clickeable sin un backend real detrás,
- una plataforma multi-rol completa justificada con "eventualmente la vamos a necesitar",
- ni una lista de features copiada de quien consideres tu mayor competidor.
Una prueba que usamos con clientes: si tu spec de "MVP" cubre cada edge case, cada reporte de admin y cada integración de terceros que puedas imaginar necesitar, no estás definiendo un MVP. Estás definiendo la v2 y llamándola v1 por costumbre.
Bandas de tiempo que suelen aguantar
Te vamos a dar bandas, no una promesa — porque una promesa de un desconocido en internet no vale nada.
- 2–4 semanas. Es una rebanada genuinamente angosta: auth, un flujo core, un pipeline de deploy. Solo pasa así de rápido cuando el alcance ya estaba claro desde el inicio y las integraciones son livianas o inexistentes.
- 4–8 semanas. El MVP enfocado más típico — flujo core más admin básico, un entorno de staging, y algo que en verdad está listo para producción y no una demo que se rompe si haces clic donde no debes.
- 8–12+ semanas. Pagos, varios roles de usuario con permisos distintos, funciones de IA que necesitan evaluación real, o integraciones legacy que nadie documentó del todo — cualquiera de estas te lleva aquí, a veces más allá.
Un patrón que conviene conocer: cualquier cosa anunciada como "lista en 10 días" mientras promete calidad de producción completa suele estar saltándose algo. A menudo son las pruebas. A veces es la documentación de handover. De vez en cuando son ambas, y te enteras tres meses después cuando el desarrollador original ya no responde.
Por qué los tiempos se retrasan más de lo que los equipos admiten
Rara vez es el código lo lento. Casi siempre es la latencia de decisión del lado del comprador — esperar tres días una respuesta en Slack sobre el texto de un botón, o un stakeholder que quiere ver "una opción más" antes de aprobar un flujo que ya estaba acordado. No lo decimos para culpar a nadie; decidir rápido es genuinamente difícil cuando estás manejando otras cinco cosas a la vez. Pero vale nombrarlo, porque es el verdadero asesino del cronograma que nadie pone en el Gantt.
Qué debe significar "listo" en realidad
Cualquiera sea el timeline al que llegues, acuerda esto por escrito antes de arrancar el reloj — no después de la semana seis, cuando se vuelve una negociación en lugar de un checklist:
- Los usuarios completan el flujo principal de punta a punta, no solo hacen clic en un happy path con datos falsos.
- El código vive en tu repositorio. Credenciales y cuentas cloud están a tu nombre, no en una cuenta personal que alguien "transferirá después".
- Existe un entorno de staging, y el proceso de deploy a producción está documentado lo suficiente para que alguien distinto de quien lo construyó pueda ejecutarlo.
- Los caminos críticos tienen pruebas automatizadas, o al menos un checklist de QA lo bastante específico para que "funciona" signifique algo.
- Puedes ver demos semanales de software funcionando — no solo recibir emails de status que describen un avance que no puedes verificar.
Una fecha de lanzamiento sin una definición escrita de "listo" es solo un rumor con invitación de calendario.
Cómo comprimir el timeline sin arruinar la calidad
Si la fecha límite es real y no negociable — las rondas de inversión no esperan a nadie — aquí está la palanca real:
- Corta alcance antes de cortar calidad. Menos features bien hechos gana a más features sostenidos con cinta adhesiva.
- Secuencia con intención: flujo core primero, admin esencial segundo, integraciones secundarias al final. Ningún primer usuario real necesita la exportación a CSV.
- Prefiere incrementos semanales entregables frente a un gran reveal al final. Es menos dramático, pero así detectas un supuesto equivocado en la semana dos en vez de la nueve.
- Decide rápido de tu lado. En serio — esta es en gran parte tu responsabilidad, y mueve la aguja más que casi cualquier decisión técnica.
Hemos visto equipos recortar dos o tres semanas de un cronograma solo por decidir más rápido sobre un mockup, sin tocar la construcción en sí.
Un timeline es una decisión de alcance disfrazada de calendario
Esto vale la pena internalizarlo: cuando alguien pregunta "¿puedes hacerlo en cuatro semanas?", en realidad está haciendo dos preguntas a la vez, y solo una es sobre velocidad. La otra es "¿qué estás dispuesto a cortar para llegar a esa fecha?". Un partner que dice sí a cualquier timeline sin renegociar el alcance, o te va a decepcionar, o va a saltarse en silencio las partes que no vas a notar hasta que importen — las pruebas, la documentación, los edge cases que nadie mostró en la demo.
La versión mejor de esa conversación suena así: "Cuatro semanas te da el flujo core y el admin básico. Pagos y el segundo rol esperan al sprint dos." No es una peor respuesta. Es una más honesta, y es la que en realidad protege tu fecha de lanzamiento en vez de solo nombrarla.
En ConaiSoft planificamos MVPs por sprints cortos con una primera demo clara, normalmente dentro de la primera o segunda semana. Si necesitas un timeline real para tu idea en vez de una adivinanza, cuéntanos qué quieres lanzar — te diremos con honestidad qué cabe en la primera rebanada entregable, y qué debe esperar a la segunda ronda.