Proof of Concept vs Minimum Viable Product

Proof of Concept and Minimum Viable Product are two very important tools used when working on the initial phases of software development project. What we’ve noticed is that our customers can often confuse these two or sometimes consider them to be the same. Since they aren’t, let’s take a quick look at the use cases for both of them to make it easier to place them in the development process.

Proof of Concept (POC)

This tool is employed at a very early stage of the process. Imagine a situation when you wake up one day with a new idea. You instantly believe it’s great, because we humans are biased, overly optimistic creatures, so before jumping into it feet first, we should see if this is feasible to create. In order to do it, you can create a Proof of Concept (or POC) that does one thing only: proves that it’s technically possible to create a software that matches your idea.

When working on POC, you can forget some of the principles of the good software development and focus on quick and dirty implementation that has to prove that technology is attainable. Consider these rules that govern POC development:

• There is only one feature in the build – the one that you are investigating. There is nothing else added other than what’s absolutely necessary for the thing in question to work.
• There is no UI/UX element to this project. Any UI that you piece together that allows you to use the software will do, even if it’s utterly annoying to use.
• The software is not meant to be used by a wider audience. It’s usually meant to be internal verification of an idea and therefore should be kept under wraps.
• In most cases, don’t bother with writing comprehensive tests or keeping the codebase tidy and refactored. You test the critical elements if that makes the development easier.
• There’s little sense in refactoring the code since the elements of POC are rarely used in the future stages of implementation. Typically, this code is kept for historical reference but not maintained afterward.

There is one more benefit from POC. It shows what additional and often unforeseen struggles you’ll be facing when building the real thing. When you think about the whole process, you do the POC to prove that the build is possible. That means that you don’t really know what exactly will be needed to achieve the goal, so you can’t really predict issues up front. Often, these occur when you attempt to integrate multiple third-party services. Basically, you read the documentation provided by the service and there’s always the promise of a nice, smooth integration, but getting your hands dirty quickly uncovers what’s missing in the APIs or what works slightly differently than you assumed it does.

Some of these issues need to be solved when building the POC, but most of them are possible to be put aside to be handled in the later phases. That’s cool as you already know what major issues you will definitely need to handle later and you can account for them when planning and budgeting.

Minimum Viable Product (MVP)

If you don’t know what is MVP yet, read our article about building MVP here.

This build happens at a later stage and it’s a significantly more substantial undertaking. You already know that the build is possible: you ran a verification campaign and have a list of interested potential customers. They’re waiting to be your early adopters and you need to deliver something that will prove to them that you can solve their issues. Minimum Viable Product is a completely different animal, and the rules that are set around its build show this clearly:

• This is the real implementation of the main feature of your project, in our case the one proven in the POC build.
• The main feature is encapsulated by some basic business process like user accounts, one-time billing or subscription model, and some informative pages that explain the product and the idea behind it.
• The application is aimed at real potential customers, they need to see the value and they need to see quality. Even though they are aware that the product is super early stage, the rule of first impression can’t be ignored. You want the people to praise your tool, to build hype around it and spread the news about its greatness.
• UI/UX doesn’t need to be perfect, but it needs to be thought through and working smoothly. The app does one thing and it should be doing it well so people can see that you’re able to pull off a bigger build in the future.
• Branding doesn’t need to be final, but it should align with what you envision for the final product so people are not confused.

While POC was your internal tool, you aim the MVP at your early adopters’ list. The goal is to gather their feedback and base any future development on the actual needs and requirements reported by that group of people.

Summary

So, the POC is technical proof and it’s not sophisticated enough to show to anyone outside of your team, but it’s quick and cheap to build. This way you don’t need to engage a bigger budget just to discover that you can’t really build what you thought.

With the MVP build on top of that idea, you’ll know it’s technically possible and what the initial challenges are that you’ll need to face. You can make an educated decision if you want to proceed with the MVP build and get it to your potential customers.

I hope that helps you wrap your head around what’s what in the process. We’re always happy to help you take your idea through the process and build your amazing idea into a real product. Therefore, we encourage you to start working on your idea today and get a project estimate via our MVP Calculator .