Una arquitectura MVP necesita una salida
Empezar estrecho es válido. Hacer permanente lo temporal por accidente no lo es.
Diagrama genérico. No reproduce una arquitectura de cliente.
Un MVP enfocado puede ser la forma correcta de obtener valor. El riesgo aparece cuando una dependencia temporal no tiene responsable, condición de salida ni fecha de revisión.
La complejidad temporal es aceptable si su causa, responsable y retirada están explícitos.
Este patrón tampoco sale de la documentación de ninguna plataforma. Ningún fabricante publica guía sobre cuándo retirar un atajo. Sale de práctica de arquitectura evolutiva, la que dice que casi nadie diseña pensando en cómo se sustituirá lo que construye.
Señales en producción
- Un workaround no tiene owner ni revisión.
- El segundo caso de uso se resuelve copiando y pegando el primero.
- Nadie sabe qué debe desaparecer tras el MVP.
Arquitectura recomendada
Registrar cada concesión con causa, alcance, impacto, responsable y condición de retirada.
Diseñar contratos estables para sustituir la solución sin rehacer consumidores.
Cuándo no aplicarlo
- No usar MVP para evitar controles de identidad, consentimiento o seguridad.
- No aceptar deuda sin equipo responsable.