MVP Development: What It Is and How To Estimate It

The MVP (minimum viable product) is one of the essential concepts for startups to understand firmly. Many startups run into trouble "shooting for the moon" and winding up unable to deliver anything of value in a reasonable timeframe. Or, at the opposite end, they'll aim for something so low that it's not impressive. Both of these scenarios can cause even the best ideas to go sideways quickly. It's not an understatement to say that MVP development is one of the most important things a startup will ever do


  • What is a Minimum Viable Product?
  • MVP Development Classifications
  • Advantages of Starting with Minimum Viable Product Software
  • How To Build a Minimum Viable Product
  • MVP Development Estimation
  • Minimum Viable Product Examples of Famous Startups
  • MVP Development Is Vital for all Startups

What is a Minimum Viable Product?

It's the basic set of functionality and user interface necessary to showcase what your product will be. Think about a car, for example. There's a lot of cool tech in vehicles now. You can have GPS, self-driving capabilities, and more. None of that, though, is required for a car to work. If you're looking to show that your company can build a car, you'd want to put in an engine, seats, gauges, tires, and some form of exterior covering. It wouldn't be a perfect vehicle, but it would work and show people what your vision is for the future.

In the example above, there's a vital subtlety to understand. The above car is "viable." What does "viable" mean? It means, broadly, the solution that you intend to ship with moving forward. In the example above, the car is viable. It has an engine, it works, and it has everything someone would expect from a vehicle. The minimum approach to a software problem might be to code up a shell script on your local dev box. But that's not viable, or, put another way, that won't translate to production at all.

So, in essence, the minimum viable product represents the minimum shippable functionality that adequately showcases what your idea is. This definition is, at heart, the answer to the question, "why is a minimum viable product important?" It's important because it encapsulates everything you'll need to draw in users, excite investors, and give your company the foundation it needs to thrive during the next stages.

Of course, as a project manager or entrepreneur, you need to define your MVP well. You'll need to include just enough functionality to excite users while excluding anything that doesn't add tangible value. If you don't define it right, it could cause significant problems later.

Without further ado, here's what you need to know about MVPs for startups.

MVP Development Classifications

There are multiple different approaches to developing MVPs. While many sites and people might call each method something different, usually all strategies boil down to one of four main categories. Before even thinking about your MVP's details, check out these classifications and see whether or not one would be a good fit for your particular project.

Concierge MVP Software

This way to build a minimum viable product is arguably one of the best because it connects you to your customers early on in the process. The idea is quite simple: instead of having automated systems do everything for your first customers, you have humans giving each one the white-glove treatment and manually performing all the tasks. These employees are effective "concierges" for your customers. This white-glove treatment becomes a core part of your initial marketing.

Food on the Table used this MVP type to launch their startup. According to Manuel Rosso, founder, "if you can't get them to adopt your idea with high-touch, face-to-face service, they sure as hell are not going to buy into your cold web page." That's very true. Many CEOs tell stories of how, in their early days, they were very hands-on, talking with customers, learning what they thought, and so forth. Even to this day, Elon Musk, for example, will spend time on Twitter responding to individual customer's questions. Jeff Bezos will still read emails from customers and asks employees to investigate matters using his signature single question mark.

By providing customers with concierge treatment, you accomplish two things. First, you cut your development costs considerably because now you're mostly worried about your front-facing UX. It also gets a boost for your marketing because selling a personalized approach to a problem is much easier than selling something cold and automated. Secondly, you make sure that you work out any issues with your process manually before you automate it. You can see what people like and don't like, where their questions are, and the feedback they have about your idea.

Pros: Startups can focus on the user experience and learnings from the concierge service while they refine the underlying processes. Founders and other employees can connect with the customers and continuously use those learnings to improve and iterate.

Cons: It's a lot of work. A concierge MVP for startups will not scale well at all. Therefore, if you find that your idea is a hit and generates significant excitement, you could find yourself struggling to fulfil all your customers' orders.

Wizard of Oz

This MVP for startups idea is very similar to the concierge approach. However, instead of giving each customer the "white glove" treatment, you build the front-end user experience as if you have already automated everything on the backend. That gives customers the impression that your site is powerful and robust.

This MVP approach doesn't implement an automated backend. Instead, to cut down on development cycles and work out your processes, employees manually perform all tasks.

Like the Wizard of Oz that looks powerful and mighty to the outside world, nobody needs to see the manual processes you're doing behind the curtain.

A little-known startup called Groupon used this approach. Initially, the founders started a blog called "The Daily Groupon." They'd manually post deals to this site every day. When someone signed up for a bargain, they'd generate a PDF and email it to the person.

Notice how inexpensive this initial site was. Using just WordPress and standard tools, they used the Wizard of Oz approach to make customers think they were a much bigger outfit than they were. That little WordPress site using email grew into a platform with a market capitalization of around $1 billion. That's proof that this building MVP

Pros: The Wizard of Oz approach is powerful. By focusing all your time and efforts into creating a front-end experience, you can tweak the experience before coding the backend. It cuts down development costs and enables rapid prototyping. As evidenced by the example, even a simple WordPress site could be a Wizard of Oz MVP.

Cons: Like the concierge approach, this does not scale well at all. If you find that you're getting plenty of orders, you could need to code backend solutions quickly to avoid having numerous angry customers.

Piecemeal MVP Development

The piecemeal approach involves taking individual software components and combining them to create a cohesive MVP. Projects built upon open-source software are usually excellent examples of this. You can take many open-source projects, create some "glue" code, and piece them together to create a cohesive solution.

Going back to the example above, Groupon was a piecemeal MVP to some extent. The founders took WordPress, an open-source platform, PDF generators, and email clients to put together a site that had some functionality.

However, usually, piecemeal approaches are more cohesive than that. As a quick example to illustrate this approach, suppose you wanted to build an MVP for a search engine. That's a complex problem, but there are already solutions that would let you put together a prototype search engine. Apache Solr, for example, enables you to search full-text. That could be the search backend. There are numerous open-source web crawlers, such as Scrapy. You could take what Scrapy finds and ingest it into Solr. Then, for your front-end, you could use WordPress. You could make your home page and then make a results page with a simple widget on it that queries Solr. Some open-source solutions will integrate Solr into your WordPress site, so you may not even need to write that code.

And voila! You have a search engine primarily built with open-source components. Will that alone beat the major search engines on the market today? Probably not. But it's an MVP. The pages you scrape and indexes you build in Solr are transferable to any more custom solutions you create later.

Pros: Very little development time means that startups can focus more on their ideas and less on the code. Since there are so many pre-built components, connecting them often results in a fast, reasonably efficient prototype. This approach works best if you can use a standard tech stack (see our guide to the best tech stack for startups).

Cons: You'll need to find the right components to use. Sometimes those won't exist. Or, if they do, sometimes it's harder to integrate them than it is to code something from scratch. For example, suppose one component used C# (Windows), and another was an open-source software package that was only compiled for Linux. Now you need two types of servers with connectivity between the two. (With Windows Subsystem for Linux, this may not be an issue now, but this is a rough example to show that the piecemeal approach can run into integration challenges).

Single Feature

The single feature MVP approach is different from the previous three we've discussed. With the earlier techniques, the goal is to build a functional version and make tradeoffs in coding time. You'll have a less perfect (often manual) implementation in exchange for a well-polished, complete user experience.

The single feature approach works by providing a less complete user experience but focusing on nailing the implementation right for its critical features. With this approach, you can focus on the top one or two features that your product has and tune them as effectively as possible. You can collect user data, resolve feedback, solve pain points, and more. Then, you can add more features as time progresses.

This type of approach works well with projects with one thing that they need to do well and features that will likely build on that aspect. An excellent example of a project that might benefit from a single feature paradigm is a new cloud service. Let's say you want to make a competitor to AWS or Azure. None of the approaches above would work that well. Instead, what's the one thing that all cloud services need to do (to some capacity) under the hood? They need virtualization. Whether users ultimately spin up compute engines, app engines, databases, etc., all cloud services require the ability to spin up isolated instances of platforms for customers.

So, you could develop your cloud competitor by focusing on that one aspect. Your initial MVP cloud could be the ability to create a cloud computing instance, complete with an OS. Once you have that, you can get customer feedback, see whether they like your user interface, whether they find the system speedy, and so forth. After you collect that data, you can continue to develop features based on that initial core concept.

Pros: This paradigm helps to cut out the "fluff" and keep you and your team laser-focused on the one or two features that matter to your application.

Cons: Some sites and apps don't work well with the single feature approach because, by their nature, they need to have multiple features to feel complete. Also, sometimes it's tough isolating the ideal single component to develop first.

Advantages of Starting with Minimum Viable Product Software

After reading the above classifications, you may be wondering why developers even bother with MVP development? Why not develop the entire product right away?

There are five main reasons why starting with an MVP is essential.

Less Time To Launch

Software is a competitive field, and the first company to market has a massive advantage over everyone else. Getting your idea into customers' hands as fast as possible is vital. With an MVP, you're not building the whole solution right now. You're making the essential parts. This paradigm means your development time will go down, and you'll get your idea out into the public much quicker.


Startups often don't have a significant amount of capital to start. Therefore, they need to make the best use of their time and money. By reducing the development time, you'll also reduce the costs. The initial MVP is more like a design project than an intensive development project. You'll focus more on the user interactions than the underlying backend code. That makes it much quicker and simpler overall.

Faster Iteration

With an MVP, you can iterate much faster than developing the entire project at once. Let's say you're creating a Groupon clone. If you use an MVP and handle all the orders manually, you can use the time you saved on the backend to tweak the user interface to maximize conversions, resulting in more sales. However, if you built the whole thing at once, you might have a suboptimal conversion ratio, making it tough to convince investors to fund your project further.

The Product of MVP Development Will Raise Funds

Having a well-done minimum viable product makes it significantly easier to raise funds. Think about it this way, suppose you have two businesses. One company has a prototype of their product working. The other gives you an abstract presentation about how their product will work, in theory.

In which project are you more likely to invest?

Most people will invest in the first business. It's much easier to evaluate the potential of a product when it's real and tangible. Many investors will not do business with someone that only has an idea. Even Kickstarter began requiring prototypes for campaigns because it made investors more likely to be happy and back someone's efforts.

Show investors something tangible with a real MVP. Even if it's not perfect and doesn't have all the bells and whistles, it will give the investment community more confidence in your company's ability to deliver.

Establish Your Customer Base Quickly

As mentioned earlier, software development often feels like a race. The first company with an innovative idea is the one that can capture the user base most easily. A well-designed MVP lets you hit the ground running, so to speak, by engaging your customers early and allowing them to sign up for your service instead of that of a competitor.

Think about the Groupon example earlier. By throwing up a WordPress site as quickly as possible, they established themselves as a trusted source of deals. If they had spent all their time perfecting a backend instead of working on the MVP, someone else might have come along and stolen their market position.

How To Build a Minimum Viable Product

Hopefully, by now, you feel convinced that starting with an MVP is the right thing to do for your business. If you have a startup, you have to start somewhere, and having a well-defined, well-built MVP is the best approach.

If your startup needs some minimal viable product software, here are the steps you need to know to build one.

Define Your Project's Goal

This point might sound simple, but there's a significant amount of complexity in that statement. For your MVP, you're going to want it to solve a particular problem. So think about your idea and then try and figure out what problem your solution will fix. Pick something relatively broad, but don't be vague. Think of it kind of like your MVP's mission statement.

For the Groupon MVP, the general goal might have been to save customers money with deals. For Airbnb, the objective may have been to provide cheaper places for people to stay and provide homeowners with an alternative income stream. Of course, nobody except the founders knows what goals each of these two companies had. Still, these objectives are examples of ones that are sufficiently broad to encompass plenty of features but narrow enough to be meaningful.

Map Out the User Stories

Once you have a goal for your project in mind, the next step is to map out the user stories. Put yourself in your users' shoes and imagine that they are coming to your site, app, or platform to solve the problem identified in your project's goal. Walkthrough their journey and write down what you expect the user to do at each step.

Let's say, for example, you're creating an e-commerce site that sells computers.

You'd first write down what your user wants to accomplish. That might look something like "buy a top-of-the-line computer."

Next, you'd identify the steps. First, they'd need to come to your site. Then, they'd need to search for a computer and filter it by speed/power. They'd add it to the cart, choose a payment, select delivery, and then hit the buy button.

You can then use this journey to ask critical questions like "how can this be done better?" In the example above, what if there was a top-of-the-line computer category or page? It seems like some people would want to see what the best of the best is that you offer. So, what if you reduce the steps to Browse Top Computers Page -> Select Desired Computer -> Add To Cart, Pay, Deliver, and Buy? Maybe that would be better, or perhaps not — that's for the startup to decide.

Prepare Your List of Features To Build During Your MVP Development

Once you have these steps, you can transform them into features pretty quickly. Continuing with the example, you'll need a search feature, a display list of your inventory, cart functionality, the ability to select delivery methods, and the ability to receive payments. Broadly, you'll need some form of an order management system, where customers can pay, and you can pick up those orders for shipping.

At this level, features tend to be relatively granular, so "search" is not enough. You might put one component to "search by CPU type," and another might be "search by graphics cards." You might also have features to search by intended use, like "gaming" or "business."

Also, note that, at this point, you're not thinking "MVP," so list out everything that you'd want your product to do. It would be best if you also looked to start defining your software architecture to scale well for whatever MVP you build. It should be a brainstorming session to figure out all the features that you would like to see for your idea.


Once you have the list of relatively granular features that correspond with your user stories, you prioritize them. Often this requires a little bit of market research to understand what user behavior is. For example, do customers search by CPU type when buying a computer, or do they look for "gaming PCs." A clothing store might have a similar debate about whether or not customers find by size or style.

Your goal should be to build the most commonly-used baseline features first. Prioritizing the parts that make your product feel like it is coming together and help motivate the team.

With each step in the user story, you'll have a list of features. You can order each one by step. So let's say you're on the "payment screen" step. You might have three features: pay with a credit card, pay with a check, or pay with PayPal.

Credit cards are the most popular form of e-commerce payment. So, that would rank #1. PayPal is more popular and intuitive to take than checks, so that would be #2. That, of course, leaves taking checks in position #3.

Define MVP

Now that you have your user story, the steps in that story, and a list of all the features you'd like, you can start defining the MVP. Look at the list of features associated with each part of the user story. What do you want to develop first? What can wait for later?

Continuing with the example above, you have a list that looks like this:

1. Take credit card payment

2. Take PayPal payment

3. Accept checks

What do you need to go live? Credit cards are the number one payment method globally, accounting for an estimated 41% of e-commerce transactions worldwide. So that needs to be in the MVP. eWallets, like PayPal, will likely account for up to 50% of all online purchases by the end of 2022. In some markets, they're preferable to credit cards.

By implementing those two payment methods, you'll capture about 90% of the transactions to your e-commerce site.

Since implementing both payment methods is relatively straightforward, you would probably take those two methods to define MVP. Then you can reassess and prioritize adding check support as necessary.

MVP Development Estimation

Once you have a clearly-defined feature set for your project, you can move on to the MVP product estimation phase. In this phase, you will create a roadmap for how long it will take to make your MVP in development days.

Estimating sounds easy, but it's quite nuanced. Software development can sometimes be tricky, and something that you think takes a day winds up taking a week. If you merely look at your features and guess how long it will take, there's a good chance you'll wind up oversimplifying the work involved and underestimate the time that it takes to build.

Fortunately, there are ways in which developers and project managers can better estimate the time that it will take to build the software.

Approaches To Minimum Viable Product Software Estimation

There are two approaches to estimating software: agile and fixed.

Agile estimation is an approximation rather than a guarantee. The agile MVP definition means that you recognize that you probably don't have 100% of the requirements upfront and that there will be some scenarios and things you can't think of now that will pop up as you develop the prototype. Therefore, developers and project managers need to be "agile" or "flexible" to adjust the estimates and development tasks as requirements solidify.

The advantage of this approach is that you can modify requirements more quickly to adapt to needs, challenges, customer feedback, etc., as you develop your MVP. Of course, the disadvantage is that it's nearly impossible to estimate how long the project will take with absolute precision. Your estimates can get pretty good, but without every single detail known ahead of time, there will be things that come up that you didn't foresee.

The fixed approach is the opposite of agile. Using this approach, you very clearly define every element of work, with exact requirements. If something comes up later that requires modification, it won't be part of the MVP.

The advantage is that you know precisely how many days the MVP will take and how much it will cost. The disadvantage is that there's no flexibility. If something comes up or user feedback suggests that something is problematic with the MVP, there's no wiggle room to adjust it. You've committed to a specific requirement set.

Modern software tends to favour a more agile approach since it's more "realistic." There are always things that you discover the further you go along in the development process. However, the fixed approach can be beneficial in some instances. If your startup has a fixed budget and you're looking to get an app done for a certain amount of money guaranteed, then the fixed approach is the way to go.

Software Requirements

No matter which method you choose, creating quality software requirements is essential. There are two components to top-quality requirements:

  • Text description of what the feature does.
  • Design, application map, or a clickable prototype.

Imagine, for a moment, a traditional login screen. You'll see fields on it for username and password. You might also see a "log in with Google'' button where people use their Google account to log into the app.

An excellent software requirement would have a design of that login screen and some accompanying text like:

"The login screen will contain the company logo and the text 'Welcome to My App' up top. There should be two fields. One for user name and the other for the password. There are two buttons, 'Sign In' and a 'login with Google' button. When the user taps the 'Sign In' button, the app will send a request to the server with the credentials. The server then validates these fields to see if the user has an account or not. If they do, the server should respond with a 200 HTTP code and a token. However, if there is no account, the server should respond with a 404, and a 'Sorry, you don't have an account' message should be displayed to the user. If the user taps on the 'Facebook' button, the application should show a web view asking the user to sign into their account. Once logged in to Facebook, the app should send a request with the relevant user data to the server to establish an account. Like before, the server should respond with 200 if it created the account. If the account creation fails, it should return 400 and the error should show to the user."

Notice in this example requirement how detailed the description is. If this is an agile spec, we would have the flexibility to say, "hey, our customers would love to be able to log in with Twitter too, so let's add that!" However, if we're following the fixed methodology, this would be immutable.

No matter which methodology you choose, if you're creating requirements, always remember to have a detailed description and a design. Having exact requirements will almost always lead to much better estimates.

Risks in Estimation of MVP Development

No matter how careful you are in developing your requirements, every project has potential risk factors. These are risks outside of your control, and, unfortunately, there's no way to plan or estimate for them. All you can do is call them out and keep them in the back of your mind.

A classic example of an external risk is a platform change or version upgrade. A long time ago, Apple decided to transition from the PowerPC platform to Intel. Imagine, if you will, that you were building an MVP shortly before the time of that transition. You would have estimated all your dev efforts for a platform that Apple was going away from, which likely would have meant you would need to append dev days to get your PowerPC code working on Intel.

Another potential risk is a version upgrade or deprecation of dependent services. One of the iOS 12 betas had some apps that stopped working. Google is notorious for killing services rather quickly. If there's a version upgrade or a dependency shuts down, that will impact your development timeline.

Minimum Viable Product Examples of Famous Startups

Creating an MVP is not a simple task. There's a lot of thought and effort that goes into making the perfect MVP that developers, owners, customers, and investors will love.

With all of the above in mind, let's explore three MVP examples for famous startups.


Amazon was once the most valuable company, but it was a startup in Bellevue, WA, in 1994. Jeff Bezos left his job at D.E. Shaw & Co. to found "Cadabra, Inc." Bezos changed the name to Amazon after a lawyer misheard what he was saying in a meeting and thought his company was "cadaver."

Bezos identified a list of 20 products that he could sell online. Eventually, he narrowed that list to the six most promising ones and then chose one: books. He chose books because of the worldwide demand for literature, low unit price, and the fact that there are so many titles available.

Bezos' first MVP was simple. It was a place where people could search for books and buy them. It also included a personal notification service that would let you know when your favorite author released a new book or when a version you already had was out on paperback. These are two simple, key features that every book lover would need.

Amazon is a fantastic example of a single feature MVP. They picked one user and one scenario (buying books) and nailed that experience. Only when they were growing substantially did they branch out to other business areas, such as AWS.


The MVP for Twitter shows the importance of doing a minimum viable product in the first place. Now known as a microblogging service, Twitter was initially "twttr," an SMS service that communicated with a small group. The idea came about while Jack and company were at Odeo, a podcasting company in San Francisco.

Odeo was facing stiff competition from Apple in the podcasting space, so they had to reinvent themselves. Jack Dorsey came up with the idea of an SMS service to tell small groups of people what you're doing.

The idea was that you could text 40404, and it would send everyone in the group your message.

The employees of Odeo were addicted immediately. The service was limited to employees only, at first. Then family and friends.

Eventually, Odeo let people go. Twttr let these fired employees stay connected. That showed the value of the service.

Twttr had some hurdles, though. At that time, most people were still paying by SMS message, so the service could rack up huge bills if people weren't careful. To counter that, they morphed the MVP into the microblogging service it has become.

This story shows how vital an MVP is. It got people excited. People instantly knew it would be addictive. And when the company fired everyone, they stayed connected with the platform they built, showing its value.

Twitter is another excellent example of a single feature MVP. It did one thing so well that it kept people hooked and inspired countless iterations until it became a multi-billion dollar company.

Groupon's MVP Development

Lastly, Groupon was another fascinating MVP. Andrew Mason, the founder of Groupon, received a $200 cancellation fee trying to get out of his cell phone contract. He had a new mission: "to build a platform for digital activism to fight such unfairness."

Andrew's initial foray into the business world wasn't even that technical. It was a platform called The Point, a 500-person mailing list comprised of subscribers from his office building. The entire "business" happened through that mailing list. The first deal was a 2-for-1 pizza slice deal, located at one of the office building's restaurants.

After ten months of perfecting this mailing list idea, Andrew got the idea of Groupon. The MVP was a WordPress blog that sold t-shirts. The only way to buy one of those shirts was to send an email. On the backend, Andrew would generate coupons with FileMaker and send them to a mailing list via the script running on his local machine.

The Point was the initial audience for Groupon. His ideas eventually took off. The Point died off, but the initial idea that was The Point kind of lives on in Groupon — a platform where consumers can get better deals through collective buying.

Groupon is a fantastic example of a concierge MVP in The Point that led to another Wizard of Oz piecemeal MVP that wound up worth billions.

And that's the beauty of MVPs. You can test your ideas without spending a fortune.

MVP Development Is Vital for all Startups

Having a high-quality, well-estimated MVP is vital for a startup's success. Since the MVP is the springboard for all future development, getting it right is of the utmost importance. A quality MVP could make the difference between having a company worth billions and having a company that goes bankrupt.

If you're interested in developing, defining, or getting help with a lean MVP that dazzles, Impressit is an MVP development company with extensive knowledge in this domain.

Please contact us. We'd love to learn more about your project and help you create the best MVP for your startup.