If you’re thinking of building an MVP of your app or web project, you’re probably wondering how long this process will take. It’s important to get your MVP out in the market as soon as possible, in order to beat the competition and get revenue flowing into your startup.
Firstly, what is an MVP?
An MVP is a minimum viable product - the idea is to build only the required features to satisfy early adopters by focusing on solving their pain points.
Why build an MVP?
By building an MVP you can validate your idea quickly and avoid building the wrong features. It’s not about building something beautiful and full of features, it’s about proving that your idea can solve a real-world problem.
Building an MVP is preferable to building a prototype or proof-of-concept because you don’t have to throw it away when you decide to go ahead and build the full product - you simply build on top of the MVP to add more features.
Calculating the time required to build an MVP
In order to calculate how long it will take to build an MVP, you have to make some simple decisions first:
Choose the features of your MVP - try to tackle one thing really well, rather than building lots of things all at once.
Decide how much focus will be on the design of your MVP.
Think about your audience - each user type is called a “persona”. The more personas you have, the longer it will take.
Choose your channels. For apps, decide if it will be launched on the web, iPhone, Android or a mixture of them.
These decisions form the “scope” of the MVP. It’s important to keep the scope narrow with an MVP - this means don’t build too many features. Keep it lean and fast.
Average time taken to build an MVP
Having worked on building a lot of MVPs over the last few years, I think our sample size is now big enough to take an average. On average, building an MVP takes about 25-30 days with a team of 2 people. This is actually the ideal length of time - any longer than this, and you risk losing focus and building too many untested features. Your MVP should be released within weeks, not months, whether it’s looking beautiful or not.
Obviously, this average time is based on a lot of assumptions - launching your MVP on one platform to a limited set of personas with only the bare essential features and functionality. Padding with extra features will make the build take longer, and isn’t really an MVP any more.
Common mistakes when building an MVP
We build MVPs all day every day. It’s far easier to point out what goes wrong rather than what goes right when building MVPs. If everything goes right, the project is a success, but the focus quickly moves to extending the MVP. I think it’s important to highlight potential pitfalls when building an MVP so your project keeps on the rails and doesn’t take too long.
Avoid scope creep. This is when you keep adding extra features before you even launch. Doing this jeopardises the whole MVP methodology and you risk building features that nobody once.
Don’t be scared of the launch. First impressions do matter, but a slightly bad design or missing features won’t put off early adopters if you solve their problem well enough with the MVP’s core features. Which leads me to:
FUNCTION OVER FORM. I can’t stress this enough. People WILL use a crap looking app if it does the job well enough. This is what building an MVP is all about!
If you can avoid these common pitfalls, your MVP will be fast and cheap. Every decision you make should be about getting to market quickly with your MVP.
What else should you know before building an MVP?
Do your homework. Do plenty of market research before building your MVP.
Be clear about the reasons you’re building the MVP, and stick to your values. Don’t get lost along the way.
Build, Measure, Learn. Do this over and over again, really fast. Don’t spend 6 months learning - the build-measure-learn cycle should happen in days, not months.
Measure your success. Don’t make guesses about how popular features are in your MVP, or if people are using it. Track your traffic with Google Analytics, Hotjar and other off-the-shelf tools.