Un MVP no es una versión barata de tu producto
Esta confusión cuesta más proyectos que cualquier problema técnico. Un MVP no es tu producto completo hecho a la mitad de calidad. Es un pedazo de tu producto, terminado bien, que sirve para contestar una pregunta concreta de negocio.
La diferencia se ve en el resultado. La versión completa a medias no le sirve a nadie: falla, frustra y no enseña nada porque los usuarios abandonan antes de llegar al valor. La rebanada bien terminada sí se usa, y lo que aprendes de esos usuarios vale más que seis meses de planeación.
Antes de escribir una línea, escribe la pregunta que quieres contestar. “¿Los dueños de salón van a cargar su catálogo si les tomo ocho minutos?” es una pregunta de MVP. “¿Funciona mi idea?” no lo es — no hay producto que conteste eso.
Si no puedes escribir la pregunta, el problema no es el presupuesto ni el proveedor. Todavía no sabes qué vas a construir.
Las trece semanas, sin adornos
Noventa días son trece semanas. Así se reparten cuando el proyecto va bien. Si tu proveedor no te puede dar un calendario de este nivel de detalle antes de firmar, no lo tiene.
| Semanas | Fase | Qué pasa | Qué te entregan |
|---|---|---|---|
| 1 – 2 | Diagnóstico | Se define la pregunta de negocio, se recorta el alcance y se cierra por escrito. Aquí se pelea, no después. | Alcance firmado, flujos, criterios de aceptación |
| 3 – 4 | Diseño | Pantallas reales, no wireframes bonitos. Se decide la arquitectura y qué piezas se compran en vez de construirse. | Diseño navegable, decisiones técnicas |
| 5 – 10 | Construcción | Seis semanas de desarrollo con entregas visibles cada semana. Si no ves avance semanal, hay un problema. | Ambiente de pruebas actualizado cada semana |
| 11 – 12 | Ajuste | Pruebas con usuarios reales, corrección de lo que se rompe, revisión de seguridad y SEO técnico. | Producto probado, reporte de seguridad |
| 13 | Lanzamiento | Salida a producción, monitoreo, entrega del repositorio y las cuentas. | Producto en la calle, código en tus manos |
Nota dónde está el peso: cuatro semanas antes de programar. A la gente le parece tiempo perdido y es exactamente al revés. Cada decisión que se toma en la semana 2 cuesta una conversación; la misma decisión en la semana 8 cuesta dos semanas de trabajo tirado.
Lo que sí cabe
Con el alcance cerrado, noventa días alcanzan para bastante más de lo que la gente cree:
- Un flujo completo de punta a punta, desde que alguien llega hasta que obtiene el valor. Completo, no simulado.
- Cuentas de usuario con registro, recuperación y sesiones. Un tipo de usuario, bien resuelto.
- Cobro en línea con una pasarela y un modelo de precio. Uno, no cuatro.
- Panel de administración para que operes sin llamarnos cada vez que cambia un dato.
- Contenido administrable por CMS, para que el texto y las imágenes no dependan de un desarrollador.
- Analítica que responda la pregunta que definiste. Sin eso, no vas a saber si funcionó.
- Producción de verdad: dominio, certificados, monitoreo, respaldos.
Lo que no cabe, y quien te diga que sí te está vendiendo un retraso
Esta es la sección que ningún proveedor publica. Nosotros sí, porque el alcance mal puesto es la causa número uno de proyectos que se van al doble.
| No cabe | Por qué | Qué hacer |
|---|---|---|
| Tres o más tipos de usuario | No cuesta el triple: cuesta más, porque hay que resolver todas las combinaciones de permisos entre ellos. | Elige el usuario que paga. Los demás en la ronda dos. |
| App nativa en iOS y Android | Son dos desarrollos y dos revisiones de tienda que no controlas. Apple puede tardar semanas. | Web app primero. La nativa cuando ya tengas usuarios. |
| Integración con un ERP heredado | Si no tiene API documentada, el descubrimiento solo puede tomar un mes. | Investigar antes de firmar. Exportación manual mientras. |
| Tiempo real para todo | Cambia la arquitectura completa, no una pantalla. | Solo si es el corazón del producto. |
| Migrar años de datos sucios | Limpiar información inconsistente es trabajo invisible y lento. | Migrar lo que se usa. El histórico después. |
| Modelos de IA entrenados a medida | Entrenar y evaluar necesita datos que casi nadie tiene todavía. | Usar modelos existentes por API. Casi siempre alcanza. |
Si tu lista de requisitos tiene tres o más renglones de esta tabla, no necesitas otro proveedor. Necesitas recortar, o necesitas seis meses. Ambas son respuestas legítimas; fingir que caben en noventa días no lo es.
Con quién empezar si no eres técnico
Antes de escribir una línea de código hay cuatro caminos, y la diferencia entre ellos no es el precio: es qué pasa cuando el proyecto crece o cuando alguien se va. Los costos son relativos a contratar un estudio.
| Con quién | Costo relativo | Cuándo conviene | El riesgo real |
|---|---|---|---|
| No-code | −70% a −90% | Validar si alguien quiere el producto, antes de invertir. | Techo bajo. Cuando el producto crece hay que rehacerlo, y migrar cuesta más que haber empezado bien. |
| Freelance | −30% a −50% | Alcance chico y bien definido, con alguien que ya conoces. | Punto único de falla. Si se enferma o cambia de trabajo, el proyecto se detiene y nadie más conoce el código. |
| Socio técnico (CTO) | Sin costo directo | El software ES el negocio y planeas levantar inversión. | Le entregas parte de la empresa para siempre. Y encontrar al correcto tarda más que construir el MVP. |
| Estudio o agencia | Base | Quieres una fecha, un alcance cerrado y el código en tus manos. | Varía enormemente entre proveedores. El riesgo es contratar por portafolio bonito sin verificar quién ejecuta. |
| Equipo interno | +80% a +200% el primer año | El software es el negocio y ya tienes tracción que sostener. | Reclutar toma meses y cuesta antes de producir una línea de código. |
Las tres cosas que sí puedes hacer tú, sin ser técnico, y que cambian la cotización que te den: escribir en una hoja qué problema resuelve y para quién, listar las tres pantallas sin las cuales no sirve, y decidir cómo vas a saber si funcionó. Quien te cotice sin pedirte eso, te está cotizando otra cosa.
Los tres errores que duplican el plazo
Cambiar de opinión después de la semana 4
No es que cambiar sea malo. Es que cada cambio después del diseño toca trabajo ya hecho. Un requisito nuevo en la semana 2 cuesta una conversación; el mismo en la semana 9 cuesta rehacer pantallas, datos y pruebas. Por eso el alcance se cierra por escrito: no para amarrarte, para que sepas cuánto cuesta soltarte.
No tener quién decida del lado del cliente
El asesino silencioso. Si cada duda tiene que pasar por un comité que se reúne los jueves, el proyecto avanza a velocidad de comité. Necesitas una persona que pueda decir sí o no en veinticuatro horas. Sin eso, no hay metodología que salve el calendario.
Confundir el MVP con el lanzamiento de marca
Se ve seguido: el producto está listo en la semana 10 y no sale porque falta el video, la campaña y la nota de prensa. El MVP existe para aprender de usuarios reales lo antes posible. Cada semana que no está en la calle es una semana sin aprender.
Qué tienes que hacer tú cada semana
Un MVP no se entrega, se construye contigo. Esto es lo que se espera de tu lado, y es menos de lo que temes pero más de lo que muchos proveedores admiten antes de firmar.
- Semanas 1 y 2: tres o cuatro sesiones de trabajo, de hora y media. Aquí se decide todo. Es la única fase que exige tu tiempo de verdad.
- Semanas 3 y 4: una revisión del diseño y una ronda de comentarios. Aquí todavía cambiar es barato.
- Semanas 5 a 10: media hora a la semana para ver el avance y contestar dudas. Nada más.
- Semanas 11 y 12: tú y unas cinco personas reales usando el producto. Es la fase que más se subestima y la que más valor devuelve.
- Semana 13: revisar que las cuentas queden a tu nombre y que el repositorio esté en tus manos.
Suma unas quince horas repartidas en tres meses. Si un proveedor te dice que no necesita nada de ti, está construyendo lo que él cree que quieres.
Cómo saber si tu MVP funcionó
Aquí se cae la mayoría, y no por razones técnicas. El producto sale, tiene usuarios, y nadie sabe decir si fue un éxito porque nunca se definió qué medir.
La trampa son las métricas que siempre suben: visitas totales, descargas, registros. Suben aunque el producto no sirva, porque las alimenta el marketing, no el valor. Sirven para un reporte, no para decidir.
Lo que sí decide son tres números, y se definen antes de construir:
- Activación: de cada cien que entran, cuántos llegan al momento donde el producto sirve. Si es menos de veinte, el problema está en el flujo, no en el tráfico.
- Retorno: cuántos vuelven a la semana siguiente sin que los persigas. Es la única métrica que no se puede fingir.
- La acción que importa: la que definiste en la pregunta de negocio. Cargar el catálogo, mandar la primera cotización, agendar la primera cita.
Si el MVP demuestra que la gente no quiere lo que construiste, funcionó. Te costó un trimestre en vez de dos años y el aprendizaje es real.
El fracaso de verdad es terminar los noventa días sin saber si funcionó. Eso pasa cuando nadie definió la pregunta, y ningún equipo de desarrollo puede arreglarlo por ti.
Cinco MVPs entregados y lo que tardaron
Alcance y tiempo reales. Los montos son de nuestros clientes, así que esos no van — pero el tiempo es la variable que te dice si un calendario es honesto.
Por qué garantizamos los noventa días
No es confianza en nuestra velocidad. Es que el plazo depende del alcance, y el alcance se cierra antes de empezar. Un calendario garantizado sobre un alcance abierto no es una garantía, es una apuesta — y la paga el cliente.
Por eso las dos primeras semanas son de diagnóstico y por eso se firma lo que entra y lo que no. Si a mitad del proyecto quieres algo que no estaba, se puede: se cambia por algo de valor equivalente, o se mueve la fecha. Lo que no hacemos es asentir y entregar tarde.
El proceso completo, fase por fase, está en el método. Si lo que te falta es el número, la guía de precios desarma el costo pieza por pieza.
Preguntas frecuentes
¿Qué es un MVP exactamente?
¿Se puede hacer un MVP en menos de 90 días?
¿Qué NO cabe en 90 días?
¿Cuánto cuesta un MVP?
¿Qué pasa si quiero cambiar algo a la mitad del proyecto?
¿El código es mío al terminar?
¿Qué necesito tener listo antes de empezar?
¿Incluye pruebas y seguridad o eso se cotiza aparte?
¿Y si mi producto necesita una app nativa?
¿Qué pasa después de los 90 días?
¿No está la tuya? Las 148 preguntas del sitio están agrupadas por tema en el índice de preguntas.
En una frase
Noventa días no es una promesa de velocidad, es una consecuencia de haber decidido. El proveedor que te acepta cualquier alcance con la misma fecha no está siendo flexible: está posponiendo la conversación difícil hasta que ya le pagaste.