In software development, MVP stands for Minimum Viable Product and is used to describe a core set of functionality that is essential to a product. It is perhaps more commonly known a ‘proof of concept’. This may be as simple as setting up a Facebook page, drawing up some basic sketches, making an indicative video, through to a working prototype with the bare essentials.
The first stage of development in almost every application should be an MVP. Here are some reasons why:
Further to this, an MVP proves a relationship between a client and the developer. In an MVP, we want to demonstrate our capability in building an outstanding application for you, and prove our value as your app development partner in the stages to come.
If we weren’t genuinely interested in the success of our clients then we wouldn’t talk about an MVP – we’d happily build everything asked of us and perhaps earn a lot more money, in the short term. Our clients come back to us because we care, and because we work with them to develop a sensible development strategy to deliver the most value. We strongly recommend you consider what your app really needs.
There are 3 ways you can apply the concept of an MVP to a set of requirements:
Limiting the sets of features available in an app is the most obvious and significant way to cut down development time and costs. If the goal is to get an app into the hands of your users as soon as possible, then you probably don’t need reams of reports, dashboards, and a wide range of features related to your core proposition. You can always add these things in stages 2, 3 and so on. We often start writing a requirements document for stage 2 while creating the MVP requirements because many of these ideas are fantastic for the product and should be developed – just not yet.
This can be created as a list of ‘nice to haves’ or future considerations. At Dapper, we build flexible apps that can grow with your needs. No need to redevelop or start over when you wish to add new features.
Once you identify the core features, it’s time to cull specific functions. This requires systematically assessing each function and deciding if it is absolutely needed. Consider a mobile app that requires a user to login; you’ll need a login screen, some way to register users, and probably a way to reset the password. You may also need Terms and Conditions, or a Privacy Policy. But perhaps you don’t need a screen for users to edit their profile? If you take away the user profile screen then that is one less screen to design and code, several fewer API, and a couple hours of time saved. Whether this is feasible depends on your situation as every app is different, and what might be right for one app won’t be right for another. Just remember that every function you cull from the MVP makes a small contribution toward lessening the work and cost. If you can be ruthless, then significant savings may be possible, and your app may be better for it.
Appearance is mentioned last because it isn’t an area that you can skimp on much in an app. You’ve heard the phrase ‘looks sell’ and this is particularly true for app design. Particularly with tech products, sometimes the best way to describe your concept and to gain attention is through visuals. Sometimes, it may be all you need.
Your back-end administration system may be functional only (but still branded and easy to use), but your client facing apps need to be beautiful apps. It doesn’t matter if your app is intended for the public, or for use internally, the presentation of the app must appeal to the user and encourage them to get engaged. Still, there are things you can do to keep costs down, and our designers are very talented at creating great apps on a budget.
The concept of scope is baked into an MVP, as it defines precisely what will be developed. We talk about this more in the next topic.