Prototipo de app o MVP: qué conviene crear primero

Cuatro formatos para cuatro incertidumbres

No todos los proyectos recorren las cuatro etapas. Una herramienta interna sencilla puede pasar de un flujo probado a una primera versión con poco código. Un producto que depende de visión artificial quizá necesite una prueba técnica antes de diseñar todas las pantallas.

El prototipo sirve para comprobar un recorrido

Elige un prototipo cuando la duda está en la navegación, las palabras, el orden de los pasos o la comprensión del servicio. Puede representar registro, búsqueda, reserva y confirmación sin desarrollar cada integración. Figma permite conectar pantallas, establecer puntos de inicio e interacciones; su guía de flujos de prototipo explica la mecánica.

No hagas una presentación guiada. Da una tarea a personas parecidas al público previsto. Pide a una academia que cree un curso y matricule a un alumno, o a un cliente que encuentre un profesional, seleccione hora y cambie la cita. Observa dudas, errores y palabras que interpreta de otra forma.

Una reacción positiva no demuestra intención de compra. El prototipo valida mejor la comprensión que el mercado. El entregable debe incluir tareas, participantes, observaciones, decisiones y preguntas abiertas, no solo un enlace a las pantallas.

La prueba técnica aísla lo que podría bloquear el proyecto

Una prueba de concepto técnica estudia una sola incertidumbre: reconocimiento de voz en una consulta con ruido, sincronización sin conexión, lectura de un dispositivo, latencia de vídeo o coste de un modelo de IA. No necesita un diseño completo ni todos los perfiles.

Define el criterio antes de programar. «Probar IA» no permite decidir. Es mejor plantear algo medible: transcribir dos minutos en tres teléfonos compatibles, dentro de un tiempo acordado, sin enviar datos sensibles a un proveedor no aprobado. Registra modelos, conjunto de prueba, coste, velocidad y fallos.

Parte del código puede reutilizarse, pero ese no es el objetivo principal. Un experimento puede omitir seguridad, pruebas y tratamiento de errores. Debe considerarse una prueba hasta que un ingeniero confirme qué partes cumplen las condiciones de producción.

El piloto manual prueba el servicio y la operación

En un piloto manual, clientes reales reciben el resultado aunque el equipo haga por detrás lo que más tarde automatizará. Una empresa de reparto puede recoger solicitudes con un formulario, asignar mensajeros manualmente y enviar avisos por chat. Una plataforma de salud puede coordinar profesionales antes de construir un sistema de asignación complejo.

Así se estudian demanda, precio, calidad y excepciones. Hay que explicar qué parte es manual y proteger los datos igual que en cualquier otro servicio. Registra cada tarea oculta y el tiempo que consume; esa información se convierte en la primera lista de automatizaciones.

El piloto deja de ser representativo si los clientes solo valoran la atención personal del fundador o si nadie calcula el coste real de la operación. La prueba debe parecerse lo suficiente al servicio futuro para que sus resultados sean comparables.

El MVP ya es un producto real

Un MVP ofrece el mínimo necesario para completar un resultado de principio a fin con usuarios reales. Puede empezar en una ciudad, admitir un método de pago o tener pocos perfiles. Aun así, requiere autenticación de producción, tratamiento adecuado de datos, control de errores, seguimiento, soporte, cuentas propias y una forma repetible de publicar.

La guía de Y Combinator para especificar un MVP propone centrarse en los recorridos esenciales y posponer funciones secundarias. «Mínimo» se refiere al alcance. No autoriza a perder pedidos ni a tratar la privacidad como un añadido. Nuestra guía de planificación de un MVP móvil ayuda a reducir funciones sin romper el resultado principal.

Un MVP aporta datos que una maqueta no puede dar: activación, repetición de uso, incidencias, coste de soporte, cancelación y pagos reales. Precisamente por eso exige más trabajo alrededor de las pantallas.

Qué demuestra un prototipo con IA en dos semanas

Con IA generativa y una persona con experiencia se puede crear en unas dos semanas una demostración convincente cuando el alcance es pequeño y las integraciones se simulan o son sencillas. Sirve para probar un recorrido, enseñar el concepto y descubrir huecos en la descripción. En la guía de desarrollo de apps con IA explicamos sus ventajas y límites.

La velocidad no aporta por sí sola seguridad ni mantenimiento. El código generado puede mezclar patrones, exponer claves, utilizar dependencias dudosas o funcionar solo en el caso preparado para la demostración. Antes de aceptar usuarios, revisa autenticación, permisos, datos, errores, licencias, registros, despliegue y propiedad.

Que el archivo se instale en un teléfono no lo convierte en MVP. Lo será cuando el equipo pueda operarlo y responder por los datos y el resultado entregado.

¿Se puede aprovechar el código del prototipo?

De un prototipo de diseño suelen aprovecharse flujos, textos y recursos visuales, no código de aplicación. Una prueba técnica puede aportar un algoritmo o integración comprobados. Un piloto creado con poco código o IA puede aportar más si la plataforma permite controlar permisos, exportar datos, integrar servicios y mantener el producto.

La decisión se toma después de validar. Revisa arquitectura, licencias, esquema de datos, pruebas, seguridad y publicación. Reescribir es razonable cuando la estructura provisional hace arriesgada cada función nueva. Conservar es razonable cuando el código ya respeta las condiciones del producto y el equipo sabe operarlo.

No prometas que nada se descartará. El aprendizaje es el principal activo de un prototipo. Tirar código frágil y conservar una decisión correcta puede ser un resultado excelente.

Una secuencia sencilla para elegir

1. Nombra la suposición que podría invalidar el proyecto.
2. Si la duda es de comprensión, prueba un prototipo navegable.
3. Si depende de tecnología, mide una prueba técnica limitada.
4. Si no conoces demanda, precio u operación, presta el servicio manualmente a un grupo pequeño.
5. Cuando recorrido, tecnología y servicio estén claros, define el MVP de producción.
6. Decide de antemano qué resultado significa continuar, revisar o parar.

Para ideas tempranas, consulta los métodos de nuestra guía de validación de una idea de app. Cuando ya existe una dirección, la plantilla de especificación técnica permite describir roles, estados, integraciones y criterios de aceptación.

Qué explicar al pedir una estimación

Una estimación mejora si el equipo conoce la pregunta que quieres responder. Describe usuario principal, resultado, recorrido crítico, riesgo técnico, integraciones, sensibilidad de los datos y materiales disponibles. Indica si necesitas una herramienta desechable para aprender o una versión que habrá que mantener.

En Appfyl proponemos un prototipo cuando el recorrido todavía cambia cada semana, una prueba técnica cuando el producto depende de una integración incierta y un MVP cuando el núcleo ya está entendido. La guía de plazos de desarrollo diferencia una prueba rápida con IA, una primera versión con poco código y un producto personalizado más amplio.

Puedes dejar estos datos en el brief de estimación de Appfyl. Elegir todas las funciones posibles no mejora el presupuesto; explicar la incertidumbre actual sí.

Preguntas frecuentes