Desarrollar un MVP en menos de 3 meses: el plan semana a semana

Plan real para desarrollar un MVP en menos de 3 meses: qué se decide cada semana, equipo mínimo, coste por bloque y qué recortar cuando vas tarde.

Desarrollar un MVP en menos de 3 meses: el plan semana a semana

Doce semanas son sesenta días laborables, y se gastan igual de rápido decidiendo que programando. La mayoría de MVP que acaban en seis meses no se retrasan por un problema técnico, sino porque en la semana 4 nadie se atrevió a decir que no a una funcionalidad. Los datos de PMI recogidos en este análisis lo cuantifican: el 52% de los proyectos sufre ampliaciones de alcance no controladas y el 48% acaba tarde.

En Docastix construimos aplicaciones a medida con este calendario desde Galicia, y lo que sigue es el plan de ejecución que usamos, no una teoría. Si aún estás decidiendo qué es un MVP y cómo lo presentas a un inversor, empieza por nuestra guía de producto mínimo viable y vuelve aquí cuando tengas la idea acotada. Esto es el «cómo»: quién hace qué, en qué semana, por cuánto dinero y qué se cae por la borda cuando el calendario aprieta.

Respuesta rápida: ¿se puede desarrollar un MVP en menos de 3 meses?

Sí, siempre que el alcance quepa en cinco bloques cerrados y alguien tenga autoridad para recortar sin convocar una reunión. Doce semanas dan para un producto de una plataforma, con tres a cinco flujos y un backend sencillo. No dan para dos apps nativas, integración con un ERP antiguo ni facturación completa. La referencia de mercado ronda los 3-4 meses de media: 12 semanas es ambicioso, pero no ficticio. Es el caso comprimido: los plazos habituales por tipo de app, y lo que añaden las tiendas, están en cuánto se tarda en desarrollar una app.

BloqueSemanasDecisión que cierraEntregable
Discovery1-2Qué problema y qué se queda fueraAlcance firmado y métrica de éxito
Diseño y arquitectura3-4Cómo se usa y sobre qué se construyePrototipo clicable y stack elegido
Construcción5-9Qué entra en cada sprintBuild instalable cada viernes
Beta cerrada10-11Qué se arregla y qué se documenta20-50 usuarios reales usándolo
Lanzamiento12Cuándo se publica y qué se mideProducto en producción con analítica

Si necesitas quedarte con tres cifras: la construcción real ocupa 5 de las 12 semanas, discovery y diseño se comen un tercio del calendario (ahorrártelo es la forma más cara de ganar tiempo) y un MVP a medida arranca en 8.000 €, con la horquilla habitual en 25.000-45.000 € cuando incluye backend, panel y pagos.

Semanas 1-2: discovery y recorte del alcance

Aquí no se escribe código: se escribe la lista de lo que NO va a hacer el producto, el documento más importante del proyecto. El 43% de las startups que cierran lo hace por falta de encaje producto-mercado, según el análisis de CB Insights sobre 431 empresas cerradas desde 2023. Programar rápido algo que nadie quiere no es velocidad, es desperdicio.

Qué sale de estas dos semanas:

  • Una hipótesis con número. «Los administradores de fincas tardan horas en responder a un lead» es una observación. «Bajamos la primera respuesta a menos de 60 segundos» es medible: es lo que perseguimos en PropPilot, y acabó respondiendo en menos de 60 segundos a cualquier hora.
  • De tres a cinco flujos de usuario, numerados. Si tu lista tiene ocho, no tienes un MVP: tienes la versión 2.0.
  • La lista de exclusiones firmada. Literal: «en esta versión no habrá multiidioma, ni panel de estadísticas, ni exportación a Excel». PMI mide que los proyectos sin un proceso formal de cambios tienen un 35% más de probabilidad de pasarse de coste o de plazo.
  • Una métrica de éxito con umbral. «Retención a 7 días por encima del 25%» o «15 clientes de pago». Sin umbral, cualquier resultado parece bueno.
  • La decisión de cobro. El modelo de monetización se decide ahora, no en el mes cinco. Aquí tienes las opciones y cuándo encaja cada una.

Señal de alarma: si en la semana 2 no puedes nombrar a diez personas que probarán la beta, tu problema no es el desarrollo.

Semanas 3-4: diseño, prototipo y arquitectura

Dos semanas para convertir la lista de flujos en algo que se pueda tocar. El diseño de un MVP no busca premios: busca que alguien que no te conoce entienda la pantalla en cinco segundos.

  • Semana 3: wireframes de todas las pantallas y prototipo clicable. Se enseña a cinco personas del público objetivo y no se pide opinión («¿te gusta?»), sino que completen una tarea, y se mira dónde se atascan.
  • Semana 4: diseño visual de las pantallas principales, componentes reutilizables y decisiones técnicas. Aquí se cierran la plataforma, el enfoque nativo o multiplataforma y el proveedor de backend.

En 12 semanas, salvo que dependas de hardware específico, multiplataforma gana casi siempre: mantienes un solo código para iOS y Android. Lo desarrollamos en nativo vs multiplataforma. Nosotros elegimos nativo en Dormus por la integración fina con el sistema, y Flutter en Saher Connect porque tenía que funcionar offline en el campo, con más de 200 referencias de boquillas ISO consultables sin cobertura. La regla: nativo cuando manda el hardware, multiplataforma cuando manda el calendario.

Dos cosas se cierran ahora y no se tocan más: el sistema de diseño y el modelo de datos. Cambiar cualquiera de los dos en la semana 8 cuesta una o dos semanas de retrabajo.

Semanas 5-9: construcción

Cinco semanas, sprints de una semana y una regla innegociable: cada viernes hay una build instalable, aunque esté a medias. No un vídeo ni una captura: un APK o un TestFlight que se pueda abrir. Es el único indicador honesto de progreso. Orden de ataque:

  • Sprint 1 (semana 5): infraestructura, autenticación, navegación y despliegue automático. Aburrido y obligatorio.
  • Sprint 2 (semana 6): el flujo principal de punta a punta, sin florituras. Si tu producto es una app de reservas, aquí se reserva.
  • Sprint 3 (semana 7): flujos secundarios y panel de administración mínimo. Sin panel no puedes operar la beta.
  • Sprint 4 (semana 8): pagos, notificaciones y analítica. Sin eventos instrumentados, la beta no te dirá nada.
  • Sprint 5 (semana 9): cierre, bugs y preparación del envío a tiendas.

La semana 9 es la más subestimada. Publicar en tiendas tiene fricción propia: cuenta de Apple Developer a 99 €/año, cuenta de Google Play a 25 € de pago único, fichas, política de privacidad y revisión. Reserva días reales o tu semana 12 será la 14. Si es una plataforma web, el equivalente son producción, dominios y cookies: más ligero, pero no cero.

Semanas 10-12: beta cerrada, lanzamiento y primeras métricas

La beta (semanas 10-11)

Entre 20 y 50 usuarios reales, reclutados en el discovery. Los amigos te dirán que está muy chulo; lo que necesitas es ver dónde abandonan.

  • Instrumenta antes de invitar. Eventos, embudos y un canal único de feedback: un formulario o un grupo, no cinco conversaciones por WhatsApp.
  • Clasifica en tres cajones: bug que impide usar el producto, fricción que baja la conversión y petición de funcionalidad. Solo se tocan los dos primeros; el tercero se apunta y espera al lanzamiento.
  • Accesibilidad mínima: contraste, tamaños de toque y lectores de pantalla en los flujos principales. Es obligación legal para buena parte de los productos digitales en la UE, como explicamos en la normativa europea de accesibilidad, y añadirla después cuesta el triple.

El lanzamiento (semana 12)

Publicar es un trámite; lo relevante es qué pasa las dos semanas siguientes. Ten decidido quién mira las métricas, cada cuánto y qué hará con ellas: un MVP sin nadie responsable de leer los datos es un producto huérfano.

El equipo mínimo para llegar en 12 semanas

Con menos gente no llegas; con más, tampoco: sumar un tercer desarrollador en la semana 7 casi siempre retrasa el proyecto.

RolDedicaciónSemanas clave
Product owner (cliente)25-30%Todas. Decide en 24 h o se para el sprint
Diseñador UX/UI100% en 3-4, luego 20%3-4 y 10-11
Desarrollador senior100%4-12
Desarrollador mid100%5-11
QA / tester30-40%8-12

El rol que más proyectos hunde no es técnico: es el product owner que no responde. Si quien decide tarda una semana en contestar a «¿el registro es con email o con teléfono?», has perdido el 8% del calendario en una pregunta de dos minutos. Aquí va cómo elegir el equipo para desarrollar tu app.

Cuánto cuesta cada bloque

Las tarifas en España van de 40-65 €/h para perfiles mid a 65-110 €/h para seniors; un freelance ronda los 35-80 €/h y una agencia los 60-120 €/h. Así se reparte el presupuesto de un MVP de 12 semanas:

Bloque% del presupuestoEn un MVP de 25.000 €
Discovery y alcance10-15%2.500 € – 3.750 €
Diseño y prototipo15-20%3.750 € – 5.000 €
Construcción (5 sprints)45-55%11.250 € – 13.750 €
Beta y correcciones10-15%2.500 € – 3.750 €
Lanzamiento y analítica5-10%1.250 € – 2.500 €

Un MVP a medida arranca en 8.000 € (una plataforma, alcance muy acotado) y el proyecto medio en España ronda los 40.000 €. Tienes el desglose completo en cuánto cuesta hacer una app y una calculadora de presupuesto.

Y la partida que casi nadie presupuesta: el mes 4 en adelante. El mantenimiento va del 15% al 20% del coste de desarrollo al año, y el evolutivo arranca desde 500 €/mes. Un MVP sin presupuesto de continuidad se muere solo aunque la beta vaya bien.

Qué recortas cuando vas tarde (y qué no se toca)

Vas a ir tarde en algún momento. La diferencia entre entregar en la semana 12 y en la 20 es tener decidido el orden de sacrificio.

Se recorta, por este orden:

  1. Configuración y perfil. Un usuario de beta no necesita cambiar el idioma ni el avatar.
  2. Onboarding elaborado. Tres pantallas de bienvenida se sustituyen por una.
  3. La segunda plataforma. Lanza en una sola: Android si tu público español es de consumo, iOS si es profesional o de pago.
  4. El panel de administración bonito. Un panel feo que funciona vale lo mismo; una hoja de cálculo conectada por API aguanta las primeras semanas.
  5. Automatizaciones internas. Si con 30 usuarios el proceso lo puede hacer una persona a mano, que lo haga a mano. Ya lo automatizarás cuando tengas 3.000.

No se toca nunca:

  • La instrumentación analítica. Sin ella la beta no genera aprendizaje y todo el ejercicio pierde el sentido.
  • La autenticación y la gestión de datos personales. Un fallo aquí no es un bug, es un problema legal.
  • El flujo principal completo. Un MVP con el flujo central a medias no valida nada.
  • Copias de seguridad y despliegue automatizado. Ahorrar dos días aquí cuesta una semana después.

Señales de que no vas a llegar

Cuatro semáforos con fecha. Si se enciende uno, no aceleres: recorta.

  • Semana 2 sin lista de exclusiones firmada. Vas tarde y aún no lo sabes. Solo el 31% de los proyectos termina a tiempo, en presupuesto y con el alcance previsto según los datos del CHAOS Report recogidos aquí, y ninguno de ellos empezó sin alcance cerrado.
  • Semana 4 sin prototipo clicable validado con cinco personas. Estás a punto de programar suposiciones.
  • Semana 6 sin el flujo principal de punta a punta. Punto de no retorno: o recortas alcance esta misma semana, o te vas a la 16.
  • Semana 9 con más de 15 bugs abiertos de prioridad alta. No es falta de esfuerzo, es calidad de base. Para y estabiliza antes de meter nada nuevo.

Y uno más sutil: si en las reuniones se habla de funcionalidades futuras en vez de lo entregado el viernes, el foco ya se ha perdido.

La IA acelera el código, no el proyecto

¿Con asistentes de IA se puede hacer esto en seis semanas? Mirando los datos, no de forma automática.

La adopción es masiva: el informe DORA 2025 de Google, con casi 5.000 profesionales encuestados, sitúa la adopción de IA en el 90% de los desarrolladores, y más del 80% dice que ha mejorado su productividad. Pero percepción y medición no coinciden. En un ensayo controlado de METR con 16 desarrolladores experimentados y 246 tareas reales, los participantes tardaron un 19% más usando IA mientras estimaban que les había acelerado un 20%. Los autores avisan de que el estudio no cubre proyectos desde cero, que es el caso de un MVP.

A eso se suma el coste diferido: el análisis de GitClear sobre 211 millones de líneas de código muestra que el código copiado y pegado pasó del 8,3% al 12,3% entre 2021 y 2024, mientras el refactorizado cayó del 25% a menos del 10%. Y en Stack Overflow 2025, el 66% de los desarrolladores señala como principal frustración las respuestas «casi correctas, pero no del todo»; un 45,2% dice que depurar código generado por IA lleva más tiempo.

Dónde sí gana semanas en un MVP: andamiaje de pantallas y modelos, pruebas automatizadas, migraciones, textos de las fichas de tienda y prototipos desechables para la semana 3. Dónde no: modelo de datos, lógica de negocio delicada e integraciones con terceros, donde la revisión se come la ganancia. Que tu producto incorpore IA como funcionalidad, con agentes conversacionales o clasificación automática, es alcance, no velocidad, y se presupuesta aparte.

Conclusión

Desarrollar un MVP en menos de 3 meses no va de programar más rápido. Va de decidir antes, escribir lo que queda fuera y sostener esa decisión cuando alguien proponga «una cosita rápida» en la semana 7. El calendario funciona porque cada bloque cierra una decisión y ninguna se reabre: el alcance en la 2, la experiencia en la 4, la funcionalidad en la 9, la calidad en la 11.

Y el objetivo no es lanzar: es aprender algo concreto que te permita decidir si sigues, giras o paras. Si prefieres que el calendario lo lleve un equipo que ya lo ha recorrido, cuéntanos tu idea y te devolvemos un alcance de 12 semanas con lo que entra, lo que queda fuera y cuánto cuesta cada bloque.

Preguntas frecuentes

Entre 3 y 4 meses de media para un producto con backend. Doce semanas es alcanzable si limitas el alcance a una plataforma y a tres o cinco flujos, con el equipo dedicado desde la primera semana. Por debajo de ocho semanas hablamos de un prototipo, no de un producto en producción.

Sigue leyendo