MVP o prototipo: qué conviene construir primero

Un prototipo le ayuda a probar una idea o una interacción. Un producto mínimo viable, o MVP, permite que usuarios reales completen una tarea útil para que usted aprenda del uso real. Construya un prototipo cuando el diseño sea incierto; construya un MVP cuando esté listo para entregar y operar un producto pequeño. Si la incertidumbre es técnica, puede ir primero una prueba de concepto concreta.

Son compras distintas. Una demostración pulida no incluye necesariamente el tratamiento de datos, los permisos, el proceso de publicación o el soporte que necesita un producto en funcionamiento. Antes de comparar propuestas de desarrollo, nombre la pregunta que quiere que responda el trabajo.

Comparación entre prototipo, prueba de concepto y MVP

Los nombres varían de un equipo a otro. Acuerde el resultado que se pretende en lugar de fiarse del nombre que figure en una propuesta.

En una pantalla estrecha, desplace la tabla hacia los lados para leer todas las columnas.

Entregable	Pregunta a la que responde	Qué debería poder observar	Qué no demuestra
Prototipo	¿Pueden los usuarios entender y completar esta interacción propuesta?	Las personas prueban un recorrido limitado; usted ve dónde dudan o lo malinterpretan.	Integraciones fiables, funcionamiento en producción ni disposición a pagar.
Prueba de concepto	¿Puede funcionar un enfoque técnico concreto con las restricciones relevantes?	Un experimento acotado demuestra una capacidad, por ejemplo leer los datos necesarios de un proveedor.	Un producto completo ni una experiencia de cliente utilizable.
MVP	¿Puede un producto pequeño y funcional aportar el valor previsto a sus primeros usuarios?	Usuarios reales completan la tarea principal; usted recoge comentarios y observa el uso.	Encaje del producto con el mercado, captación rentable ni preparación para todos los clientes futuros.

Un prototipo puede ser un boceto en papel, un diseño en el que se puede hacer clic o una interfaz programada y limitada. Su utilidad viene de lo que se aprende, no de la cantidad de código que contiene. La guía de la fase alfa de GOV.UK (en inglés) hace la misma distinción práctica: probar las hipótesis arriesgadas con prototipos en lugar de tratar el código experimental como software de producción.

Un MVP puede ofrecerse a un grupo pequeño de invitados. No necesita todas las funciones, pero quienes lo usan necesitan una forma de completar la tarea prometida y de obtener ayuda cuando falla.

Elija el entregable más pequeño que resuelva la incertidumbre

Pregúntese qué podría convertir en un derroche la siguiente inversión en desarrollo.

La necesidad es incierta: hable con los usuarios previstos y observe su trabajo actual. Ni un prototipo ni un MVP sustituyen a descubrir si el problema importa.
La interacción es incierta: use un prototipo para probar los pasos difíciles. Puede que no necesite diseñar todo el producto para saber dónde se atascan las personas.
La integración es incierta: haga una prueba de concepto con datos representativos y un acceso realista. Una petición correcta a un endpoint de pruebas no demuestra que toda la integración esté lista.
El valor en el uso real es incierto: considere un MVP con un recorrido pequeño y completo, y un plan para observar lo que ocurre tras la publicación.

No tiene por qué comprar los tres en secuencia. Si el flujo de trabajo ya se entiende y la tecnología está consolidada, un prototipo aparte puede aportar poco. Si una integración imprescindible no puede funcionar, construir antes el resto del producto es el orden equivocado.

Una idea de reservas, tres alcances distintos

Piense en un producto hipotético de reservas. Los clientes deben elegir una cita disponible, recibir una confirmación y modificar la reserva si hace falta. Es un ejemplo ilustrativo, no un resultado de un cliente de AL+.

Un prototipo podría mostrar la selección de la cita, la pantalla de confirmación y el flujo de cancelación. Compruebe si las personas entienden las opciones y si el personal puede usar la vista administrativa propuesta. Las citas y las confirmaciones pueden estar simuladas si se les explica a los participantes.

Una prueba de concepto podría examinar el proveedor del calendario. ¿Puede la aplicación leer la disponibilidad, crear una reserva y reconocer un cambio en conflicto, con el acceso que el negocio puede obtener realmente? Documente qué probó el experimento, el entorno utilizado y qué queda sin probar.

Un MVP podría permitir que un grupo limitado haga reservas reales de un servicio en un local. También necesitaría las reglas pertinentes sobre zonas horarias, conflictos, cancelaciones, acceso del personal y recuperación ante fallos. Un gran panel de informes puede esperar; evitar que dos personas reserven el mismo horario, quizá no.

La decisión depende de la incertidumbre y del resultado prometido. «Solo cinco pantallas» no basta para distinguir esos alcances.

Un briefing que puede usar antes de pedir un presupuesto

Rellene estas seis líneas. Si no puede responder a alguna, anótela como pregunta abierta en lugar de como suposición.

Usuario y tarea: quién necesita hacer qué, y qué hace hoy.
Pregunta por responder: qué incertidumbre debe resolver este trabajo.
Entregable: prototipo, experimento técnico o una primera versión funcional; explique por qué.
Prueba de finalización: qué comportamiento u observación le permitiría aceptar el trabajo.
Alcance y exclusiones: qué usuarios, dispositivos, integraciones y casos de fallo se incluyen; qué puede esperar.
Próxima decisión: qué hará si el resultado respalda la idea, la contradice o no es concluyente.

En el ejemplo de las reservas, un criterio de aceptación podría ser: «Un cliente invitado puede reservar un horario realmente disponible, recibir la confirmación y cancelarlo; el personal ve el cambio». Eso describe el comportamiento del producto. «La app tiene una pantalla de reservas» describe una interfaz y deja sin resolver el trabajo importante.

Use la guía del costo de desarrollar un MVP (en inglés) para comparar estimaciones del mismo entregable con las mismas exclusiones.

Lo que un MVP sigue necesitando tras reducir la lista de funciones

Un alcance pequeño no elimina las responsabilidades que crean los usuarios y los datos reales. Identifique cuáles se aplican antes del lanzamiento:

Reglas de acceso y un tratamiento correcto de la información que guarda el producto.
Un proceso de publicación repetible y el control del repositorio y de las cuentas de servicios.
Una forma de detectar los fallos y de recuperar el trabajo o los datos importantes.
Un contacto de soporte y alguien responsable de la siguiente versión.
Un plan para recoger comentarios que sirvan a una decisión concreta sobre el producto.

Esos requisitos deben ajustarse a la publicación real. No añada infraestructura para una escala imaginaria, pero no omita una vía de recuperación para la información que no puede permitirse perder. La guía de la fase beta de GOV.UK (en inglés) ofrece un modelo útil: invitar a un grupo limitado, aprender del uso real y planificar la capacidad para sostener ese aprendizaje.

¿Se puede convertir un prototipo en un MVP?

A veces. Primero examine lo que contiene realmente el prototipo. Puede que la interfaz sea reutilizable, mientras que los datos simulados, la autenticación provisional o la configuración solo local deban sustituirse. A veces sale más barato descartar el código escrito para un experimento que hacerlo fiable.

Pida al desarrollador que separe el trabajo reutilizable, el trabajo de producción que falta y las hipótesis sin resolver. Un prototipo creado con IA necesita la misma revisión; una demostración convincente es prueba de que la demostración funciona, no de que el producto esté listo para los clientes.

Hable de la próxima versión útil

AL+ ofrece desarrollo de MVP para fundadores que necesitan un primer recorrido completo y una titularidad clara tras el lanzamiento. Envíenos el briefing de seis líneas, cualquier prototipo existente y sus limitaciones de presupuesto o de plazo.

Escriba a AL+ sobre su prototipo o MVP. Podemos hablar de qué entregable responde a la pregunta que usted necesita resolver.