Prototipo o MVP: cuál necesitas antes de gastar en desarrollo
La mayoría de los que piden un MVP todavía no lo necesitan. Cómo saber cuál de los dos te toca, qué cuesta cada uno y qué pregunta responde antes de escribir código.
Cada vez que alguien me escribe pidiendo presupuesto para un MVP, la primera pregunta que hago es qué quiere aprender con él. Aproximadamente la mitad de las veces, la respuesta describe algo que un prototipo responde en cinco semanas y por una décima parte del dinero.
No es un problema de vocabulario. Es que “MVP” se ha convertido en la manera por defecto de decir “la primera versión”, y eso hace que mucha gente construya software durante tres meses para averiguar algo que podría haber averiguado en tres semanas.
Cada uno responde una pregunta distinta
Esta es toda la decisión, y cabe en dos líneas.
El prototipo responde: ¿lo quieren y lo entienden? Se lo enseñas a diez personas del perfil correcto, las ves usarlo, y sales sabiendo si el concepto se sostiene y dónde se atascan.
El MVP responde: ¿lo siguen usando? Eso solo se puede medir con producto real, datos reales y semanas de por medio. Ninguna cantidad de prototipo te lo va a decir.
La consecuencia práctica es que si todavía no sabes si lo quieren, un MVP es la forma más cara posible de averiguarlo.
Qué es cada cosa, en concreto
| Prototipo | MVP | |
|---|---|---|
| Qué es | Pantallas conectadas que se navegan | Software funcionando |
| Guarda datos | No | Sí |
| Quién lo usa | Diez personas en una sesión contigo | Clientes en su trabajo diario |
| Tiempo | 4 a 6 semanas | 3 a 6 meses |
| Coste típico | 4.000 a 8.000 € | 25.000 € para arriba |
| Cambiarlo cuesta | Un día | Una sprint y una discusión |
| Responde | Si lo quieren | Si lo retienen |
La fila que decide es la penúltima. Mientras estás aprendiendo, quieres que cambiar sea barato. En cuanto el cambio cuesta una sprint, dejas de probar cosas y empiezas a defender lo que ya hiciste.
El test de las tres preguntas
Si dudas cuál te toca, contesta estas tres:
- ¿Hay alguien pagando hoy por resolver este problema, aunque sea a mano? Si no, necesitas prototipo. La demanda no está validada.
- ¿Sabes exactamente qué tiene que hacer el producto, pantalla a pantalla? Si no, necesitas prototipo. Vas a descubrirlo dibujando, y descubrirlo en código cuesta veinte veces más.
- ¿Lo que quieres medir requiere que alguien lo use durante semanas? Si sí, y las dos anteriores están resueltas, entonces sí es un MVP.
Dos noes de tres significa prototipo. En seis años no me he encontrado una excepción a esa regla que no fuese alguien con presupuesto de sobra y prisa.
El coste de saltarse el paso
El daño no es el dinero del desarrollo, aunque sea el que se ve. Es que un MVP construido sin validar arrastra tres costes que aparecen después.
El coste de arrastre. El código que escribiste para una hipótesis equivocada no se tira, se parchea. Seis meses después el producto tiene una estructura que responde a una idea que ya nadie defiende.
El coste de la evidencia falsa. Un MVP con veinte usuarios que no retienen no te dice si el problema era el concepto, la ejecución o el segmento. Un prototipo probado con diez personas sí te lo dice, porque estás delante viendo dónde dudan.
El coste de la conversación interna. Cuando ya hay tres meses de desarrollo, cambiar de rumbo deja de ser una decisión de producto y pasa a ser una discusión sobre quién se equivocó.
Lo que sí hay que hacer antes de las dos cosas
Ni el prototipo ni el MVP arreglan un problema mal definido. Antes de dibujar nada hace falta saber qué problema estás resolviendo, para quién y qué pasa hoy cuando ocurre. Eso es discovery, cuesta un par de semanas y es lo que evita construir bien la cosa equivocada. Lo cuento en qué es un sprint de discovery.
Con eso hecho, la decisión entre prototipo y MVP deja de ser una cuestión de presupuesto y pasa a ser lo que debería ser: qué necesitas aprender ahora.
Si estás en el punto de tener que decidirlo, el servicio de prototipo validable cubre exactamente esas cinco semanas, con una ronda de cambios después de las primeras pruebas con gente real. Y si lo que tienes todavía es un problema sin aterrizar, empieza por la definición para desarrollo.
¿Qué diferencia hay entre un prototipo y un MVP?
Un prototipo simula el producto sin funcionar por dentro: se navega, se enseña y se prueba, pero no guarda datos ni tiene lógica real. Un MVP es producto de verdad, con la funcionalidad mínima, que la gente usa en su trabajo. El prototipo responde si lo quieren; el MVP responde si lo siguen usando.
¿Cuánto cuesta un prototipo frente a un MVP?
Un prototipo de alta fidelidad de un flujo completo se mueve entre 4.000 y 8.000 € y cinco semanas. Un MVP real en código rara vez baja de 25.000 € y tres meses, y en España las agencias publican rangos de 5.000 a 150.000 € según el alcance. La diferencia de un orden de magnitud es justo lo que estás arriesgando si te saltas el prototipo.
¿Un prototipo en Figma sirve para enseñárselo a un inversor?
Sí, y es uno de sus dos usos principales. Un prototipo de alta fidelidad se navega como el producto real y aguanta una demo perfectamente. El otro uso es servir de especificación para el equipo que lo va a construir, que suele ser el que más dinero ahorra.
¿Cuándo tiene sentido saltarse el prototipo e ir directo al MVP?
Cuando ya tienes clientes pagando por el problema resuelto de otra forma, normalmente a mano o con hojas de cálculo. Ahí la demanda está validada y lo que necesitas medir es el uso continuado, que un prototipo no puede darte.