Cómo lanzar un MVP en 6 a 12 semanas: el método completo

Lanzar un MVP en 6 a 12 semanas es realista si sigues un método concreto: una semana de discovery con recorte despiadado de alcance, tres semanas para construir el flujo principal de punta a punta en infraestructura de producción, seis semanas de iteración sobre señal real de usuarios, y un cierre de handoff o continuidad. Lo que marca la diferencia no es programar más rápido: es decidir mejor qué no construir. En Freshwork llevamos más de 10 años construyendo software desde Santiago de Chile — partimos en 2014 — y este es el método completo que usamos en nuestros proyectos de desarrollo de MVP.

¿Qué es un MVP y qué no es?

Un MVP (producto mínimo viable) es la versión más pequeña de tu producto que permite validar, con usuarios reales, si el problema que crees estar resolviendo existe y si tu solución les sirve. Es software funcionando en producción, con medición de comportamiento real. No es un prototipo desechable ni una presentación bonita para inversionistas.

Lo que tampoco es: una versión 1.0 con "solo lo esencial" definido por comité. Cuando cada stakeholder agrega su funcionalidad "imprescindible", el MVP de 6 semanas se transforma en un proyecto de 6 meses. La disciplina de recorte es el 80% del método; el otro 20% es ejecutar rápido y medir todo.

¿Cómo se organiza el trabajo semana a semana?

Semana 1: discovery y recorte despiadado

Una semana, no un mes. De aquí sales con tres cosas: la hipótesis central escrita en una frase ("los usuarios X pagarán por Y porque Z"), el flujo mínimo que la valida, y una lista explícita de lo que no se va a construir. La regla es simple: si una funcionalidad no ayuda a validar la hipótesis central, sale del alcance. Duele — por eso lo llamamos recorte despiadado — pero es lo que hace posible todo lo demás.

Semanas 2 a 4: el happy path de punta a punta, en producción

Se construye el camino feliz completo: desde que el usuario llega hasta que obtiene valor. Sin manejar cada caso borde, sin pantallas de configuración, sin pulir lo que nadie ha usado todavía. Y en infraestructura de producción desde el primer día: deploy real, dominio real, monitoreo básico. "Producción" no significa sobre-ingeniería; significa que en la semana 4 le puedas mandar el link a un usuario real sin vergüenza. Nuestra regla interna: si en la semana cuatro no hay nada que puedas clickear, algo anda mal.

Semanas 5 a 10: iterar sobre señal real

Aquí el MVP se gana el nombre. Usuarios reales usando el producto, analytics registrando qué hacen (y qué abandonan), conversaciones cortas con los primeros usuarios, y demos semanales para decidir el siguiente paso. Cada semana se prioriza según lo que muestran los datos, no según el roadmap que se escribió antes de tener información. Vas a aprender cosas que ninguna planificación anticipó — ese aprendizaje es el producto de esta etapa.

Semanas 11 y 12: handoff o continuidad

Dos salidas posibles. Handoff: documentación, capacitación y entrega de credenciales a tu equipo interno — el código es 100% de tu propiedad, siempre. O continuidad: el mismo equipo sigue hacia la siguiente fase. Lo importante es que la decisión se toma con más de seis semanas de datos de uso real, no con intuición.

¿Qué se corta y qué no se corta jamás?

Se corta casi todo lo que no valida la hipótesis:

• Paneles de administración sofisticados — una planilla o acceso directo a la base de datos aguanta perfecto las primeras semanas.
• Múltiples roles y permisos.
• Apps nativas, si una web responsive valida lo mismo.
• Integraciones "nice to have" y personalización avanzada.
• Internacionalización, temas oscuros, y todo lo que empiece con "sería bueno que...".

Y hay tres cosas que no se cortan jamás:

1. Analytics y feedback loops. Un MVP sin medición es un lanzamiento a ciegas: gastaste ocho semanas y no aprendiste nada. La instrumentación de eventos y un canal directo con los usuarios se instalan en la semana 2, no en la 10.
2. El flujo de valor completo. Si el usuario no puede llegar de punta a punta, no estás validando un producto: estás mostrando pantallas.
3. Seguridad básica y respaldo de datos. Mínimo viable no significa negligente. Contraseñas bien guardadas, HTTPS y backups no son opcionales.

¿Cuáles son los errores clásicos al construir un MVP?

• Construir para escalar antes de validar. Microservicios, Kubernetes y arquitectura para un millón de usuarios... en un producto que todavía no tiene diez. La escalabilidad se construye cuando hay tracción que la justifique. Y cuando toca, se puede: nosotros construimos la plataforma de una campaña para LAN que registró 191.219 usuarios con 2.580 conectados a la vez — pero eso fue con demanda comprobada, no antes.
• Seis meses de roadmap sin nada demostrable. Si el plan no contempla software clickeable antes de la semana 4, no es un MVP: es un proyecto tradicional disfrazado.
• Confundir mínimo con barato. El recorte es de alcance, no de calidad. Lo poco que hay tiene que funcionar bien, porque es lo único que el usuario va a juzgar.
• Ignorar la señal. Lanzar y no mirar los datos — o mirarlos y no cambiar el plan — convierte la iteración en teatro.

¿Cuánto cuesta un MVP?

Como referencia, un MVP bien acotado cuesta entre US$ 10.000 y US$ 30.000, dependiendo de la complejidad del flujo principal y de las integraciones necesarias. Proyectos más simples — una automatización, una web con backoffice — pueden partir más abajo, y plataformas complejas superan ese rango. Más importante que la cifra es cómo se paga: con hitos de entrega verificables, viendo software funcionando antes de cada pago, y nunca el total por adelantado. Tenemos más detalle de precios y modalidades en nuestras preguntas frecuentes.

¿Cuándo NO conviene hacer un MVP?

Ser honestos con esto es parte del método:

• Cuando ya existe un SaaS maduro que resuelve el 90% de tu necesidad. Configúralo, úsalo y valida tu negocio con eso. Construir software propio se justifica cuando el proceso es tu diferencia competitiva — lo explicamos en detalle en desarrollo de software a medida.
• Cuando el dominio no admite "mínimo". Procesos regulados, salud, o flujos donde un error compromete dinero de terceros: ahí el mínimo viable es más grande, y hay que dimensionarlo como tal desde el inicio.
• Cuando no hay quién mire la señal. Si nadie va a analizar los datos ni hablar con usuarios, el MVP pierde su propósito.
• Cuando tu problema es un sistema existente, no un producto nuevo. Si lo que te duele es una plataforma antigua que nadie quiere tocar, el camino es otro: modernización de sistemas legacy.

Si tienes una idea y quieres un diagnóstico honesto — incluyendo un "no te conviene un MVP" si ese es el caso — escríbenos: respondemos dentro de un día hábil.

Preguntas frecuentes

¿Se puede lanzar un MVP en menos de 6 semanas?

A veces, si el alcance es realmente pequeño: una automatización, una landing con un flujo de pago, un piloto interno. Pero bajo cierto umbral ya no estás validando un producto sino una maqueta. Para software con usuarios reales, medición y un flujo completo, 6 semanas es el piso realista.

¿Qué pasa si el MVP "fracasa"?

Un MVP que invalida la hipótesis no fracasó: te ahorró el costo de construir durante 12 meses algo que nadie quería. Ese es exactamente su trabajo. El fracaso real es gastar el presupuesto sin aprender nada — y eso pasa cuando se corta la medición, no cuando la hipótesis resulta falsa.

¿Qué stack tecnológico conviene para un MVP?

El que tu equipo domine y permita iterar rápido. Nosotros trabajamos con TypeScript, Vue/Nuxt, React, Laravel y PostgreSQL: tecnologías probadas y aburridas en el buen sentido. La innovación debe estar en el producto, no en la infraestructura.