Qué es un MVP: la definición real (y por qué tu idea no necesita una app completa)

La pregunta “qué es un MVP” tiene respuestas en todos lados, y casi todas son malas. Algunas hablan de “una versión inicial”, otras de “un producto mínimo”, otras de “un prototipo funcional”. La confusión es tal que la mayoría de los emprendedores termina construyendo una app completa creyendo que está haciendo un MVP.

Un MVP no es una versión chica del producto que tenés en la cabeza. Es otra cosa: una herramienta para aprender si tu idea le importa a alguien antes de quemar 6 meses de tu vida y los ahorros de tu familia. En este artículo te explico qué es un MVP de verdad, qué no es, y por qué tu idea —sí, esa que querés lanzar completa— no necesita una app completa todavía.

La definición que sí sirve

El término MVP (Minimum Viable Product, o producto mínimo viable) lo popularizó Eric Ries en The Lean Startup en 2011. Su definición original:

Tres palabras importan más que el resto: aprendizaje, validado y mínimo. Un MVP no se mide por features, ni por usuarios, ni por revenue. Se mide por cuánto te enseñó sobre tu cliente. Si construiste algo que no te enseña nada nuevo, no construiste un MVP — construiste una demo.

Qué NO es un MVP (y por qué la confusión sale cara)

El 80% de los emprendedores que nos contactan en FORJA llegan diciendo “quiero hacer un MVP” y describen un producto completo. La confusión más común es pensar que un MVP es:

• Una maqueta o prototipo. Un Figma bonito no es un MVP. Si nadie lo puede usar, no validás nada.
• Una versión beta. La beta es lo que viene después del MVP, no el MVP en sí.
• Tu producto pero feo. La idea de “MVP = versión fea” quedó en 2010. Hoy con Tailwind y shadcn/ui un MVP puede verse profesional sin esfuerzo extra.
• Un producto con menos features. Tener 7 features en vez de 10 no es un MVP, es un producto incompleto.
• Un Excel con macros. Salvo que un cliente te pague por usarlo. Ahí sí —y es un MVP brutalmente eficiente.

Por qué tu idea no necesita una app completa

Esta es la parte que más cuesta aceptar: cuando tenés una idea, todas las features se sienten críticas. Hablás con un amigo y le contás: — “es como Uber, pero para X. Tiene perfil de usuario, mensajería interna, sistema de reseñas, panel de administración, dashboard de métricas, integración con Google Calendar, notificaciones push, modo oscuro y...”.

En tu cabeza, todo eso es el producto. Sin alguna de esas cosas, tu idea no funcionaría. Y entonces empezás a construir todo junto. Resultado:

El error no está en construir —el error está en construir antes de saber si alguien lo quiere. Y la única forma de saberlo es lanzando algo, aunque sea diminuto, y mirando qué pasa.

3 ejemplos de MVPs que parecen mentira

Para entender hasta dónde puede ser mínimo un MVP, mirá estos casos reales. Ninguno tenía una app pulida. Todos validaron una hipótesis con clientes pagos.

Zappos: el MVP de la zapatería online

Antes de levantar millones, Nick Swinmurn quería validar si la gente compraría zapatos por internet (en 1999, una idea descabellada). ¿Construyó un e-commerce con stock, envíos y devoluciones? No. Sacó fotos de zapatos en zapaterías locales, las publicó en una página web básica, y cuando alguien compraba, él iba caminando, compraba el par, y lo enviaba. El MVP era él mismo. Hoy Zappos vale más de mil millones.

Fuga Restaurantes: el POS antes del POS

Cuando empezamos a construir Fuga (sistema POS para gastronomía), no arrancamos por la app. Arrancamos hablando con 12 dueños de restaurantes en Córdoba para entender qué los enloquecía. La respuesta más repetida: facturación AFIP. Construimos solo eso —un módulo de facturación electrónica que se integraba con su caja existente— y lo vendimos por USD 50/mes. 9 de 12 pagaron antes de tener app completa. Ese fue el MVP. Toda la suite (mesas, stock, delivery) vino después, financiada por esos 9 clientes.

Dropbox: el video que valió 70.000 emails

Drew Houston no podía construir Dropbox sin gastar millones (sincronización de archivos en 2007 era complejísimo). Hizo un video de 3 minutos mostrando cómo iba a funcionar el producto, lo subió a Hacker News, y al día siguiente tenía 70.000 emails en una lista de espera. Esa lista fue la prueba de que la idea importaba. El MVP fue un video, no software. Recién después empezó a programar.

Cómo saber si lo que tenés es un MVP o no

Hacete estas 5 preguntas. Si respondés “sí” a todas, es un MVP. Si respondés “no” a alguna, todavía no lo es.

Los 4 errores conceptuales más comunes

Qué hacer entonces si tenés una idea

El antídoto contra construir-de-más es brutalmente simple. Antes de escribir una línea de código, hacé este ejercicio en una hoja:

Cuando tengas esa única feature, el siguiente paso es construirla. Tenés varios caminos: hacerlo vos, no-code, freelancer, agencia, o una software factory que lo hace gratis como FORJA. La diferencia entre opciones la cubrimos a fondo en la guía completa de cómo construir un MVP.

Resumen práctico

Si te tenés que ir con una sola idea de este artículo, que sea esta: un MVP no es una versión chica de tu producto, es un experimento para aprender. Si lo que estás construyendo no te enseña algo cada semana, dejá de construir y volvé al pizarrón.

Tu idea no necesita una app completa. Necesita una respuesta a la pregunta “¿le importa a alguien?”. Esa respuesta vale más que cualquier funcionalidad bonita que tengas en la cabeza.

En FORJA construimos MVPs gratis en 7 días. Si tenés una idea y no sabés por dónde empezar, te ayudamos a definir cuál es esa única feature crítica y la construimos juntos. Si te sirve, seguimos. Si no, te quedás con el código y no debés nada.