Everyone knows what a minimum viable product is, right? It's what you build to test your assumptions before you build the bells and whistles version of your product? Well kind of, yes, but also kind of no.
We've written quite a lot about MVPs on our blog. You might want to check out some of our previous articles including the Critical Things You Need to Know About Building an MVP Part 1 and Part 2.
In this article we talk about the difference between an MVP and a prototype. It's a confusion that we see in lots of our clients and it's important to know the difference - especially when we come to discuss the all important budget.
Understanding the Differences
Well, first, let's cover the similarities. Neither an MVP or a prototype are the finished, polished product. Both of them might look a bit rough and ready.
The main difference is that a prototype demonstrates a concept. It's essentially a way of showing what your product will do, rather than just talking about it.
An MVP on the other hand actually does the concept. Although it's crude, it's an actual working iteration of an idea.
A Practical Example
This might sound a bit confusing so let's break it down a bit. Consider a product like Twitter. Let's say that the core functionality of the product is as follows (we've simplified it by the way):
1) See a feed of tweets from my network
2) Send a tweet
3) Receive a tweet
Now if I were building a prototype, I would want to show the 3 stages above. But I don't actually need the functionality to be live. It's essentially a mock up that allows me to convey the idea of the product to someone, just so they can see how it works.
So, in my prototype, the feed of tweets doesn't really need to be real data. I can just use placeholder data. Similarly the sending and receiving of the tweet don't really need to actually work. They just need to show the user how it would work in the final product.
A prototype is like a movie set. It's mainly just for show, and there's nothing really behind the interface. It's normally just enough to sell someone on the idea - normally an investor or a potential client.
So what about an MVP? Well an MVP uses actual real data, and allows the user to really execute the functionality in the application - no matter how basic. MVPs are normally used to test the appetite of the product in the marketplace.
In other words - will people actually use this?
So in our above example. I would need to actually set up a bunch of different users and have them tweet (or create tweets) to fill up the feed. It might look the same, but this time the data in the feed is real. Similarly, rather than just demoing the process of sending a tweet, with an MVP I can actually send one. That means that my tweet is real, it's live, and it's added to the feed so that all users can see it.
How Does This Affect the Budget?
The bottom line - a prototype is a lot cheaper than an MVP. When you're building an MVP you're essentially building the final product, albeit in a stripped down form. You have to set up databases and build a 'back end' to handle your data. You have to set up different users, which normally means different types of users (admin, team etc).
With a prototype, you can actually 'fake' a lot of the processes, which makes things a lot simpler. Often you don't even need to build an external database. You can keep data stored 'locally' on your computer or phone.
In 2013 a bunch of CTOs were asked to estimate building MVPs for some of the world's hottest start ups. Twitter came in at $50,000 to $250,000.
That's clearly not an insubstantial investment. For a prototype, we estimate that you could do a hell of a lot with $10,000.
The main thing to remember is that prototypes and MVPs are designed for different things. And it's important to know which one to go for. We'll be covering that in some of our future posts.
Photos: Matyida Czarnecka and Joel Bez used under Flickr Creative Commons licence.
-- This feed and its contents are the property of The Huffington Post, and use is subject to our terms. It may be used for personal consumption, but may not be distributed on a website.