Minimal Viable Product (MVP)

In this blog we will talk about what makes a successful MVP and common pitfalls to avoid.

We often hear the phrase “MVP”.  Usually, it’s used as a phrase on limiting the number of features to be developed for an initial release of an application.

Sometimes, it’s worse, it’s used as a term for cutting corners and producing questionable code.  All with the best intentions of saving time.

This is not what an MVP should be.

An MVP should still follow the same principles and techniques used to create resilient, maintainable software.  Cutting corners at this stage is a false economy and runs the risk of accumulating tonnes of technical debt before you’ve even released version 1.

Instead, the mindset during the MVP stage should be, “what limited features can we produce, yet they still offer a best-in-class experience and the software is still open to be extended in the future”.

I would argue that more time should be spent on reducing the technical dept and making the software more malleable at the MVP stage of the project's lifecycle.  This means that, when the evitable comes to light, and more features need to be added, it’s a frictionless experience and results in minimal blockers or issues.