Deprecated: Hook elementor/widgets/widgets_registered is deprecated since version 3.5.0! Use elementor/widgets/register instead. in /var/www/html/wp-includes/functions.php on line 5756

Deprecated: Function Elementor\Widgets_Manager::register_widget_type is deprecated since version 3.5.0! Use register instead. in /var/www/html/wp-includes/functions.php on line 5381
PoC vs Prototype vs MVP in Mobile App Development - Sprinthub: Top Software Development Company in Nigeria
Deprecated: Function Elementor\DB::is_built_with_elementor is deprecated since version 3.2.0! Use Plugin::$instance->documents->get( $post_id )->is_built_with_elementor() instead. in /var/www/html/wp-includes/functions.php on line 5381

PoC vs Prototype vs MVP in Mobile App Development

LAST UPDATED: July 3, 2020

Barisere Jonathan

MVP vs POC vs Prototype

The process of building an innovative product can be very iterative. You want to quickly know if your proposed solution can solve the problem for users.

The need to build product ideas using a minimum viable product (MVP) is now common knowledge. We have also written about the benefits of building an MVP in a previous article. But if you are here, then I am sure you want to know how MVP is different from concepts like Proof of concept (PoC) and Prototype. In this article, we explain what PoC and Prototype mean and how it relates to MVP. We believe that understanding these concepts can guide you in developing a successful mobile app.

Table of Contents

Case Study: FurryTracker

Let’s assume you have a furry friend, and we call her Kat. You have a complicated relationship with Kat, and you think a mobile app and hardware can help you relate with her better (good luck with that if she is a cat). You come to us to help create FurryTracker, your innovative solution to your Kat problems. Let us explore how PoC, Prototype, and MVP can guide you in making the FurryTracker product a success.

The Requirements

To help the app development team understand the requirements, you state your expectations as follows.

Kat is a nice fellow, but she is usually all over the house. I don’t want to restrict her movement. I just want to be able to find her easily when I need to.
Oh, it will also be nice if I can get notified whenever she is hungry or having a fever.

We conduct our discovery process [insert link here] and validate the following requirements with you.

  1. FurryTracker must show a fairly accurate location of Kat within the house. The required accuracy is at least what room Kat is in.
  2. FurryTracker may report the current body temperature of Kat and whether Kat is hungry.

We have the requirements, great! Now, where do we start?

PoC: Can it be built?

First, we need to determine whether your expectations are realistic, given the current state of technology; this will help us understand what kind of effort may be required, and it help will you determine whether it is a worthy pursuit. We go off to do some research on what it can take to build FurryTracker. Is there an existing system that can detect hunger better than just watching how Kat yawns? How about taking temperature readings? Location tracking to enable you to know when Kat leaves the house, can it be done cheaply (financial requirements, power requirements, connectivity, etc.).
After conducting a study, the team reports the following conclusions to you.

  1. We cannot reliably know whether Kat is hungry by relying on currently available technologies. We will have to invest in research and development (R&D) for such technology if you insist.
  2. We can determine Kat’s body temperature accurately using off-the-shelf sensors. Great.
  3. We can determine Kat’s location within the house by using existing indoor positioning systems. Still, there is one detail we need to figure out: how to fit the location reporting software on a small, energy-efficient wearable device for Kat.

You are okay with just watching Kat yawn. She even comes around when she is hungry, so [1] is not a problem. But there is still an unknown in [3]. To resolve that unknown before committing to something risky, we buy some off-the-shelf components and try to build a system that demonstrates that fitting a location reporting app on Kat’s wearable is energy-efficient, cheap, and possible. This last activity is an evaluation of technical feasibility, and the artefact we produce here is called a proof of concept (PoC).

proof of concept is a demonstration that shows the feasibility or practical potential of an idea or a method.

Prototype: How does it look?

In mobile app development, we value early and rapid feedback. We want to know early enough whether we are going in the right direction. Therefore, we build incrementally and iteratively. We want to get something in the hands of users as quickly so that we can collect feedback that will let us know is the product is usable.
For FurryTracker, we can use add an off-the-shelf sensor to a device to a strap for Kat’s neck and watch her walk, run and jump with it; this will also give us the chance to know if the device can handle shock without malfunctioning. The main focus at this point will be the usability of the product.

In this process of building incrementally and iteratively, we produce intermediate artefacts, such as clickable user interfaces, that you can use to determine whether your expectations and our work are still in sync. These intermediate artefacts are known as prototypes.

A prototype is an initial model of an object built to test a design. The word comes from a Greek word for “primitive form.” Prototypes are widely used in design and engineering to perfect items and processes before implementing them on a large scale. (Source:

While we are working, you would like to see how the work is progressing; this is what prototypes give you. Prototypes also give us a chance to reflect on what the final product will look and feel like so that it can be improved before launch.

MVP: When can users have it?

Work is progressing fine, but Kat is still playing hide-and-seek. You want this to be over soon. You want to know when we can give you a working first version that will up your little game with Kat. We can now skip the other nice-to-have (reporting Kat’s body temperature) that you mentioned. You just really want to know where Kat is hiding now, because she may be biting on your new shoes. You wish to receive a push notification on your smartphone when Kat leaves the house. This first version you are anxious for is called a minimum viable product (MVP). It must satisfy your basic requirements.

An MVP is a product that has the must-have requirements for early adopters. We know this by obtaining confirmation from you, hence the series of prototypes we had you testing. Your feedback on the prototypes steered us steadily towards your burning desire, and when it is met, we give you the MVP. It is this MVP that can help us learn the most from FurryTracker. We have determined that FurryTracker is good enough for your day-to-day use, and we can now analyse your use of the product to learn more about how it can be improved, if necessary.

In a way, the MVP is similar to Prototype, but it is not a prototype. You would not use a prototype on your furry friend: it may have a lot of sharp edges; it may emit energy waves that are too strong for her; it is not ready for use as a product; you can only validate the design. You would typically not buy a prototype car. Still, you may purchase Tesla’s next Helicar even though it is the first version that has been approved by the regulatory authority.Minimum Viable Product Development Process

MVP Development Process

MVP in a Nutshell

From the FurryTracker case study, you now know that we use PoC, prototype, and MVP differently in mobile app development. MVP is a technique from Lean Startup. It emphasizes validated learning as an essential part of a startup. A startup is in unfamiliar territory, so sensing the environment is vital for success; this success may be learning early that an idea for a solution is not feasible or marketable and stopping before taking huge losses.
Eric Ries said, “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The emphasis is on “validated learning,” and Eric Ries gives a few caveats right off the bat. We follow here with some more caveats and emphases, and we encourage you to read the original idea.


The minimum here does not refer to the feature completeness or the thoroughness of the product you build. Your product still has to solve the problem in a way that is usable for users, so you cannot sacrifice quality for speed in any way. What you can leave out is most of the nice-to-haves: features that do not contribute to the solution effectively. For example, you can build a website that explains the product better to your customers rather than adding another obscure feature to the product. You can also improve your website to enable your customers to self-serve rather than dedicate your marketers to strong-arming your customers into buying.


By focusing on obtaining validated learning, you can determine soon enough whether your product is viable. MVP should not be confused with minimum marketable features (MMF): depending on the economic positioning of your product, this validated learning may come from different sources. For example, although your product may win a lot of mindshare, there may be free alternatives available. Your product may be viable, wanted by customers, but not marketable yet. You may not even want to charge for it.
When we build MVPs, we recommend the following to help you get this validated learning.

  1. Telemetry; Being able to measure specific metrics, such as product usage, user engagement, the stability of your product to help you make improvements in subsequent iterations.
  2. Customer feedback medium like forms, surveys, and polls; make it easy for your customers to tell you what they think.
  3. Build tools to assist your team. It should be easy to track your cost of sale, the time it takes for customers to complete a purchase, how helpful customers find your landing page, etc.


Building a PoC is useful when you’re building a revolutionary product. If you are making something similar to a competitor’s product, then you can consider that as your PoC and move straight to building a Prototype (for user testing) and MVP for your early adopter.

An MVP allows you to obtain validated learning (from real users) about your product. This learning is essential in shaping your efforts on said product. To get your product idea from idea to MVP, you employ other learning aids as you build. Two such aids are proof of concept (PoC) and Prototype. A PoC tells you whether an idea or method is feasible; a prototype shows you possible designs for your idea and helps you obtain feedback for improvement. Applying these aids, you can build an MVP in an agile environment, taking advantage of agile methods to learn quickly and stay innovative.

About the Author

Let's connect


Message Sent