La respuesta corta
MVP son las siglas de Minimum Viable Product: producto mínimo viable. Es la versión más pequeña de un producto que ya resuelve un problema real para alguien, y que se pone en manos de usuarios de verdad para aprender algo que no se puede aprender de otra forma.
Las dos palabras que más se malinterpretan son las dos primeras. Mínimo no significa a medias: significa acotado. Viable no significa que funcione en una demo: significa que alguien puede usarlo para lo que necesita sin que le pidas disculpas.
Si el producto no llega a manos de nadie, no es un MVP. Es un prototipo, y está bien que lo sea —pero es otra cosa.
Qué significa cada letra
| letra | significa | lo que suele entenderse mal |
|---|---|---|
| M — Minimum | Acotado al alcance más pequeño que permite aprender | «barato» o «rápido» |
| V — Viable | Utilizable de verdad por alguien que tiene el problema | «que compile» |
| P — Product | Producto, con su experiencia y su soporte | «demo» o «prueba de concepto» |
Y una aclaración que hace falta más de lo que parece: en deporte, MVP significa Most Valuable Player, jugador más valioso. No tiene relación con esto. Si has llegado buscando eso, este no es tu artículo.
Para qué sirve de verdad
Un MVP no existe para ahorrar dinero. Existe para reducir incertidumbre antes de gastarlo.
La pregunta que responde no es «¿podemos construirlo?» —casi siempre se puede— sino «¿le importa a alguien lo suficiente como para cambiar lo que hace hoy?». Esa segunda pregunta no la contesta ninguna reunión, ninguna encuesta y ningún informe de mercado. La contesta gente usando algo.
De ahí sale el criterio para decidir qué entra y qué no: entra lo que hace falta para que la pregunta quede respondida; sale todo lo demás. No lo que es fácil, ni lo que ilusiona al equipo, ni lo que pidió el inversor en la última reunión.
Qué NO es un MVP
Confundir estas cuatro cosas es el error más caro que vemos, porque cada una responde una pregunta distinta:
- Prototipo. Sirve para validar una interfaz o un flujo con usuarios, normalmente sin código funcional detrás. Es más barato y más rápido que un MVP, y muchas veces es lo que de verdad hacía falta.
- Prueba de concepto. Responde «¿esto es técnicamente posible?». Vive en el equipo técnico y no la ve un usuario.
- Piloto. Es un producto ya construido puesto a prueba con un grupo acotado. Va después del MVP, no antes.
- Versión 1 recortada. Es el antipatrón: coger el producto completo que se quería hacer y quitarle cosas hasta que quepa en el presupuesto. El resultado no aprende nada y encima decepciona.
La diferencia práctica: un MVP se diseña desde la pregunta hacia atrás. Una versión recortada se diseña desde el producto hacia abajo.
Cuándo tiene sentido construir uno
Cuando la incertidumbre está en la demanda. No sabes si el problema duele lo bastante, o si tu forma de resolverlo es la que la gente quiere. Ahí un MVP paga.
Cuando el coste de equivocarse es alto. Cuanto más caro sea el producto completo, más justifica gastar una fracción en averiguar si merece la pena.
Cuando puedes definir qué sería un fracaso. Si no eres capaz de decir de antemano qué resultado te haría parar, no vas a aprender nada: vas a interpretar cualquier dato como confirmación.
Cuándo NO tiene sentido
Y esto se dice mucho menos:
- Cuando la incertidumbre es técnica, no de mercado. Si sabes que hay demanda y la duda es si el sistema aguanta, lo que necesitas es una prueba de concepto.
- Cuando el mínimo viable no es viable. Hay productos que por debajo de cierto umbral no sirven para nada: un sistema de pagos a medias no es un MVP, es un problema. Igual con salud, banca o cualquier cosa con requisitos regulatorios.
- Cuando ya tienes el cliente. Si construyes para una empresa concreta que ya firmó, no estás validando demanda: estás entregando un proyecto. Llamarlo MVP solo sirve para justificar recortes.
- Cuando lo que hay que validar cabe en una conversación. Veinte llamadas con clientes potenciales cuestan una semana y a veces responden lo mismo.
Cómo se acota uno bien
El método que usamos es empezar por el final: escribe la frase que quieres poder decir dentro de tres meses.
«Cuarenta empresas del sector han subido su catálogo y doce lo actualizan cada semana» es una frase útil. «Hemos lanzado la plataforma» no lo es, porque se cumple hagas lo que hagas.
Con esa frase escrita, cada funcionalidad se contesta sola: ¿esto es necesario para que la frase pueda ser cierta? Si la respuesta es no, fuera. Da igual lo barata que sea de hacer: cada cosa que entra alarga el calendario y diluye lo que vas a aprender.
Después, tres decisiones que suelen ahorrar meses:
- Lo manual antes que lo automático. Si el flujo lo puede resolver una persona detrás de una pantalla las primeras semanas, resuélvelo así. Automatizar antes de saber si el flujo es el bueno es construir dos veces.
- Comprar antes que construir, en todo lo que no sea el núcleo. Autenticación, pagos, mensajería y analítica tienen soluciones que funcionan; escribirlas tú no aporta aprendizaje.
- Instrumentar desde el día uno. Un MVP sin medición es una opinión con código. Antes de lanzar hay que saber qué se va a mirar y qué número movería la decisión.
Cuánto cuesta y cuánto tarda
Depende del alcance, y quien te dé un número sin conocerlo te está vendiendo algo. Lo que sí podemos decir es cómo se mueve el rango.
En Dribba los proyectos parten de 30.000 €, y un MVP se acota normalmente cerca de ese suelo cuando la pregunta está bien definida y hay pocas integraciones externas. Lo que dispara el presupuesto casi nunca es el número de pantallas: es cuántos sistemas ajenos hay que integrar y qué nivel de cumplimiento normativo aplica.
En calendario, la acotación funcional lleva una o dos semanas —y es donde se decide casi todo— y una primera versión en producción suele estar entre ocho y dieciséis semanas.
Si quieres el desglose completo de qué mueve cada euro, está en nuestra guía sobre cuánto cuesta crear una app.
Qué hacer con el resultado
Un MVP termina en una de tres conclusiones, y las tres son buenas:
- Funciona. Hay uso repetido y gente que se queja cuando se cae. Toca invertir en producto: escalar lo que se hizo a mano, cubrir los casos que dejaste fuera y arreglar la deuda que asumiste a conciencia.
- No funciona, y sabes por qué. El problema existe pero tu forma de resolverlo no era la buena. Es el caso más valioso: has gastado una fracción del presupuesto y sabes hacia dónde girar.
- No funciona y no sabes por qué. Aquí el MVP estaba mal planteado: o no se midió, o entraron demasiadas cosas y no se puede aislar qué falló. Es el único desenlace que hay que evitar, y se evita en la acotación, no en el desarrollo.
Lo que nosotros hacemos con esto
Acotamos la pregunta antes de escribir código, y decimos que no cuando lo que hace falta es un prototipo o una conversación con clientes en vez de un desarrollo. Después construimos con equipo sénior propio —sin subcontratas— y dejamos el sistema instrumentado para que la decisión siguiente se tome con datos.
Si estás en ese punto, el detalle de cómo trabajamos está en desarrollo de software a medida y en product discovery.
