What is POC in software development and how to prove your concepts in 4 steps

11

What is POC?

Proof of concept or POC is a verification methodology for software concepts. The main idea of POC is to prove that the concept is technically feasible and solves the real problem of intended users. POC can be a presentation or a PDF document — you only need to code when you get to the prototyping stage. However, proof of concept should contain detailed descriptions of technical requirements and specifications for a clearer project vision.

POC doesn’t exist only in software development. For example, directors make short films to demonstrate the main themes, characters, and technical tricks like using a green screen for particular scenes. These films are shown to producers so they can decide if the film idea is viable enough to make the full version. POC in the film industry takes a different form than in IT but the objectives are the same:

I don’t need it, developing an MVP is enough!

Unlike MVP development, the result of POC is not a finished product — it’s a prototype, which is an early draft of a product not designed for the actual market. Most importantly, proof of concept gives you a clarified vision of your project. And you’re not the only one who needs it. POC helps you attract investments. Your possible stakeholders need to see that your project has at least some ROI potential. And if you prove that your project is worth their money, chances are, you’ll make a deal.

Another benefit is identifying possible issues. POC prevents you from:

• • trying to build an infeasible app;
  • building an app that could have been developed easier, faster, and work better.

Not only does proof of concept help you make sure that you can actually bring the app to life but it also allows you to find the best solutions for future development.

Finally, POC saves you time and money. The lack of market need is one of the top 3 reasons startups fail. Proof of concept is more about technical feasibility rather than market research but it still helps you find out if people need your product.

OK, how do I prove my concept?

Imagine you want to build an AI that generates background music for working, studying, and meditating. Your friends think your idea is a little questionable — so you might think of your potential investors. To prove them all wrong, you use POC.

Define the market need

It sounds like the beginning of market research but it’s not. POC defines the market need not for promotion strategies or easier UX decisions. Here, you need it for different purposes, namely:

• • showing that there’s a problem;
  • proving that your product can solve it.

One way to get the data for this part is an in-depth interview with your potential customers. For this AI project, you can gather a sample group of people who listen to music while working or studying and ask them questions like:

• • Why do you listen to background music while working or studying? Does it improve your productivity?
  • If you do, which playlists or services do you use? What do you like and dislike about them?
  • What do you think of AI-generated music?

This is qualitative research, so you don’t need huge amounts of data. The ideal size of a focus group is 6–10 people and one interview is enough. But sampling is still tricky because of confounding factors — variables that can distort data and bring you to false conclusions. For example, be selective and don’t choose people who will not be interested in the outcome of your study — like this fair lady:

But at the same time be diverse. Men and women, zoomers and millennials, and people with different cultural backgrounds have different opinions that provide valuable insights. Apart from that, your research shouldn’t be biased towards a particular social group. For example, a male-only sample is not representative unless you make an app for men. And you can receive backlash from users for sexist UI texts in the future.

You should also remember that any outcome of your interview is valuable. It might turn out that people don’t need playlists composed by a machine — they are happy with a lo-fi hip-hop radio on YouTube. And that’s why you need this part in POC — if there’s no problem, people don’t need your solution.

A better outcome is when customers say that lo-fi hip-hop makes them sleepy. Or they can’t listen to live DJ sets because they get too focused on track transitions instead of working. This is where your endless generated playlist can help — it provides music that is not distracting and improves users’ attention span. If you discover the need for this product, proceed to the next part of POC.

Elaborate on the solution

You still don’t need to code anything. At this stage you should answer one question:

How will you solve the problem?

During the interview you identified the problem — users told you about it. The solution is your product. You need to provide a detailed description of your software project that includes:

• • the answer to users’ frustrations;
  • user scenarios;
  • architecture;
  • technical stack — languages, frameworks, data types, etc.;
  • estimated implementation time and required resources.

Keep in mind that you don’t write POC for developers — you write it for investors. Despite having a lot of technical details and assessing feasibility as the main objective, POC should be simple enough to be read by a person who hasn’t written a line of code in their entire life. When you describe the technical part of your solution, be specific but ditch unnecessary details. For example, important technical details to mention about our AI-generated music app are:

• • LSTM as a learning algorithm;
  • Music21 as an instrument for musical data processing;
  • Python as an AI programming language;
  • 3 learning datasets with each one containing 3 mln minutes of music in one genre (ambient, instrumental hip-hop, or house);
  • React Native as the main app-building framework;
  • 3 years of development.

And you don’t need to be more specific than that — a POC document should be detailed but simple.

Define success criteria

POC has two types of success criteria — technical and business. Technical criteria mean that your software works as intended and solves the problem it’s supposed to. Business criteria mean that your software brings you money. Details may vary for each project but both types of criteria should be SMART which means:

Characteristics	Don’t	Why it’s bad	Do
Specific	The app works.	Too abstract — how can you understand that it works?	The LSTM-based AI generates up to 24 hours of background music without overfitting. According to our in-app 10-scale survey, people don’t find it annoying, distracting, or uncanny, and the average score on these scales is not higher than 3.
Measurable	People like our app. The app brings money.	Both product reputation and economy have metrics.	The average rating on Google Play is 4.0 or higher. The ROI percentage reaches 6%.
Achievable	We release the final product in a month after POC.	It’s only realistic for no-code projects.	We finish deep learning in 2 years, develop an MVP in 3 months after getting satisfactory output from our AI, and release the final product in 6 months after testing an MVP.
Relevant	We also released a dating app.	It has nothing to do with the idea you’re verifying with this POC.	In case of successful MVP testing, we release the final product.
Timely	We reach 3,000 monthly active users (MAU).	It’s not time-bound.	We reach 3,000 MAU by the third quarter of 2024.

The key is thinking in numbers. Both technical and market success have metrics. Your objective at this stage is:

• • choosing the right metrics for your project;
  • defining realistic values for these metrics.

You can use the last column in our spreadsheet above as a reference. But keep in mind, this is only an example — MAU and ROI are not the only app metrics you can use as success criteria. And technical success criteria are more nuanced and depend on your project.

Make a prototype

A prototype is a working model of your future app. Unlike an MVP, it’s not designed for the general public and only gives you a rough idea of what the final release will look like. But it’s not the only difference.

Prototype	MVP
Tests the basic concept of a product	Tests the actual product and its features
Sometimes can be interactive but usually non-functional	Can be used despite limited functionality
Designed for stakeholders to attract investments	Designed both for stakeholders and for insights from user behavior
The foundation for an MVP	The foundation for the final product

In some cases, prototyping is not mandatory, like:

• • migration projects (for example, switching from native development to React Native);
  • minor changes to an existing product;
  • small-scale projects that don’t require months or years of development;
  • simple projects with clear requirements.

But if you’re developing a mobile app from scratch, especially if you’re using new technologies, you need a prototype. And it’s not only for investors — it allows you to:

• • add more details to your solution;
  • refine your solution to make the final product more user-friendly;
  • identify possible obstacles and lower the risk of code rework;
  • increase the development speed by using a prototype as a reference.

As we mentioned earlier, a prototype is only a model of your future product. But this model can be as detailed or as basic as you want — but not to this extent:

Prototypes can be lo-fi or hi-fi — take a look at their key differences:

Low-fidelity prototypes	High-fidelity prototypes
Usually non-interactive	Interactive
Created in Figma or tools like Justinmind	Requires coding basic features
Show basic design, user flow, and general app logic	Show the intended solution in detail

Not every project needs a high-fidelity prototype. For example, a set of 2D screens is enough for simpler projects like this.

But if you’re ideating a more complex solution and testing new technologies, an actual piece of software will be more informative to both users and investors. This is the best option for our AI-generated music app. But the amount of details is not the only thing to consider.

Another question is how you will use the prototype later. There are three kinds of prototypes based on their role during further development:

• • Throwaway prototypes are only used to gather feedback from users and stakeholders — later they are discarded. For example, you made non-clickable screens to show UI elements in Figma. After adjusting the prototype to users’ needs, you use this file as a reference — but these screens won’t become a part of your future MVP.
  • Evolutionary prototypes are pieces of software with basic features. During development this prototype will “evolve” into an MVP — you will use the same codebase. For example, you developed an app with one screen and one drop-down menu. This screen has a play/pause button and the menu allows you to choose one of three genres of background music. After presenting the prototype, you use the same project to add more screens and features.
  • Incremental prototypes consist of several models that show various aspects of a complex system. For example, you’re working on a mobile photo editing app. This project has too many features. You chose color correction, effects like noise or blur, and red eye removal. You built three working one-feature apps separately. After presenting the prototype, you combine these three projects into one app and keep adding more modules like exposure correction, layers, and other features.

Choosing the right kind depends on your project’s complexity. Incremental prototypes are the best choice for software with a lot of loosely related modules. Throwaway prototypes are good for simpler projects where you only need to test design decisions and user scenarios. Evolutionary prototypes help you test and showcase complex technologies, as well as create a solid foundation for further development. This kind of prototype is the best option for our AI-generated music project. 

Now, let’s take a look at the prototyping process step by step.

Defining your goal and key features. Prototyping begins with deciding what you want to model exactly and why your project needs a prototype. For example, you need to gather user feedback, show your solution to stakeholders, and test how good LSTM is at generating music before you start developing. To do this, you create a high-fidelity prototype of your app with short AI-generated music playlists as a sample.

Paper design. Start by sketching screen layouts to map out all the basic UI elements. At this stage, you don’t need to make your design too polished or detailed — you’ll do it later. Your sketch is good enough if it clearly shows the basic logic of the app.

Wireframes. Proceed to make a polished version of your paper design — draw your screens in Figma or a prototyping tool of your choice. If you’re making a lo-fi prototype, you can stop here. But it’s not the case for our example.

Clickable prototype. Add interactive elements to your wireframes — show the connection between the screens, button states, and animations. Clickable wireframes count as lo-fi prototypes too — if you’re satisfied with this amount of details, you can stop here.

Coding. If you’re making a hi-fi prototype, start building your software at this stage. It’s harder for AI projects — you need to show what the neural network is capable of, which requires more detailed prototyping. To save time, you can use less data for learning and generate less output — an endless playlist is too much for a demo.

Feedback and refinement. After your prototype is ready, present it to the focus group of potential users, gain feedback, and refine the project to meet their needs. For example, during the initial testing, your users complained about an irritating color palette, unclear interface logic, and performance lags in the background mode. You work on these problems and present the refined version again. Repeat until users are satisfied.

Final presentation. After refining the prototype, it’s time to show it to potential investors with your entire proof of concept research and user feedback you received earlier. The POC document itself doesn’t have any specific requirements — you can write it however you want, make a presentation, or use a free POC template from any source. Just make sure it contains all the elements we’ve mentioned earlier.

But what happens after POC?

In the best-case scenario, you proceed to develop an MVP to test specific product features and study user behavior. During this stage, you tweak the product to meet the market need. After successful testing, start working on the final release.

POC is important when you develop a mobile app with new technologies or work on unique solutions — but it takes time. And when it comes to innovations, time to market is crucial. By the time you release an MVP, the concept of your product can go obsolete. To speed up the process, you can outsource MVP development — and Purrweb is here to help.

It takes our team 3 months to develop an MVP with all the necessary features and beautiful UI. To save you time, we build cross-platform apps so you can bring your product to a larger market. We take care of every project from idea to app store. And yes, you still can decide if the app should have a chat function.

We’ll be happy to work on your project — tell us about your future app in the contact form below.

[wpim]