How to build an MVP and how much time it would take?
Minimum Viable Product (MVP). The buzzword of the 21st century of small and large tech businesses alike! But what is it exactly? In short, it is precisely what it says it is – A product in its most basic form with basic functionality and a core premise behind it!
And the second question: how long does it take to develop one? Let’s find out!
What is a Minimum Viable Product?
MVP in the tech world, is your metaphorical sword and shield of development of new projects! It allows your team to collect the maximum amount of information about its customers and their needs with the least amount of resources spent in development, and most importantly it reveals the economic viability of the project in question!
It’s important to note that an MVP can be a physical product, a digital and mobile app or even a website.
So how does one build an MVP? Here is the step-by-step guide you want to follow on your first journey in the world of Minimum Viable Products! And if you follow it we’ll be able to accurately estimate the time it takes to do so!
Find a problem then fix it!
The very first thing you need to do is to have a problem to fix! There is no benefit from your product or service if it does not solve someone’s’ problem. And if there is no benefit then there is no reason to use your product, simple as that.
Explore your competition.
Alright then, you found a problem and you’re ready to provide the solution! But before you start any development and assigning tasks to your team it is paramount to find out if the service is already provided by someone, and chances are it already is! There is no reason to get discouraged but it is important to understand the market you are trying to enter, know who all the players are and what they have in their cards. Once that is done you will have a better understanding of how to proceed with your own project.
Know thy user = Know thyself = Know thy product!
Understand your target market audience, your customers!; at the end of the day your users are your customers and they are all that matters. At this point, we know what market we are trying to enter and what product we want to create. The time has come to perform a thorough audience assessment and analysis, no stone should be left unturned. You must know your customer to cater to his needs – to its fullest potential; and doing it now, in the early development stages, will provide you with all the necessary ammunition to save on development costs in the long run.
Following that, it’s time to begin our early-stage planning and for that, you want to build a user story to follow. What is a user story?
What is a User Story?
In the software development world, a user story is a short informal description of one or more features from the perspective of the end-user. It keeps your team focused on actual value and not get bogged down by context-less tasks in feature developing cycles. User story brings to the front the context of why your developers are doing what they do, and for whom – your users!
It is a short and uncomplicated way to quickly capture the “WHO”, the “WHAT” and “WHY” of the products’ requirements. Here is an easy and quick format to follow:
As a <user type>, I want <feature>, so that <reason>
<user type> is the WHO. Who are we building it for? Who is the main user?
<feature> is the WHAT. What is it that we build? What is the intention?
<reason> is the WHY. What is the value for the customer? Why would they use it?
As a single father, I want to find a babysitter, so that I can go out with friends for drinks.
It’s easy, it’s concise and gets the point across.
It does what!? Priority is key.
At this point, your priority should be to develop a clear product strategy using all that fancy analysis we did previously. Understand and outline clearly what you want to achieve with your product, what problem it needs to solve. Make note of that problem, transpose it into one main core feature and that is going to be your MVP.
All effort goes into that one main feature, then you can start adding bells and whistles into your plan, options that you would like to offer as a secondary priority. It’s important to stick to the basics – simple problem > simple solution.
Customer needs shoes > Provide shoes. Adding colour, size, the material is secondary at this point. Get everyone on your team to understand the core of your product and know its end purpose.
At the end we suggest gathering your team with the whole list of your features and outlining – “must-have”; “nice-to-have”; and “doesn’t-matter”s’.
Don’t be afraid to trim your product to its essentials, the important thing is to save costs and test the product with an audience in the shortest time possible!
Assess your resources
Make sure you have a brief window of time before the start of the project to give your team time to get ready, understand the project goals, everyone’s on the same page who’s going to be doing what. This is where that product strategy will come in handy. Besides, it’s important to make sure you actually have enough money to begin development. If it’s your first app check out our take on things to consider when budgeting your first app!
In all likelihood you will need external involvement from designers, programmers, marketing or QA, obviously, you need to make sure you have a list of these people and you are sure they are all available on short notice, perhaps you might need equipment as well – plan ahead > save yourself a lot of headaches. You simply don’t want to get into situations where you have to find that missing link when you need it at the time.
Capacity planning means that your resources are allocated in such a way that no-one’s ever waiting for someone’s work to finish to begin their own.
You would think this goes without saying but sadly that is simply not the case: proper company resource usage and time management are paramount to achieving success.
Stages stages stages
You are probably familiar with this picture, it perfectly captures the essence of iterative and incremental development, it has been circulating the small and big business world all the way from 2016 and has been used in multiple articles, presentations and even a book in one instance (Jeff Patton’s “User Story Mapping” if anyone’s interested), and now it’s our turn to enter the list.
Without going into much detail, the picture describes the general premise you want to follow when in the process of developing your product. If you start building an end product from the ground up but without providing some usable functionality, you’ll end up with an unsatisfied client/user. When you finally give him SOME functionality, it might simply be too late because it took too much time. Compare that ill-fated scenario to giving your users something to use right off the bat even if it’s incredibly simple – you get to test your product right away and make necessary adjustments in the very first cycle.
We highly suggest giving Henrik Kniberg, the original author of the picture, a read on his blog.
Build it, test it, fix it, test it some more…
Now it’s particularly important to have a vague idea of how your product is going to look but we don’t want to spend unnecessary time creating concept designs, wire-framing is much easier to adapt and adjust on the fly according to user-orientated feedback a bit down the line when we get to the alpha!
We also advise you to take the “prototype-first” approach be that for your website or a digital app. It allows you more flexibility to make adjustments on the fly as well as get an early version of your product in the hands of your team and alpha testers so much faster!
Understand that much like Thanos, bugs are inevitable and should be ironed out as fast as possible. However this is precisely why we took as many precautions as possible not to bloat our project, the fewer cogs in the machine the less likely it is to break down.
After the alpha – Improvise, Adapt, Overcome!
No matter how much you analyse your market, client’s needs, real-life always finds a way to make it difficult for you or as the saying goes – “no battle plan survives contact with the enemy” (Doesn’t mean you shouldn’t do it, it’s still very important). You must expect the unexpected!
And that is exactly what is most likely going to happen once you’ve sent out your alpha version and received your first feedback from your colleagues or friends and family. You get a rough understanding of what you need to start working on; you never know what can go wrong in your logic:
– You hate X? Why? Oh, it’s the colour? Okay!
We’ve saved money by knowing what to work on rather than trying to provide a full-fledged product with a bloated number of features. We know exactly what the users want changed and sometimes it’s the most unexpected thing. You create a metaphorical car (or a scooter) and instead of complaining about its mobility or size( aka “main features”), the customer simply doesn’t like its’ colour and we find that out only after a thorough feedback analysis. The less features we need account to account for, the easier to find crucial problems.
Beta – “You’re like a brother to me..”
You have your product; you have your alpha feedback and you have made required adjustments tailored to the market and target audience. What could go wrong? Well as previously mentioned “expect the unexpected”. This is your products’ trial by fire; time to go beta! You’re releasing the product into the wild, but luckily if you’ve been following our steps, you’re more than ready to take action as soon as it is required.
Customers tend to make their own mind how they want to use your product. The art of UX/UI planning is important to create an easy and intuitive user interface to maximize the control over your users, want to know which one’s more important? We’ve got you covered!
But sometimes no matter how much you prepare, you have to face reality and adjust on the fly!
Fight another day – Discretion is the better part of valour
Understand that you can fail, MVPs are there to teach you and save you money! An MVP is not a triumph guarantee. In fact, even a “failed” MVP can be a success.
There are two types of MVPs – the ones that validate your business plan, and the ones that don’t. And that is the whole point of an MVP: it allows you to create a product in the shortest amount of time with the least number of resources poured into it. You can never tell with a 100 per cent certainty if a product is even viable in the current market, but rather than pouring absurd amounts of money on a product that fails, you instead go the MVP route and cut the ropes once you understand that your business model is not working. In the end, you come out stronger and smarter, ready to try another day!
How long does it take to develop an MVP?
So, let’s say you’ve defined your scope, understand what you’re trying to achieve with your MVP and are fully committed to go through with it. You followed our step-by-step guide, and one final question eludes you – how long?
But anyway, taking a rough estimate of a basic minimum viable product, say for example a mobile app, your numbers will be:
20-40 hours for initial consultation and planning, reputable vendors almost never bill these, freelancers and amateurs consider this a lifeline and tag them as billable (this of course, if it doesn’t involve adding a dedicated Business Analysis Resource).
150 billable hours for UX/UI design and implementation.
190 billable hours of Mark-Up
150 billable hours for API
300 billable hours for backend deployment
All that amounting to 830-850 hours for your alpha!
This is the most basic lowest form of your MVP that you’re ready to ship out to your test customers (earlier mentioned as friends, co-workers, family etc.) and start receiving that feedback! Once you receive proper input, you can safely add another 150 – up to 500 billable hours for implementation and getting into the beta phase.
So overall, our example of MVP takes roughly 1000-1300 billable hours of development. Or a few weeks or 2 months for a competent software development company!
And how much money that is? If we take an average of 35€ / hour, we land into 35k to 45k € for a successful MVP build! Yup, don’t get us started on the time, and money it takes to develop an application that is NOT an MVP. Actually, that is precisely what we’ll be talking about next week!
Or if you can’t wait…
Otherwise, you’ll just have to have some patience and wait for a week!
Don’t agree with what we said? Or simply want to add something to what we said? Leave a comment down below and we can have a discussion!
Stay classy business and tech nerds!