> 2021-04-15

MVPs (“minimum viable products”) shouldn’t be built in a way to handle a wide range of future use cases.

For example, an MVP for an API-based service shouldn’t focus on accommodating future expansions in its first iteration. Constructing a simple, albeit rigid, pattern addressing the immediate need is the goal. If no one is using the API, focusing on delivering something that can be used to gather feedback is more important than planning for every eventuality.

Provide the “minimum value possible” for the MVP even if the first cut is clunky or doesn’t adhere to best practices. The most important goal is to get the API out there for user evaluation; a V2 of the API can always be released later.

MVPs shouldn’t worry about being initially backwards compatible.

> Home