POC vs. Prototype vs. MVP in App Development

Trying to decide how and where to fit these three methodologies — proof of concept, prototype, and minimum viable product — into your app development plan? We’ve seen this before. The struggle is real.

But it doesn’t have to be. Once you understand that:

• The proof of concept (POC) method revolves around testing if an idea is doable,
• A prototype of an app is an interactive, working visualization of the product, meant to identify usability flaws in design,
• A MVP app is the core-value-proposition-wrapped-up-in-essential-features-only version of the product to bring value to the market ASAP

– it’ll all clear up.

It’s not about choosing either the one or the other. All three of these methods are used by product development teams to make informed decisions, based on tested and validated hypotheses, every step of the way.

So let’s set the record straight.

Proof of concept (POC)

In one short sentence, proof of concept is all about testing if a certain idea or concept is feasible or not. This method implies a really small, internal project, that has the end result of everyone involved understanding whether the idea has legitimate potential or not.

Think of this as a question with a clear “yes” or “no” answer — no in betweens. If your concept proves to be viable, then you can move on to the next step of your project. On the other hand, if your POC leaves you with a “no” answer to your idea, don’t despair. Gather all the knowledge you can from what you have just found out, and see if you can derive another concept from this experiment. If there’s a way, you want to be the first one to find it, right?

Just remember: be thorough in your experimentation. Applying the proof of concept method to your work should point your efforts (and investments) in the right direction, not the wrong one.

As an app development agency, we’re definitely no strangers to the POC technique. In fact, it’s part of our mindset. Having worked with a lot of startups in the past 4 years since we’ve been around, we know very well how important it is to be efficient with one’s resources.

Although the proof of concept method is definitely on the efficient side of doing things, you don’t necessarily need it. So what we like to clear up with the client at an early stage is:

Has this been done before?

If there’s nothing similar on the market with the mobile app our client is thinking of building, then applying the POC method to our working process is a must. It’s in our client’s interest, as well as ours as their development partner, that we only develop the features with real practical potential.

But if there are comparable apps on the market, why put in the time and effort to test out features that have already proven their value? In this case, it’s wiser to get your facts from what’s already out there.

Which brings us to our next question:

These two points go hand in hand really. Knowing what’s already out there means knowing if there’s competition and, if so, what it is.

Say our client’s idea is a messaging app. Obviously, there’s no need for proof that a messaging app is something people use, a lot. But there’s also reason to believe that it might not fly well since Facebook’s Messenger or WhatsApp are doing so good these days. So we might come up with a little extra something to spice up our messaging app, make it more appealing than the rest of them. Well, that “little extra something” we’re thinking of, could definitely use some POC.

Our advice: whatever features you’re thinking of adding to your mobile product, apply POC. It doesn’t have to be code just because we’re talking about apps. What it has to be is simple and clarifying. Get creative, and get to work.

Prototype

Knowing what to build is the first step. Knowing how to build it is the next one. And this is where a prototype of the mobile app you have in mind comes in very, very handy.

Compiling the results of the research done in the early stages of the project, we end up with a list of everything the strategy, design, and development teams assigned need to know, in order to make informed decisions regarding the app.

But just looking at it on paper isn’t enough. That’s why we always work with interactive prototypes of our projects. It’s the only way to get the look and feel of the app without actually having to go through the entire development process.

So if you were one of our clients, at this point you’d be able to check several matters on your list:

• Screens for core app flows
• User Experience (UX) / Usability of the app
• Special features you want to test out

Depending on the fidelity of the prototype it can also focus on:

• Polished User Interface (UI)
• Final designs
• Branding
• Copy

And by all means, don’t keep this app prototype to yourself. Have your stakeholders and investors play with it. Better yet, have your target audience play with it. Knowing how people would interact with your product would be very valuable in this stage. There’s still room to make changes and they won’t cost you nearly as much as they would later on.

A little hint: the chances of you not making any changes at all after having a prototype are slim. A prototype is not meant to be pixel perfect. It should, however, be perfectly capable of pointing out any errors regarding design or development early on, as well as generating new ideas regarding implementation.

Our advice: look at the prototype with a critical eye. Remember that prototyping again revolves around determining feasibility, just one step ahead of POC. In this stage, you’re deciding how to better develop the app, in order to make the core value as obvious as possible.

Minimum viable product (MVP)

Having discussed and worked on dozens of mobile projects, we’ve come to the conclusion that there’s a general misconception about:

• What a MVP app is
• When to consider building a MVP app

This misconception goes somewhere along the lines of this idea:

So let’s clear things up by first being on the same page about what a MVP is. We’ll just trust Eric Ries on this one:

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.

An MVP app is a basic, core-value-oriented form of your app, which you release into the market in order to gain valuable insights into how it works for your target audience, as well as your business goals.

This is not the time for fancy UI, nor extra features. This stage of product development is all about testing the app in the market. Doing so provides answers to a lot of questions regarding further product development stages:

• First and foremost: is the core idea viable or not?

If the target audience does not seem to resonate with the product, then there has to be a thorough analysis of why this might be in order to move forward. Is it because of a bug that just wasn’t detected on time? Is it a major flaw in the app’s functionality? Or is the idea altogether simply not fitting?

If, however, the target audience seems to comprehend the app’s core value and enjoy using the product, then you can move on to other points:

• How does the product stand on the matter of usability?
• Does the target audience find the app useful?
• Does the target audience like the app?
• Are there any defects in any of the user flows of the app?
• Are there any flaws in the UI of the app?
• Are there any features that prove to be uneffective?
• What features would work well in the app’s flow?

Now onto the second part of our discussion: you should build an MVP app only if your situation requires you to.

If your app idea is very similar to some other mobile apps that are already out there, then you should grab all the knowledge you can from what others have already invested time and money into finding out.

As Eric Ries puts it:

We have to manage to learn something from our […] product iteration.

If the lesson is already learned, there really is no need in repeating it, is there?

However, the situation does require a MVP app, if:

• Your product demands a different behavior from the user on a given matter
• The core value of the app is nothing new, the UI however is totally different
• The development budget does not allow for more

As for how many features an MVP app should include, how long it should take to develop it, how it should look like — all of this should be derived from the given context.

It’s exactly why we arrange a Product Discovery Workshop with all of our clients who come to us with an app idea. An idea has to be well defined and documented in order to obtain the right premises for subsequent decisions.

Our advice: don’t make the mistake of viewing a MVP as a mediocre version of your actual product. A MVP app should be a stripped-down version of your product — meaning it’s reduced to the essentials. If the essentials don’t get traction in the market, neither will they with a couple of fancy, costly features added.

Now let’s sum this up nicely:

Proof of concept

Approach: Is this concept feasible?

Implementation: The simplest, fastest, most precise way you can think of to either confirm or infirm your hypothesis about the user and your app.

App Prototype

Approach: How should the app be built?

Implementation: A visualisation of your mobile product in order for you to get the look and feel of the app and make enhancements to the design and development plan where necessary.

MVP App

Approach: What is the core value of the app?

Implementation: The MVP version of your product that you can launch into the market in order to gain valuable insights into how users interact with the app. Small investment, big payoff.

Like we said in the beginning, the one thing POC, prototype, and MVP have in common, is the fact that they are all based on the idea of thoroughly testing before fully investing.

Other articles on the tapptitude blog you might be interested in:

Complete Guide for better User Onboarding

The Start-Up Theory: Map a coherent user success flow

The Start-Up Theory: Mastering the Lean Canvas