MVP stands for Minimum Viable Product and it’s usually a software app with a limited number of features that’s just enough to be used by early-stage customers. Following the iterative approach, teams usually go from MVP to later versions of the product using the customers’ feedback to prioritize new features.
There are several reasons for that:
1. It saves resources. The first reason is that it actually saves your time & money. Everything is moving so fast these days. Your idea can be good today but it will become outdated very soon. The sooner you launch your first version and get some real clients - the better.
2. Hypothesis check. Most of the time, you can’t be sure about how good your idea is. Even if you’ve made some research, it’s still not obvious if it’s going to play out or not. Building an MVP allows you to figure out whether your software is actually interesting for the customers and brings enough value to them. If it turns out that something is wrong, you can quickly make a pivot and try building a different product based on the MVP.
3. Get some traction. That’s what every investment fund loves. With MVP you can get some real customers who actually pay for your software. That will affect your company evaluation and allow you to get a better investment deal when raising money during the early stage.
Avoiding burnout. Building software can be fun. It’s interesting, really. But it might also feel stressful if you work on the project for years without any result. Functional MVP brings satisfaction and a lot of motivation.
I’m pretty sure there might be many more reasons. Please share your thoughts in the comments.
Ok, now when we know why it’s important to build an MVP first, let’s go through the most common mistakes that founders make.
Let’s quickly get through these three most common mistakes.
Okay, I guess you all know what it means. When OCD comes in and you can’t stop improving things that already work fine. Launch time is usually very important and chances to build a really successful product are quite low if it takes you too long to build the MVP. That means, you need to define features, build them and try avoiding perfection.
Things should work, they should look good, but do not try to make them perfect. That’s it. Focus on launching.
Imagine the following example. You’re building an MVP of a car. What are the main features?
Well, obviously you need it to move and some basic control “interfaces” like steering wheel and gear box.
So, the MVP of a car is a metal box with 4 wheels, one chair, steering wheel and a gear box, right?
What features are optional? Well, one can say everything else. How about headlights? Are they optional?
Will the car be functional without them? Well, yes, but not during the nighttime. Are you building a car that should work during the night time? If yes, then that should be a part of an MVP.
What’s obviously optional is everything related to driver’s and passengers’ comfort - climate control, multimedia, massage seats etc. Leave these things for the future versions, do not include them in your MVP.
Let’s get back to the car MVP example.
What if you build a box with 4 wheels and Multimedia with apple car play support? Well, it’s something useless. You can sit there and connect your iPhone, but you can’t get to your destination. That’s one case.
Another case - you’re trying to build a Toyota Corolla straight away. It seems to be a simple car (not a Rolls Royce) but it will take you 10X or 50X time of building an MVP to build a simple but fully-functional product. If your resources are limited, start with an MVP, start selling it and getting feedback
What is important in MVP from the technology standpoint?
Below I will share the stack that we usually use to build MVPs of web-based projects at 2V Modules and try to explain why.
This is a modern and most popular PHP framework. It has a great community, many existing packages and some easy-to-use boilerplates with most common functions.
Let’s say you want to build a SAAS. Laravel already has things like authorization, billing, user access levels etc. handled either in its core or using popular packages. Same thing is true if you’re building a LMS (learning system), CRM, Social network, marketplace for a new niche, etc.
Alternatives are numerous. You can use Python (Django), Ruby (RoR), NodeJs, Go, ASP.Net, Java, or any other modern language and framework.
For early and mid-stage startups any of those technologies would work equally great if implemented professionally. We propose one of the most commonly-used stacks which means it’s relatively cheap and scaling possibilities are almost unlimited when your business starts to grow. There are certainly use-cases when some other technology should be prefered. We always start a new project with analyzing requirements and thinking of possible technology approaches.
VueJs is a modern Javascript front-end framework (alongside ReactJs and Angular). We usually build front-end with VueJs because it works very well with Laravel and Laravel also has a bunch of packages where VueJs is already used.
This one is also one of the most popular solutions. If your data can be well-structured under a relational data model, then most probably it can be stored in MySQL. There are scenarios where another model works better and you should probably look into NoSQL direction (e.g. MongoDb).
If you’re limited in resources (time or money), not sure about the idea or want to have something that can be shown to potential investors, it’s a good idea to build an MVP. You need to avoid popular mistakes and find a good service provider who will build it using a popular technology stack that fits your product requirements.