El backlog de la app tiene 86 tickets y el calendario dice «MVP en doce semanas». Alguien tacha notificaciones, alguien deja el onboarding de cinco pantallas y alguien recorta el modelo de datos «porque eso se refactoriza». Eso no es un recorte. Es una hipoteca con fecha de lanzamiento.
Un MVP no es una app a medias. Es el recorte que deja una base que se puede ampliar sin reescribir auth, stock o el contrato con las stores. La pregunta no es cuántas pantallas caben. Es MVP app: qué dejar fuera sin convertir el recorte en deuda que pagas el mes cuatro.
Este artículo es el criterio que usamos en Truman al plantear un proyecto de desarrollo de app. Qué cortar, qué no se puede posponer, y cómo se ve eso en producto real —no en un canvas de Lean Startup.
MVP app: qué dejar fuera sin hipotecar el producto
MVP, en este estudio, no significa «la versión barata». Significa la versión más pequeña que demuestra el valor y deja un suelo técnico sobre el que se puede construir. Si el recorte obliga a tirar auth, el modelo o el binario de store a los tres meses, no has hecho un MVP. Has hecho una demo cara.
La diferencia se ve en dos listas. Una es lo que el usuario no necesita el día uno para completar el trabajo (onboarding teatral, gamificación, el tercer canal de notificación, el dark mode). Otra es lo que el producto necesita para no mentir: identidad, permisos, un modelo de datos que aguante la segunda feature, y un camino real a las stores si el canal es app. Mezclar las dos listas es el error habitual.
En startups el recorte se parece al de una web por fases. El marco está en diseño web para startups por fases: no es «menos diseño», es un orden. En app el orden duele más porque el store review, el offline y el backend no se improvisan el viernes del launch.
Lo que sí se puede cortar (y casi siempre sobra)
Se puede cortar todo lo que no cambia la prueba de valor. Si el producto es «invitar a un grupo y que hablen unos días», no necesitas un feed eterno, un marketplace de extras ni cinco tipos de push. Si el producto es «comprar la entrada y entrar por puerta», no necesitas un club social el día uno.
En la práctica, en Truman cortamos primero lo que es teatro de producto: onboarding de más de dos pantallas, empty states ilustrados para features que no existen, dashboards de analítica interna, perfiles públicos, referidos, y cualquier «también podría». Eso no es crueldad. Es dejar sitio para el núcleo.
| Pieza | En el MVP | Por qué |
|---|---|---|
| Onboarding largo y tooltips | Fuera | Si hace falta un tutorial, el flujo no está cerrado |
| Tercer canal (chat, mapa, social) | Fuera | No demuestra el núcleo; diluye la prueba |
| Auth, roles y revocación | No se pospone | Reescribir sesiones es reescribir la app |
| Modelo de la entidad central | No se pospone | Grupo, pedido, ticket: el resto cuelga de aquí |
| Dark mode, referidos, gamificación | Fuera | Adorno. No cambia si el producto vale |
| Camino a stores (cuentas, privacidad) | Preparar, no pulir | No es UI; si llega tarde, el calendario miente |
| Stack nativa vs híbrida | Decidir, no aplazar | Aplazar es elegir por accidente |
El stack también se decide en el recorte, no «cuando escalemos». Nativa, híbrida o PWA no es ideología: es si el núcleo es sensor, formulario o web. Esa conversación está en app nativa vs híbrida en 2026. Elegir mal no se arregla con un sprint de «migración suave».
Lo que no se puede posponer (aunque no se vea en el mockup)
Hay tres suelos que, si los dejas para la fase 2, hipotecan el producto. El primero es identidad: login, sesión, roles, revocar a alguien. El segundo es el modelo de la entidad que da nombre al producto (el grupo, el pedido, el ticket). El tercero es la política de datos: qué se guarda, qué se sincroniza, qué pasa sin red. Sin eso, cada feature nueva pisa la anterior.
El detalle de auth, cola y offline está en el backend que tu app necesita. Aquí basta la regla: si el MVP promete «guardar», «invitar» o «validar», el servidor tiene que saber qué significa eso. Una pantalla verde de «listo» que no está confirmada no es ágil. Es una mentira que el usuario recuerda.
Tip técnico: el recorte se escribe como inventario de acciones
Antes de abrir Figma, lista las acciones del día uno: crear, invitar, pagar, validar, expulsar, leer. Cada una: ¿existe?, ¿es online only?, ¿tiene id de idempotencia?, ¿quién puede hacerla? Lo que no está en esa lista no se diseña. Lo que está y no tiene respuesta de servidor no entra en el MVP. El mockup bonito no sustituye esa tabla.
Cómo se recorta en la mesa (no en el backlog eterno)
El recorte no se hace tachando tickets a las once de la noche. Se hace en discovery, con una frase de valor y una prueba observable. «La gente invita y el grupo está vivo el fin de semana» es una prueba. «Tenemos las 14 pantallas del deck» no lo es.
Si quitas tres features y el producto deja de tener sentido, no tenías un MVP: tenías un wishlist. Si quitas tres y el núcleo sigue en pie, ya sabes qué era teatro.
Cómo se ve el recorte en Weddle y en Klapper
Weddle es una app social alrededor de una boda: grupos privados de solteros invitados, activos unos días. El MVP no era un feed eterno ni un marketplace de planes. Era: entrar por invitación, estar en el grupo correcto, hablar a tiempo. Auth por invitación, dato que caduca, sync «estar donde toca». Todo lo demás —perfiles públicos, reputación, features de red social— habría hipotecado el lanzamiento y no habría demostrado el valor.
Klapper es otra tijera. Es venta de entradas, marca, web y app. El núcleo el día uno no es un club de fans: es inventario, pago y el momento en que un QR se valida en puerta. Recortar el social es fácil. Recortar el stock o el auth de staff no lo es. Si el MVP de una plataforma de eventos «deja el acceso para después», no tienes producto: tienes un catálogo.
Un MVP serio se reconoce por lo que no tiene y por lo que no se atreve a improvisar. Si el recorte es solo de pixels, no es un recorte: es una deuda con interfaz.
En València vemos el mismo patrón en briefs de producto propio y de cliente: el deck pide «la app completa» y el presupuesto pide «un MVP». Las dos frases no pueden ser verdad a la vez. Elige la prueba. El resto se agenda, no se finge.
Antes de llamar MVP a un alcance, verifica esto
- ¿El valor cabe en una frase y se puede observar en usuarios reales?
- ¿Hay un inventario de acciones (crear, invitar, pagar, validar) con dueño y estado de error?
- ¿Auth, roles y revocación están especificados, no «con un plugin»?
- ¿El modelo de la entidad central aguanta la segunda feature sin migración de pánico?
- ¿Sabes qué es online only, encolable o prohibido sin red?
- ¿El stack (nativa, híbrida, PWA) está decidido por el núcleo, no aplazado?
- ¿El camino a stores (cuentas, privacidad, review) tiene semanas en el calendario?
- ¿Lo que queda fuera está escrito y se defiende, no se «asume que entra»?
Preguntas frecuentes sobre qué dejar fuera de un MVP de app
¿Qué se debe dejar fuera de un MVP de app?
Todo lo que no demuestra el valor ni sostiene la siguiente feature: onboarding teatral, canales extra, gamificación, dashboards internos, dark mode. No se deja fuera el auth, el modelo de la entidad central ni el camino a las stores si el producto es app. Recortar UI es fácil. Recortar el suelo es caro.
¿Un MVP de app tiene que estar en las stores?
Solo si el valor depende de instalar, de push fiable o de un sensor. Si estás validando un flujo que cabe en web, una PWA o un TestFlight cerrado pueden ser el recorte honesto. Publicar por icono en el escritorio no es un MVP: es vanidad de canal.
¿Cuánto debe durar un MVP de app?
El tiempo de cerrar la prueba, no un número mágico. En Truman solemos hablar de semanas a pocos meses cuando el núcleo está escrito. Si el calendario pide «MVP» y el alcance pide producto completo, no tienes un plazo: tienes una contradicción.
¿Se puede lanzar un MVP y reescribir el backend después?
Se puede. Casi nadie lo hace limpio. Reutilizas aprendizaje y, si acaso, pantallas. No reutilizas un auth improvisado ni un modelo mentiroso. Si ya sabes que el suelo está mal, no lo llames MVP: llámalo prototipo y no lo llenes de usuarios reales.
