"MVP" es una de esas siglas que se usan tanto que perdieron significado. Para mucha gente pasó a querer decir "versión barata", y ahí empieza el problema.
Un producto mínimo viable es un producto hecho para aprender algo. Esa es la definición útil, y de ella se desprende todo lo demás.
La pregunta que decide
No es "¿tengo presupuesto para el producto completo?". Es:
¿Sé con certeza que alguien va a usar esto?
Si la respuesta es no, hacé un MVP. Estás por invertir en una hipótesis y lo racional es comprarla barata.
Si la respuesta es sí, andá al producto completo. Un MVP es una etapa más, no un ahorro.
Cuándo la respuesta es "sí, ya está validado"
Más seguido de lo que se cree, y en esos casos el MVP no aporta:
Digitalizar un proceso interno que ya existe. Si tu equipo hoy lleva los pedidos en papel y eso duele, no hay hipótesis que probar. El proceso existe, los usuarios existen, el dolor está medido. Construí la solución.
Reemplazar un sistema que ya usás. Los usuarios ya están y ya saben lo que necesitan.
Un cliente que ya te lo pidió y lo va a pagar. No hay riesgo de demanda: hay un compromiso.
En estos casos hacer un MVP primero significa dos ciclos de desarrollo, dos capacitaciones y dos migraciones para llegar al mismo lugar.
Cuándo la respuesta es "no sé"
Un producto nuevo para un mercado nuevo. Creés que hay gente dispuesta a pagar. Todavía no lo sabés.
Una funcionalidad grande que nadie pidió explícitamente. "Los clientes seguro van a querer el módulo de reportes." ¿Seguro?
Un cambio de modelo de negocio. Pasar de vender por proyecto a vender suscripción cambia todo, y no sabés cómo va a responder tu base.
Acá el MVP tiene sentido: desde USD 5.000 y 8 a 12 semanas, contra los USD 30.000 y ocho meses del producto completo. Si la hipótesis era falsa, te enteraste barato.
Qué se recorta y qué no
Este es el punto donde más MVPs se arruinan.
Se recorta:
- Casos de uso. Uno solo, el central. Si es una app de reservas, reservar. No cancelar, no reprogramar, no recurrentes.
- Configurabilidad. Todo fijo. Nada de que el usuario elija.
- Automatización interna. Que el alta de usuarios la hagas vos a mano los primeros meses está perfecto, y además te obliga a hablar con cada uno.
- Panel de administración. Si sos vos el que administra, la base de datos alcanza.
- Escala. Construí para cien usuarios, no para cien mil.
No se recorta nunca:
- La seguridad. Contraseñas bien guardadas, conexiones cifradas, permisos que se respeten. Una filtración en un MVP se lleva puesta la idea entera.
- El manejo correcto de datos personales. Hay obligaciones legales que no tienen versión reducida.
- Que lo que existe funcione. Un MVP con dos pantallas que andan perfecto enseña algo. Uno con quince que fallan no enseña nada, porque no vas a saber si el usuario se fue por la idea o por los errores.
- Poder medir. Si no instrumentás qué hace la gente, no vas a aprender, y aprender era el único objetivo.
Dicho corto: un MVP es un producto chico, no un producto mal hecho.
El error más común
Es este: definir un alcance que no es mínimo y llamarlo MVP igual.
Pasa así. Se lista lo indispensable. Alguien dice que sin login no se puede. Otro que sin notificaciones no sirve. Otro que hay que poder exportar. Cada agregado es razonable solo.
Tres semanas después el "MVP" tiene once módulos, cuesta como un producto completo y tarda lo mismo. Pero como se llama MVP, se construyó con los atajos de un MVP.
Es el peor de los dos mundos: la inversión del producto completo con la calidad estructural del prototipo.
La prueba: si tu MVP tarda más de tres o cuatro meses, no es un MVP. Es un producto completo con otro nombre, y conviene tratarlo como tal.
Lo que hay que definir antes de arrancar
Un MVP sin esto es sólo un producto chico:
1. Qué hipótesis estás probando. Escribila: "creo que los estudios contables van a pagar USD 50 al mes por automatizar la carga de comprobantes."
2. Qué resultado la confirma. Un número, antes de empezar: "veinte estudios usándolo semanalmente a los tres meses". Si lo definís después, vas a acomodar la vara a lo que haya pasado.
3. Cuánto vas a esperar. Un plazo. Sin eso, un MVP tibio se estira para siempre.
4. Qué hacés si falla. ¿Pivotás, ajustás el segmento, abandonás? Pensarlo antes evita el sesgo de seguir tirando plata para justificar lo ya gastado.
¿Se puede escalar un MVP?
Depende de cómo se construyó, y acá hay una distinción importante entre dos tipos de atajo:
Atajos de alcance —procesos manuales, sin panel de admin, pocos casos de uso— se resuelven después sin drama. Eran deliberados.
Atajos estructurales —sin tests, con la lógica mezclada, con la base de datos mal modelada— sí obligan a rehacer. Y ese "ahorro" inicial se paga con intereses.
Un MVP bien hecho es un producto pequeño con cimientos sanos. Se extiende. Uno mal hecho es un prototipo que llegó a producción por accidente.
Al pedir un presupuesto, preguntá específicamente: ¿qué de esto habría que rehacer si funciona? La respuesta te dice qué tipo de MVP te están cotizando.
Los números
| MVP | Producto completo | |
|---|---|---|
| Costo | Desde USD 5.000 | Desde USD 15.000 – 30.000 |
| Plazo | 8–12 semanas | 4–12 meses |
| Objetivo | Aprender | Operar |
| Usuarios | Decenas | Los que haya |
| Si la hipótesis falla | Perdiste poco | Perdiste bastante |
Si estás en la duda, una charla suele alcanzar para resolverla: a veces la conclusión es que no necesitás un MVP porque no hay nada que validar, y eso te ahorra una etapa entera. Mirá cómo trabajamos los MVP para startups o contanos tu idea.
Preguntas frecuentes
¿Cuándo conviene un MVP y cuándo el producto completo?+
Un MVP cuando todavía no sabés si alguien va a usar lo que querés construir: sirve para aprender antes de invertir fuerte. El producto completo cuando la demanda ya está validada —por ejemplo, si vas a digitalizar un proceso interno que hoy existe y duele—, porque ahí no hay nada que validar y un MVP sólo agrega una etapa.
¿Cuánto cuesta un MVP?+
Desde USD 5.000 y de 8 a 12 semanas para un producto funcional listo para poner frente a usuarios reales. Si el número te parece alto para 'lo mínimo', probablemente el alcance que tenés en mente no sea mínimo: es un producto completo con otro nombre.
¿Qué se puede recortar en un MVP y qué no?+
Se recorta alcance funcional: menos casos de uso, menos configurabilidad, procesos manuales por detrás. No se recorta ni la seguridad, ni el manejo correcto de los datos de usuarios, ni que la parte que sí existe funcione bien. Un MVP es un producto chico, no un producto mal hecho.
¿Se puede escalar un MVP o hay que rehacerlo?+
Depende de cómo se construyó. Un MVP con arquitectura sensata se extiende sin problema; lo que se rehace después son las partes que deliberadamente se resolvieron a mano. Un MVP hecho con atajos estructurales sí hay que rehacerlo, y ese ahorro inicial termina saliendo caro.
¿Querés que esto funcione en tu empresa?
En Deepyze convertimos procesos manuales en sistemas que trabajan solos: automatización con IA, apps web y móviles, y software a medida. Contanos tu caso y en 24 hs tenés una propuesta concreta.
Sin compromiso · Respuesta en 24 hs · Equipo en tu mismo huso horario