MVP architecture needs an exit path
Starting narrow is valid. Making temporary choices permanent by accident is not.
Generic diagram. It does not reproduce a client architecture.
A focused MVP can be the right way to create value. Risk appears when a temporary dependency has no owner, exit condition or review date.
Temporary complexity is acceptable when its cause, owner and retirement path are explicit.
This pattern does not come from platform documentation either. No vendor publishes guidance on when to retire a shortcut. It comes from evolutionary architecture practice, the one that says almost nobody designs for how their work will be replaced.
Production signals
- A workaround has no owner or review.
- The second use case is solved by copying and pasting the first.
- No one knows what should disappear after the MVP.
Recommended architecture
Record every concession with cause, scope, impact, owner and retirement condition.
Design stable contracts so the solution can be replaced without rebuilding consumers.
When not to apply it
- Do not use MVP to avoid identity, consent or security controls.
- Do not accept debt without an accountable team.