Una mala primera versión no es la que tiene pocas funciones. Es la que tiene veinte y ninguna termina de funcionar.
Un MVP (producto mínimo viable) es la versión más pequeña que le resuelve un problema real a una persona real. No es un prototipo ni una maqueta: es algo que alguien puede usar de principio a fin, aunque haga una sola cosa.

Empieza por un solo flujo
Busca la frase que describe el momento en que tu app hace su trabajo: "el repartidor confirma la entrega con foto", "el cliente repite su último pedido". Todo lo que ese flujo necesita entra. Lo demás tiene que justificarse.
Una prueba simple para cada función: si la quitamos, ¿el flujo principal se rompe? Si no se rompe, puede esperar.
Lo que sí debe entrar
Hay cosas que parecen secundarias, pero recortarlas sale caro:
- El flujo principal completo, incluidos los errores. ¿Qué pasa si se cae la red a la mitad del pedido?
- Inicio de sesión y borrado de cuenta. Si tu app permite crear cuentas, las dos tiendas exigen poder eliminarla. Lo vemos en privacidad en las tiendas.
- Medición de errores y uso. Sin esto no sabrás qué falla ni qué se usa, que es justo lo que viniste a averiguar.
- Un canal para reportar problemas. Si el usuario no puede avisarte dentro de la app, te avisará con una reseña de una estrella.
- Lo que tu giro exige por ley. Avisos de privacidad, facturación y lo que aplique.
- Actualización forzada. Un mecanismo para pedir que se actualice quien trae una versión con un error grave. Agregarlo después es tarde: los teléfonos con la versión vieja nunca se enterarán.
Lo que casi siempre puede esperar
- Modo oscuro y temas.
- Segundo idioma, salvo que tu mercado lo pida.
- Reportes avanzados en el panel. Al principio basta con exportar a Excel.
- Inicio de sesión con cinco proveedores. Con una o dos opciones se puede empezar. Eso sí: revisa las reglas de Apple antes de añadir inicios de sesión de terceros.
- Roles y permisos finos que todavía nadie ha pedido.
- Animaciones elaboradas.
- Chat interno, si un enlace a WhatsApp o a tu canal de soporte lo resuelve.
Tres trampas frecuentes
"Es que el competidor lo tiene." El competidor lleva años recortando y añadiendo. Copiar su lista de funciones no es copiar su aprendizaje.
"De una vez, ya que estamos." Cada "de una vez" añade pruebas, mantenimiento y tiempo. Si el calendario se alarga, casi siempre es por acumulación de estas decisiones pequeñas.
Lanzar sin decidir qué vas a medir. Una primera versión sirve para aprender. Si no defines antes qué respuesta buscas, solo habrás lanzado una app pequeña.
Pequeña, pero no descuidada
Un recorte de alcance no es un permiso para hacer mal lo que queda. Las tiendas revisan igual una versión mínima que una grande, y una app con muy poco contenido puede ser rechazada por no ofrecer suficiente funcionalidad.
Lo mismo pasa con tus usuarios: perdonan que falten funciones, pero no que falle lo poco que hay. Es mejor hacer pocas cosas y hacerlas bien.
Cómo decidir en una tarde
- Escribe en una columna todo lo que quieres que haga la app.
- Junto a cada renglón, responde: ¿el flujo principal se rompe sin esto?
- Marca lo que tu giro o las tiendas exigen.
- Lo marcado y lo que rompe el flujo es tu primera versión.
- Guarda lo demás en una lista. Ordénala cuando tengas datos de uso reales.
Si quieres hacer este ejercicio con nosotros, es exactamente de lo que se trata la primera consulta. Y a veces la conclusión es que tu primera versión ni siquiera necesita ser una app.