¿Cuánto se tarda en construir un MVP? Un plan práctico de 3 a 5 semanas
Un MVP enfocado tarda de 3 a 5 semanas cuando prueba un workflow con auth estándar, un modelo de datos y una métrica de éxito. Este es el calendario honesto.
¿Cuánto se tarda en construir un MVP? Un MVP web enfocado tarda 3 a 5 semanas cuando prueba un workflow con auth estándar, un modelo de datos y una métrica de éxito. Tarda 6 a 12 semanas o más cuando el brief incluye varios roles, integraciones pesadas o aprobación por comité.
La parte incómoda es que el calendario suele ser una decisión de scope, no un hecho de ingeniería.
Si usted está comparando presupuestos ahora, la diferencia probablemente confunde por una razón justa. Algunos equipos presupuestan una primera prueba, mientras que otros presupuestan una versión pequeña del producto final. Esta guía le da el calendario que usamos en webvise, los bloqueos que lo alargan y las reglas de recorte que evitan que un MVP finja ser un build completo.
3 a 5 semanas es realista para un workflow central. Eso significa un usuario principal, una tarea, una forma de base de datos, una métrica de lanzamiento y decisiones rápidas.
6 a 12 semanas es normal cuando el scope tiene varios roles o integraciones profundas. No es un fracaso. Es una primera versión más grande.
La primera semana decide el calendario. El acceso lento a cuentas, reglas de aceptación vagas y decisiones tardías de API cuestan más tiempo que el código.
webvise construye MVPs desde €5.000 en 3 a 5 semanas cuando el scope encaja en esta forma. La especificación del servicio está aquí: MVP development.
El MVP más seguro no es el conjunto más pequeño de funciones. Es el producto más pequeño que puede producir una decisión dentro de los 30 días posteriores al lanzamiento.
La respuesta corta según el scope
Las guías públicas de calendario para MVP suelen caer entre 4 y 12 semanas. Ese rango no es incorrecto, pero oculta la pregunta útil: ¿de qué tipo de MVP hablamos?
En webvise separamos la respuesta por forma de scope. La promesa de 3 a 5 semanas pertenece a un MVP web con un workflow claro, stack técnico fijo y una persona responsable que puede cortar funciones durante el build.
| Forma de scope | Calendario típico | Qué prueba |
|---|---|---|
| Prototipo clicable | 2 a 5 días | ¿Alguien entiende la oferta y el flujo? |
| Prueba No-code | 1 a 2 semanas | ¿La gente hace clic, se registra o paga antes de que exista el software? |
| MVP web enfocado | 3 a 5 semanas | ¿Puede un usuario completar el workflow central con datos reales? |
| MVP de producto estándar | 6 a 12 semanas | ¿Pueden varios roles usar el producto con integraciones reales? |
| MVP regulado o marketplace | 12+ semanas | ¿Puede el producto manejar riesgo, permisos, cumplimiento o demanda de dos lados? |
Si su idea necesita primero una landing page, lista de espera y seguimiento manual, no pague aún por un MVP. Si necesita auth, un workflow, una base de datos, despliegue y analytics, encaja en la vía de MVP development de webvise.
La versión semana a semana
Un MVP de 3 a 5 semanas no es un producto completo comprimido. Es un build donde las decisiones de riesgo se toman antes del kickoff y la primera versión queda lo bastante estrecha para probar rápido.
| Fase | Qué ocurre | Decisión necesaria |
|---|---|---|
| Antes del kickoff | Se nombran objetivo de aprendizaje, usuario, workflow, métrica de lanzamiento, cuentas y recortes duros | Un responsable acepta los límites del scope |
| Semana 1 | Flujo UX, modelo de datos, auth, despliegue y primer camino clicable | Ningún rol nuevo sin retirar otra cosa |
| Semana 2 | Workflow central, escrituras en base de datos, ruta de email o pago, necesidad admin básica | Las integraciones quedan estándar salvo que prueben el producto |
| Semana 3 | Datos reales, analytics, manejo de errores, pruebas mobile, primera prueba interna | Solo defectos y bloqueos de lanzamiento entran en scope |
| Semana 4 | Pulido para usuarios, copy, handoff, tracking, despliegue a producción | Lanzar vale más que otra ronda de cambios de preferencia |
| Semana 5 | Margen para feedback, casos de pago, problemas de API de partner o limpieza de datos | Todo lo no ligado al lanzamiento pasa a después del release |
El stack no es el truco. webvise suele construir este nivel con Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel y analytics básicos. La velocidad viene de usar piezas conocidas y negarse a inventar infraestructura antes de que el producto tenga evidencia.
Qué convierte 3 semanas en 3 meses
La mayoría de los retrasos en un MVP no vienen de ingeniería difícil. Vienen de decisiones que quedaron blandas porque nadie quería recortar el trabajo deseable pero no esencial.
| Fuente de retraso | Cómo suena | Cómo mantener el calendario |
|---|---|---|
| Roles de usuario | 'Admin, comprador, vendedor, partner y soporte necesitan dashboards' | Elija un usuario principal y un operador interno |
| Integraciones | 'Necesitamos CRM, billing, analytics, Slack y la base antigua desde el día uno' | Mantenga solo el sistema necesario para probar el workflow |
| Bucles de aprobación | 'El equipo revisará cuando todos tengan tiempo' | Nombre un responsable de recorte con respuesta en 24 horas |
| Scope de diseño | 'Terminemos todas las pantallas en Figma antes de construir' | Diseñe primero el camino central y pula después de que funcione |
| Claims de cumplimiento | 'Quizá necesitemos audit logs más adelante' | Construya solo los controles legales y de seguridad que necesitan los primeros usuarios |
Por eso un brief corto de MVP importa más que una lista larga de funciones. La plantilla de nuestra guía de MVP requirements document es la versión que queremos ver antes de un build de precio fijo.
Minihistoria: OHYP necesitó 6 semanas por las razones correctas
El 2026-02-20, publicamos el caso de estudio de OHYP GmbH, un servicio inmobiliario de Berlín que necesitaba certificados de financiación para compradores en Alemania. La promesa de negocio era concreta: un comprador debía recibir un certificado vinculante en menos de 24 horas, sin consulta SCHUFA, mientras el sistema comparaba más de 550 bancos partner.
No era un MVP de 3 semanas, y llamarlo así habría sido deshonesto. La primera versión necesitaba un formulario de financiación de 10 pasos, generación automática de certificados PDF y un dashboard admin para gestionar el ciclo de vida de las solicitudes.
El resultado siguió siendo lean: 6 semanas, 96 de rendimiento Lighthouse, carga inferior a 1,2 s y entrega de certificados en menos de 24 horas. El calendario pasó de 5 semanas porque el workflow tenía datos financieros reales y un handoff operativo real, no porque el equipo añadiera funciones decorativas.
Minihistoria: los MVP vibe-coded ahorran días y luego pierden semanas
El 2026-05-18, escribimos sobre MVPs de Lovable, Bolt y v0. Esas herramientas son útiles para prototipos porque hacen visible la idea de un fundador en horas. El problema empieza cuando un prototipo se trata como la base del producto.
El patrón es tan consistente que escribimos una regla: cuando una app vibe-coded tiene usuarios reales, la reconstruimos en lugar de parchearla. Un build limpio sobre nuestro stack suele tomar 3 a 6 semanas. El rescate puede tomar 8 a 12 semanas porque cada arreglo debe respetar un esquema, estructura de rutas y modelo de datos en vivo que nadie diseñó.
Es la respuesta menos llamativa, pero es más justa para el presupuesto. Use AI app builders para aprender qué debe hacer el producto. Use un build MVP cuando lo siguiente que necesita son datos fiables de usuarios reales.
La prueba de calendario de 30 minutos
Antes de pedir un calendario a una agencia, pase el scope por esta prueba. Si no puede responderla en 30 minutos, el proyecto todavía no está listo para un calendario fijo.
Una frase: ¿qué hipótesis de riesgo debe probar la versión uno?
Un usuario: ¿quién usa la primera versión antes que nadie?
Un workflow: ¿qué pasos llevan a ese usuario desde la entrada hasta el valor?
Una métrica: ¿qué número le dice en 30 días si debe continuar?
Un responsable: ¿quién puede recortar o aceptar scope en 24 horas?
Cuentas conocidas: ¿qué cuentas de auth, pago, email, analytics, hosting y base de datos están listas?
Recortes duros: ¿qué no saldrá antes del lanzamiento aunque alguien lo pida?
Si las respuestas caben en una página, un MVP de 3 a 5 semanas puede ser realista. Si las respuestas requieren un workshop, empiece por el brief. La versión de costes de la misma decisión está en nuestra guía de coste de desarrollo de MVP.
Cuándo un MVP más largo es la respuesta honesta
Algunas primeras versiones no deberían comprimirse en 5 semanas. Datos regulados, claims médicos, decisiones financieras, marketplaces, app stores móviles y APIs de partners complejas pueden justificar un build más largo.
La prueba es simple: ¿el tiempo extra protege a un usuario real, una transacción real o un deber legal real? Si sí, manténgalo. Si el tiempo extra solo hace que el producto parezca más completo, recórtelo.
webvise ayuda a fundadores a tomar esa decisión antes de empezar con código. Si su MVP debe ser lo bastante estrecho para 3 a 5 semanas, nuestro servicio de MVP development es la vía correcta. Si ya es una plataforma de producción, lo diremos y lo scoperemos de otra manera.
Un buen calendario de MVP no es una pose. Es la consecuencia de un scope claro, decisiones rápidas y una primera versión que existe para responder una pregunta de negocio. Si quiere que webvise ponga a prueba su brief antes de construir, envíenoslo.