≡En resumen
- Un MVP sirve para validar hipótesis de negocio (problema, cliente, disposición a pagar) con el menor esfuerzo posible.
- No todo MVP es software: una landing, un vídeo o un servicio manual pueden validar la demanda antes de programar.
- El alcance se define por la hipótesis que quieres comprobar, no por la lista de funciones que te gustaría tener.
- Antes de lanzarlo fija métricas de éxito: activación, retención, conversión a pago o el test del 40 % de Sean Ellis.
- Un MVP de código para una app o un SaaS suele medirse en semanas o pocos meses, no en años.
01 ¿Qué es un MVP o producto mínimo viable?
MVP son las siglas de Minimum Viable Product, en español producto mínimo viable. Es la primera versión de un producto con lo justo para que un grupo de usuarios reales lo use y te dé información fiable sobre si vas por buen camino. La clave está en las dos palabras: mínimo, porque cada función extra retrasa el aprendizaje, y viable, porque tiene que resolver el problema lo bastante bien como para que alguien lo use de verdad.
El término lo acuñó Frank Robinson en 2001 y lo popularizaron Steve Blank y Eric Ries con la metodología Lean Startup. En appyweb lo aplicamos a diario: antes de programar un producto nuevo, sea para un cliente o uno de nuestros SaaS verticales, acotamos qué hipótesis tiene que demostrar la primera versión.
| Concepto | Pregunta que responde | Quién lo usa | ¿Es funcional? |
|---|---|---|---|
| Prueba de concepto (PoC) | ¿Es técnicamente posible? | El equipo técnico | Parcialmente, solo la parte crítica |
| Prototipo | ¿Se entiende y se usa bien? | Usuarios de prueba en sesiones guiadas | No: simula pantallas y flujos |
| MVP | ¿Lo quieren y pagarían por ello? | Primeros clientes reales | Sí, en lo esencial |
| Producto completo | ¿Cómo escalamos y retenemos? | Todo el mercado objetivo | Sí, con funciones secundarias |
02 Para qué sirve un MVP y por qué no deberías saltártelo
Casi todos los productos que fracasan no lo hacen por un error técnico, sino porque resuelven un problema que no duele lo suficiente o porque el cliente no está dispuesto a pagar lo que cuestan. El MVP pone esas dudas a prueba cuando todavía es barato equivocarse.
43 %
de las startups analizadas cerró por un mal encaje producto-mercado
Fuente: CB Insights, The top 9 reasons startups fail (431 startups con capital riesgo cerradas desde 2023)
70 %
se quedó sin capital, casi siempre como consecuencia final de los otros problemas
Fuente: CB Insights, The top 9 reasons startups fail
Validar el problema
Compruebas que el dolor existe, que es frecuente y que tu cliente ideal lo reconoce sin que se lo expliques.
Validar la disposición a pagar
Una preventa, un plan de pago o una lista de espera con compromiso valen más que cien encuestas de intención.
Aprender qué construir
El uso real te dice qué funciones importan y cuáles puedes olvidar, antes de invertir en ellas.
Negociar con datos
Ante socios, inversores o tu propio comité, métricas de uso reales pesan más que cualquier plan de negocio.
03 Tipos de MVP: no todos llevan código
El error más caro es pensar que un MVP es siempre una aplicación. Según lo que necesites validar, a veces basta con una página, un vídeo o hacer el servicio a mano durante unas semanas. Escoge el tipo más barato que te dé una respuesta fiable.
| Tipo | Qué es | Qué valida | Esfuerzo |
|---|---|---|---|
| Landing o smoke test | Una página que presenta la propuesta y pide registro, reserva o preventa | Interés y mensaje | Muy bajo |
| Vídeo o demo | Un vídeo que muestra cómo funcionaría el producto | Interés en una solución difícil de explicar | Bajo |
| Concierge | Prestas el servicio a mano a unos pocos clientes, sabiendo ellos que es manual | Problema, proceso y precio | Bajo en dinero, alto en tiempo |
| Mago de Oz | El cliente ve un producto automático, pero detrás lo hace una persona | Experiencia de uso y demanda | Medio |
| No-code | Producto funcional montado con herramientas sin programar | Uso real y retención inicial | Medio |
| MVP de código | Primera versión programada, con lo esencial para usarlo y cobrar | Retención, conversión a pago y escalabilidad | Alto |
Dropbox publicó en marzo de 2008 un vídeo de unos tres minutos que mostraba cómo sincronizaría archivos entre dispositivos. Su lista de espera de la beta pasó de 5.000 a 75.000 personas prácticamente de la noche a la mañana, meses antes del lanzamiento público en septiembre de ese año.
Airbnb empezó en octubre de 2007, cuando Brian Chesky y Joe Gebbia alquilaron colchones hinchables en su piso de San Francisco a asistentes de un congreso de diseño que no encontraban alojamiento. Validaron que había gente dispuesta a dormir en casa de un desconocido antes de construir la plataforma.
04 Cómo hacer un MVP paso a paso
Este es el proceso que seguimos para definir y lanzar un MVP, tanto si es una app móvil como una plataforma web. Si tu idea es un producto por suscripción, complétalo con nuestra guía sobre cómo crear un SaaS, que cubre el modelo de negocio, el stack y los aspectos legales.
-
1
Escribe la hipótesis de riesgo
Una frase comprobable: «Las clínicas de fisioterapia de 2 a 5 profesionales pagarían 60 € al mes por dejar de gestionar la agenda por WhatsApp». Lo que más miedo te da que sea falso es lo primero que debe validar el MVP.
-
2
Define el cliente pionero
No el mercado entero, sino el perfil que tiene el problema más agudo y tolera un producto incompleto a cambio de resolverlo antes.
-
3
Habla con 10-15 clientes potenciales
Pregunta por cómo resuelven hoy el problema, cuánto les cuesta y qué han probado. Si nadie ha intentado solucionarlo, quizá no duele tanto.
-
4
Fija el criterio de éxito antes de lanzar
Por ejemplo: 10 clientes de pago en 60 días o un 40 % de usuarios activos a la cuarta semana. Sin un umbral previo, cualquier resultado parecerá bueno.
-
5
Recorta el alcance a un solo flujo
Identifica el recorrido mínimo que entrega el valor principal, de principio a fin, y deja todo lo demás para después.
-
6
Construye con el tipo de MVP más barato que sirva
Landing, concierge, no-code o código: elige según la hipótesis, no según lo que te apetezca construir.
-
7
Lanza a un grupo reducido y mide
Trabaja con pocos usuarios muy cerca: observa cómo lo usan, instrumenta los eventos clave y habla con ellos cada semana.
-
8
Decide: perseverar, pivotar o parar
Con los datos en la mano, sigue si superas el umbral, cambia una pieza de la hipótesis si fallas por poco o detente si no hay señal.
05 Cómo definir el alcance del MVP sin quedarte corto ni pasarte
El alcance es donde se ganan o se pierden meses. La técnica que mejor nos funciona es clasificar cada función con el método MoSCoW y quedarse solo con los «Must» que sostienen el flujo principal. Si una función no ayuda a validar la hipótesis ni es imprescindible para usar o cobrar, espera.
| Prioridad | Funciones | Por qué |
|---|---|---|
| Must (entra) | Alta de negocio, agenda, reserva online, aviso por email, cobro de la suscripción | Es el flujo que entrega el valor y el que demuestra que pagan |
| Should (si sobra tiempo) | Recordatorios automáticos, varias sedes | Mejoran la retención, pero no validan la hipótesis |
| Could (siguiente versión) | Estadísticas avanzadas, integraciones contables | Solo tiene sentido con clientes que ya usan el producto |
| Won't (fuera) | App nativa propia, marketplace de profesionales, idiomas | Otro producto, otra hipótesis |
- ✓Registro y acceso seguros: sin ellos no hay usuarios reales.
- ✓El flujo principal completo, aunque sea con un diseño sencillo.
- ✓Forma de cobrar o de registrar el compromiso del cliente.
- ✓Analítica de eventos clave desde el primer día.
- ✓Un canal directo de feedback: chat, email o llamada semanal.
- ✓Datos separados por cliente si es un producto multi-empresa.
- ✓Textos legales y tratamiento de datos conforme al RGPD.
En un producto por suscripción, «mínimo» no significa renunciar a cobrar ni a aislar los datos de cada cliente: rehacer esa base después cuesta más que hacerla bien al principio. Por eso en nuestros proyectos de desarrollo de SaaS el MVP ya incluye registro, planes, cobros recurrentes y arquitectura multi-cliente, aunque el resto de funciones sea muy austero.
06 MVP de una app móvil: qué cambia
Un MVP de app tiene dos particularidades: la publicación en las tiendas añade tiempo y requisitos, y cada plataforma (iOS y Android) multiplica el trabajo si se programa por separado. Antes de decidir, repasa los tipos de apps: nativa, híbrida, web app o PWA, porque muchas hipótesis se validan antes y más barato con una aplicación web.
Empieza por web si puedes
Si el uso es de escritorio o esporádico, una web app o PWA valida igual y evita la revisión de las tiendas.
Multiplataforma para iOS y Android
Con Flutter o React Native un único código sirve a las dos plataformas, algo muy útil en la fase de MVP.
Nativa solo si hace falta
Cuando el valor depende del hardware (Bluetooth, cámara avanzada, segundo plano intensivo) o del máximo rendimiento.
Backend gestionado
Servicios como Firebase, AWS o Google Cloud dan autenticación, base de datos y notificaciones sin montar servidores desde cero.
En nuestro servicio de desarrollo de aplicaciones móviles solemos arrancar con un prototipo navegable y, cuando el flujo está validado, programamos el MVP en multiplataforma para llegar a iOS y Android con un solo equipo. Si dudas entre las dos opciones más usadas, te ayudamos a decidir entre Flutter o React Native.
07 Métricas para saber si tu MVP funciona
Las métricas de vanidad (visitas, descargas, registros) suben solas con un poco de publicidad y no dicen nada del valor del producto. Mide lo que hacen los usuarios después de registrarse y, sobre todo, si vuelven y pagan.
| Métrica | Qué mide | Señal de alarma |
|---|---|---|
| Activación | Porcentaje de registros que completan la acción clave (primera reserva, primer informe) | Muchos registros y casi nadie llega al valor |
| Retención por cohortes | Qué parte de cada grupo de alta sigue usando el producto a la semana 1, 4 y 8 | La curva cae a cero en lugar de estabilizarse |
| Conversión a pago | Usuarios de prueba que pasan a un plan de pago | Usan el producto gratis, pero nadie paga |
| Test de Sean Ellis | Porcentaje que se sentiría «muy decepcionado» si el producto desapareciera | Menos del 40 %, el umbral que Ellis asocia al encaje producto-mercado |
| Bajas | Clientes que cancelan cada mes y por qué | Se van en el primer mes sin haber usado el producto |
08 Cuánto cuesta y cuánto tarda un MVP
No hay un precio de MVP: depende del tipo, del número de flujos, de las integraciones y de si hay que publicar en tiendas. Estas horquillas son orientativas del mercado en España para proyectos encargados a un equipo profesional, no una tarifa nuestra; sirven para saber en qué orden de magnitud te mueves.
| Tipo de MVP | Coste orientativo | Plazo orientativo | Qué lo encarece |
|---|---|---|---|
| Landing con test de demanda | De unos cientos a 2.000 € más el presupuesto de anuncios | 1-2 semanas | Copy, diseño a medida, campañas |
| Concierge o Mago de Oz | Sobre todo tu tiempo y herramientas estándar | 2-6 semanas de operación | Volumen de clientes atendidos a mano |
| No-code | 3.000-15.000 € | 3-8 semanas | Lógica compleja, automatizaciones, integraciones |
| Aplicación web o SaaS programado | 15.000-60.000 € | 2-4 meses | Roles, cobros, multi-cliente, integraciones, IA |
| App móvil iOS y Android | 20.000-80.000 € | 3-5 meses | Funciones de hardware, backend propio, publicación |
09 Errores habituales al lanzar un producto mínimo viable
Construir antes de hablar con clientes
Semanas de desarrollo para descubrir que el problema no era el que creías. Diez entrevistas lo habrían detectado.
Un MVP que no es mínimo
Añadir «solo una función más» retrasa el lanzamiento y hace imposible saber qué parte funciona.
Un MVP que no es viable
Si falla, es lento o confuso, el usuario lo abandona y concluyes que no hay mercado cuando el problema era la ejecución.
No poder cobrar
Sin un mecanismo de pago no validas lo más importante: que alguien valora el producto lo suficiente como para pagarlo.
Medir sin criterio previo
Si no fijas un umbral antes, interpretarás cualquier dato a tu favor.
Tratarlo como definitivo
El MVP es un punto de partida: planifica desde el principio las iteraciones y el presupuesto posterior.
Cuando el MVP ya demuestra que hay demanda, llega la fase de convertirlo en producto: rendimiento, seguridad, diseño cuidado, integraciones y un modelo de ingresos claro. Para esa decisión te servirá nuestra guía sobre la monetización de una app o proyecto web y, si el producto va a crecer sobre el navegador, un equipo de desarrollo de aplicaciones web a medida que lo prepare para escalar.
Preguntas frecuentes
Es la versión más sencilla de un producto que puedes poner en manos de clientes reales para comprobar si resuelve su problema y si pagarían por ello. Su objetivo es aprender con el menor esfuerzo, no lanzar el producto definitivo.
Es la traducción de Minimum Viable Product. Mínimo porque incluye solo lo imprescindible para validar una hipótesis, y viable porque resuelve el problema lo bastante bien como para que la gente lo use de verdad.
Puedes validar con una landing y una lista de espera o preventa, prestando el servicio a mano a los primeros clientes (MVP concierge) o montando el producto con herramientas no-code. Cuando el experimento funcione y la operación manual no dé más de sí, toca programarlo.
El prototipo simula pantallas y flujos para comprobar si el producto se entiende y se usa bien, normalmente en sesiones de prueba. El MVP es funcional y lo usan clientes reales en su día a día, para validar si lo quieren y lo pagan.
Como orientación de mercado en España, un MVP programado para iOS y Android suele moverse entre 20.000 y 80.000 euros, según funciones, backend e integraciones. Una web app o PWA suele ser más barata y rápida de validar.
Una landing de validación puede estar en una o dos semanas y un MVP no-code en uno o dos meses. Un MVP programado de aplicación web, app o SaaS suele llevar entre dos y cinco meses, según el alcance.
El flujo principal que entrega valor, registro y acceso, cobro de la suscripción, datos separados por cliente y analítica de uso. El resto de funciones puede esperar a que los primeros clientes confirmen qué necesitan.
Cuando superas el criterio de éxito que fijaste antes de lanzarlo: clientes de pago, retención estable por cohortes o al menos un 40 % de usuarios que estarían muy decepcionados si el producto desapareciera.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗
