¿Debe su startup empezar por una prueba de concepto, un prototipo o un MVP?

Imagine que tiene una idea, quizá una demo, y está hablando con empresas de desarrollo. Una le propone una prueba de concepto, otra un prototipo y una tercera un MVP, un producto mínimo viable. Cada uno responde a una pregunta distinta.

Si duda de que una parte técnica pueda funcionar, haga una prueba de concepto: una versión pequeña y funcional solo de esa parte. Si duda de que la gente vaya a entender el producto, haga un prototipo, un modelo en el que se puede hacer clic. Si las dos cosas están claras, construya el MVP, la primera versión que pueden usar usuarios reales.

Cuando la elección no esté tan clara, la plantilla de una página que encontrará más abajo le ayuda a decidir.

¿Qué diferencia hay entre una prueba de concepto (PoC), un prototipo y un MVP?

Cada uno responde a su propia pregunta y se dirige a su propio público.

Una prueba de concepto pone a prueba la única parte de la que depende su idea, como un flujo de pago, una importación de datos o una respuesta de IA que tiene que ser correcta. Puede tener un aspecto tosco, porque su único trabajo es demostrar que esa parte funciona.

Un prototipo enseña el producto a la gente antes de que haya mucho sistema real detrás: pantallas en las que se puede hacer clic o bocetos en papel. Nielsen Norman Group (NN/g), una firma de investigación en experiencia de usuario, describe el prototipo como una hipótesis, un diseño candidato que se pone a prueba viendo cómo lo usa la gente.

Un MVP es la primera versión que usan usuarios reales para la tarea que promete. El término se popularizó después de que Eric Ries lo describiera en su libro The Lean Startup. Ries define el MVP como la versión que permite a un equipo aprender lo máximo sobre sus clientes con el mínimo esfuerzo.

¿Por cuál debe empezar?

Empiece por lo que responda a la pregunta que podría acabar con su proyecto, y sáltese la etapa cuya pregunta ya tenga respuesta.

Una parte técnica podría no funcionar. Haga una prueba de concepto solo de esa parte. Habrá cumplido su función cuando la parte arriesgada funcione con entradas reales y usted pueda contar el resultado en una frase.

No está seguro de que la gente entienda el flujo. Basta con un prototipo. Déselo a alguien que no lo haya visto nunca, dígale cuál es la tarea principal y observe en lugar de hablar, como aconseja NN/g. Para un producto con IA, pruebe un test del Mago de Oz: una persona hace el papel de la IA entre bastidores antes de que exista ninguna IA, un método que describe NN/g. Tendrá su respuesta cuando alguien nuevo termine la tarea principal sin ayuda, o cuando vea exactamente dónde se detiene.

Las dos cosas están claras. Construya el MVP: un flujo principal, las herramientas de administración para operarlo y la analítica que muestra si funciona. Después del lanzamiento, consulte la analítica para ver si la gente lo usa para la tarea que promete.

Ninguna de las dos está clara. Empiece por la parte técnica. Un prototipo de algo que no se puede construir no pone a prueba nada que le sirva.

Ya tiene una demo. Trátela como su prototipo. Observe cómo la usa alguien nuevo para responder a la pregunta del flujo y pase después a la técnica.

Cuatro de nuestros proyectos muestran adónde llevó una primera versión.

Las historias completas están en nuestros casos sobre el servicio de intercambio de criptomonedas de Swipelux y la plataforma de operaciones hoteleras de Levee.

Nuestra página de desarrollo de MVP describe las etapas de la prueba de concepto a producción, y cada una responde a una pregunta antes de que usted pague por la siguiente. Un MVP nos lleva de 2 días a unas semanas, según su complejidad, y puede ser una app móvil, una aplicación web, una aplicación de escritorio o una extensión de Chrome.

¿Necesita las tres?

No. Sáltese cualquier etapa cuya pregunta ya tenga respuesta y mantenga cada una pequeña. Un MVP puede no ser más que una página de aterrizaje o un servicio que parece automático pero se lleva a mano; el glosario de la Agile Alliance admite los dos casos.

Ries cuenta que su equipo dedicó dos semanas a una funcionalidad que nadie quería, cuando una simple prueba de humo con AdWords lo habría mostrado mucho antes. Así que, antes de pagar cualquier desarrollo, pregúntese si una página, un formulario o un servicio manual responderían a su pregunta.

Aun así, lo pequeño tiene un límite: un MVP tan escaso que no puede mostrar si los clientes lo usarán es un error que el mismo glosario señala.

¿Por qué «MVP» significa cosas distintas para distintas personas?

El término se usa para desarrollos muy diferentes. Marty Cagan, de Silicon Valley Product Group, escribió en 2011 que abarca desde el experimento más pequeño hasta una visión de producto hecha realidad. Así que dos presupuestos para «un MVP» pueden describir trabajos distintos. Pregunte a qué se refiere cada empresa.

Anote cuál necesita antes de comparar presupuestos y pida a cada empresa que presupueste exactamente eso.

¿Y si su prototipo ya parece terminado?

Un prototipo pulido parece software en funcionamiento, y eso tienta a lanzarlo. NN/g advierte de que, cuando un diseño está muy pulido, a un directivo le resulta fácil decir «esto tiene buena pinta, pongámoslo en marcha ya». Su prototipo puede venir de otro equipo o de una herramienta de programación con IA como Cursor, Lovable o Claude Code. En cualquier caso, averigüe qué puede quedarse y qué hay que reconstruir antes de que lleguen clientes de pago.

Levee, en la tabla de arriba, muestra lo que puede venir después: su prototipo básico necesitaba convertirse en una plataforma lista para producción, así que reconstruimos su backend desde cero.

Revise estas cinco cosas antes de tratar una demo como un producto:

• pruebas que se ejecutan de verdad, en cada cambio;
• un despliegue que se puede repetir, con los secretos fuera del código;
• el acceso a los datos de cada usuario, comprobado en el servidor y no solo oculto en la interfaz;
• seguimiento de errores y registros, para ver un fallo antes de que lo comunique un usuario;
• una decisión clara sobre las partes que sale más barato reconstruir que arreglar.

Pida a quien hizo la demo que le enseñe cada una en pantalla. Lo que nadie pueda enseñarle va a la lista de cosas que arreglar antes del lanzamiento. Nuestra guía sobre cómo revisar una app hecha con vibe coding recorre una revisión de 60 minutos que puede hacer usted mismo.

¿Cuánta seguridad necesita un MVP?

La suficiente para las personas reales que lo usan. Si se registran o pagan, prevea la seguridad desde la primera versión, como hacemos en nuestros MVP.

Nuestros cuatro niveles de controles de seguridad ordenan los controles según quién puede abrir la app, qué datos guarda y si mueve dinero. Antes de empezar el desarrollo, marque cada pantalla en la que un usuario escribe datos personales o paga. Después pregunte al equipo quién verá esos datos y cómo lo comprobará.

¿Qué debe demostrar su primera versión? Compruébelo hoy

Rellene esta página antes de su próxima llamada con un equipo de desarrollo y envíela con la descripción de su proyecto.

QUÉ PODRÍA ACABAR CON ESTE PROYECTO (UNA FRASE):
¿FUNCIONA LA PARTE TÉCNICA ARRIESGADA? SÍ / NO / NO SE SABE
¿ENTIENDE LA GENTE EL FLUJO PRINCIPAL? SÍ / NO / NO SE SABE
PRIMERA VERSIÓN: PRUEBA DE CONCEPTO / PROTOTIPO / MVP / UNA PÁGINA O UN SERVICIO MANUAL
QUIÉN LA USA: NUESTRO EQUIPO / USUARIOS DE PRUEBA / CLIENTES REALES
DATOS PERSONALES O DE PAGO REALES: SÍ / NO
PLATAFORMA: WEB / MÓVIL / ESCRITORIO / EXTENSIÓN DEL NAVEGADOR
RESULTADO QUE SIGNIFICA SEGUIR:
RESULTADO QUE SIGNIFICA PARAR O CAMBIAR:
QUÉ PASA DESPUÉS CON EL CÓDIGO: TIRARLO / PREPARARLO PARA PRODUCCIÓN / MANTENERLO Y AMPLIARLO

Las líneas 2 y 3 eligen la primera versión. Un «no» o un «no se sabe» en la parte técnica apunta a una prueba de concepto. La misma respuesta sobre el flujo apunta a un prototipo, y dos «sí» apuntan al MVP. Si las dos líneas dicen «no se sabe», empiece por la parte técnica.

Si no tiene un ingeniero propio, responda a la línea 2 pidiendo a quien vaya a construirlo que le enseñe la parte arriesgada funcionando con entradas reales. Hasta que lo haga, la respuesta sigue siendo NO SE SABE.

Imagine que prepara una app de reservas para peluquerías y tiene una demo hecha con una herramienta de IA. El riesgo que podría acabar con ella es cobrar una señal por cada reserva. Suponga que quienes probaron la demo reservaron sin ayuda: la línea 3 es sí. Suponga que nadie ha pagado todavía una señal a través de ella: la línea 2 es «no se sabe». La primera versión es una prueba de concepto del cobro de señales, solo con pagos de prueba.

En este ejemplo, seguir significa que una señal de prueba llega a la cuenta de la peluquería; parar o cambiar significa que no llega.

¿Cuáles son los límites de esta elección?

La plantilla decide qué construir primero, no quién lo construye; para eso, nuestro artículo sobre cómo hacer outsourcing de programación para una startup explica cómo preseleccionar y entrevistar empresas. Tampoco sustituye a hablar con los clientes, así que reserve tiempo para esas conversaciones y para leer la analítica. Y la elección vuelve después del lanzamiento: lo que muestre la primera versión debe cambiar la siguiente.

Siguiente paso

Fuentes

• Eric Ries, What is an MVP?, Lean Startup Co., publicado primero en su blog Startup Lessons Learned
• Marty Cagan, Minimum Viable Product, Silicon Valley Product Group, 24 de agosto de 2011
• Kara Pernice, UX Prototypes: Low Fidelity vs. High Fidelity, Nielsen Norman Group, 18 de diciembre de 2016
• Glosario de la Agile Alliance, Minimum Viable Product (MVP)