Proof of concept (POC) is an early stage of a project that allows you to check whether a given assumption is feasible. Read how to use the proof of concept approach in software development, when it can be useful and what benefits it provides.
Proof of concept is a method of verifying (proving) that an idea is feasible in the intended manner. It is carried out at an early stage of a project, before a prototype or MVP (minimum viable product) is even created.
Thanks to POC, it is possible to find out whether it is possible to realise the idea in the planned form, using economical means. When creating a proof of concept we try to answer one question:
Is the given task feasible?
Proof of concept in software development
You have decided to create a startup: a dating service that will match users autonomously based on matching their Facebook profiles and preferences on IMDB and Spotify.
You’ve worked out how the service will work, what features it will have, what it will look like and how it will make money. You found designers and programmers, created a prototype UX and UI. The programming work has begun.
A few months later, you find out that the developers are unable to develop an effective algorithm to associate users. Or that there is no way to retrieve music preference data from Spotify. Or yet another problem: it turns out that people with remarkably similar preferences don’t get along very well at all.
Now you’re in trouble: you’ve spent tens or hundreds of thousands, worked for many months, and now you have to take a big step back and throw some of the work (or maybe the whole project?) in the trash.
Could this have been prevented? Yes, with the help of a proof of concept.
Proof of concept example
The above idea for a dating service included several solutions that are not often used or widely known. These solutions were based on assumptions: that we could develop a matching algorithm, that it was possible to download preferences from Spotify, that the more similar the preferences the better the pairing.
Each of these assumptions could be tested in an isolated way before any other work began. Such tests would be relatively simple programming tasks that could be done quickly and inexpensively.
It was a matter of creating a simple script that retrieved the relevant data from Spotify, checking for unexpected limits on the part of the platform, performance issues, the existence of an API, or a way around the possible lack of an API.
The associative algorithm, on the other hand, could be developed on a piece of paper or in Excel and check on raw numbers what results the data simulations produce.
These simple steps are called proof of concept methodology and unfortunately, they are often overlooked.
Proof of concept in software development means checking technical feasibility of the planned solution. Most often it concerns checking if it is possible to combine several technologies and if the task is computationally or performance wise feasible.
One project may require multiple proofs of concept if more uncertain, risky points are identified.
When to use a proof of concept approach?
There are certain conditions under which a proof of concept approach can be highly beneficial. Consider performing a POC if your project contains unusual or innovative solutions (for example, a custom integration, a complex computational task, or a previously unused concept). For each such point, perform the simplest possible implementation to:
- Verify in practice that the technology can be applied in the way you planned.
- Determine what technologies will work best to solve the problem at hand.
- Identify unexpected blockers and be able to solve them “cheaply” – while still in the planning stage.
- Identify potential risk points, unexpected additional costs and unexpected dependencies in the project.
- Gain additional material to interest potential investors.
- Gain a better understanding of the issue across the project team.
Proof of concept in software development is most often used for:
- unusual integrations,
- using new APIs,
- solving computational problems,
- security issues,
- performance issues.
Proof of concept – practical advice
Write down precisely what you would like to test. Identify any “Can it be done…” questions that you are not sure of the answer to.
Develop the simplest and fastest method to check if the task can be done. If you want to check if it is possible to retrieve data from an external system, make the simplest possible script which will only retrieve the data you are interested in. If you are checking an algorithm or a computational problem – make a simulation in a spreadsheet.
Ignore UX, UI and any interface issues*. PoC answers the “IS POSSIBLE” question. The “HOW” question will be answered later by the prototype.
* unless the issue being studied is specifically about the interface.
Don’t deal with automation or optimization* of the processes being tested. Proof of concept is a kind of blurb.
* unless the issue you are investigating is automation or optimization
By doing a proof of concept you do not create a first version or part of a project. Proofs of concept usually end up in the trash because they are created without considering any architecture, optimization or other aspects that are considered during software development.
Proof of concept is not intended for users. It is an experiment for internal purposes. You will invite external users only to prototype and MVP.
Proof of concept is not for testing market demand.
Try to spend as little money as possible on the proof of concept and complete it in the shortest time possible.
Try to document and preserve your proof of concept – it may come in handy when you try to convince potential investors to fund it.
And most important: accept and take into account the conclusions of the proof of concept even if they are not to your liking. After all, you made the proof of concept to get information and to be able to incorporate it into your decision-making process.
Proof of concept vs MVP (minimum viable product)
Proof of concept is often confused with MVP (minimum viable product). However, these are two completely different issues:
POC
- intended for internal purposes
- it is used to check whether a solution is possible
- does not generate profit
- is done “dirty”
- is an isolated aspect of the whole product
- is performed with minimal resources
MVP
- is intended for users
- it can be used for market research
- you can make money on it
- it should be free of any bugs
- is already a working product
- requires more resources
Creating a proof of concept is like wandering around the board of a computer game, which reveals new areas only when the player reaches them.
The goal is to get as complete a picture of the map as possible before making a large investment of time and money.
Proof of concept helps to minimize risk, identify problems, and attract investors, thus increasing the chances of success for the entire project.
Write to us if you need help in identifying and executing a proof of concept for your idea.