The Meaning and Methods of PoC in Software Development

by Mila Slesar

In this article, we would like to elaborate on the importance of a proof of concept (PoC) in software engineering and how we do it at Alternative-spaces.

On this blog, we often recommend starting with a minimum viable product (MVP) instead of attempting a full-fledged product at once. However, it’s worth noticing that this step usually is preceded by the proof of concept in software development projects. Moreover, occasionally, they wouldn’t even go as far as the MVP stage.

Even with established enterprises, IT projects often end up much pricier and take longer than planned or with disappointing results. The risks are higher for small businesses and startups that fail 9 times out of 10 for multiple reasons.

We believe that proper allocation of time and effort to the first stage of the development cycle can mitigate most risks.

Without testing the idea of an original software or new feature for an existing system, you risk wasting resources on something that turns out useless, won’t sell, or can’t be built with the existing technologies or within a given budget in the first place.

For tech startups, enterprises, and software companies, a proper application of PoC in software development projects gives the answers to crucial questions, such as:

Is the idea practical?
Is it possible to implement from a technological standpoint?
What resources are required to make the product?
Will it meet the users’ needs?
How will it work and look?
Is making the product worthwhile at all?

What Is Proof of Concept in Software Development?

Merriam-Webster dictionary defines proof of concept as ‘something that demonstrates the feasibility of a concept (such as a product idea or a business plan).’

Experiments around PoC in technology once involved cardboard duct-tape models, videos of simulations, etc. Currently, it’s more sophisticated, but the principle remains the same: to visualize an idea, prove its feasibility quickly, collect feedback, and demonstrate a product to stakeholders without actually building it. The cost of creating a PoC should be an absolute minimum.

When it comes to software, proof of concept experiments should prove, before proper development, that a proposed system, application, product, its variation, or a new functionality can work in real life.

There seem to be a variety of possible formats of PoC in software design and programming:

Documentation about the feasibility of an idea, e.g., by citing similar solutions
Win-loss or cost-benefit analysis
Experts’ assessment of a technical challenge and possible solutions
Presentation of the concept and the proposed product functionality
Target audience/user research
Wireframes of proposed web pages or screens
Clickable prototype that allows users to test its usability
Demo of a feature in question
A plug-in installed to see if an additional functionality works as expected
Sample truncated version of the product
Landing page presenting a novelty to target audiences…

… and so on. The simplest form is a Word document with a full concept description. It may suffice for experienced software developers to review this document and either confirm or deny your concept’s feasibility.

In Alternative-spaces’s custom software development practice, PoC typically refers to the first programmed version of a future product.

We create PoC to implement one specific feature to test a technical aspect that raises concerns, omitting auxiliary functionality, such as registration, collection of metrics, scaling an application, or optimization. It’s typically one PoC per feature.

There’s also a ‘prototype’ phase that can precede, overlap with, or follow a successful PoC. This may imply creating several primitive prototypes, e.g., paper models, to choose one that satisfies users or a high-fidelity clickable design prototype created using specialized software. While a PoC shows that a product can be made, a prototype shows how it will look and how it will be developed.

Prototyping brings a concept to life, showing the main navigation, layouts, etc., while PoC validates assumptions regarding the technical feasibility. It’s enough to give an idea of the future product and the costs, resources, and capacities required to make it work. The team can also check whether it is suitable for solving a particular business problem, evaluate the prospective users’ interaction with it, and identify possible performance issues.

Some claim that a PoC should prove that an idea is competitive and in-demand. We believe that only a released MVP can confirm the market demand.

A proof of concept may or may not require coding or participation of a designer, but it should yield documented requirements and technical specifications. This process involves experts who can determine whether an idea is achievable and suggest the right technical solutions. This can be done internally or with external help in the case of IT outsourcing.

A PoC project in app development may take up to 3 weeks so that a well-rounded experienced developer can:

verify technical assumptions;
show the essential parts of the product to stakeholders and possibly end-users;
obtain a clear yes/no answer as to whether to proceed with the development.

Based on the evaluation by experts or results of testing, entrepreneurs can decide whether it’s sensible to develop an MVP, not to mention the actual product. Here, we feel it might be necessary to clarify the difference between the two product iterations.

Proof of Concept vs. MVP

Proof of concept documentation paves the way to the subsequent stages of a product’s evolution, i.e. high-fidelity prototype and MVP itself.

A PoC can be called a ‘vertical’ prototype: it includes a basic user interface (UI) and a working back-end connected to a database to demonstrate the feature in action. However, a PoC cannot go to production. The software or feature has to be rewritten from scratch to be released.

In ‘horizontal’ prototypes created using InVision, Figma, or Proto.io, clickable screens can be interlinked via clickable buttons, dropdowns, and other UI elements, for people to interact with. Prototypes also allow running multiple tests and collecting feedback from real users without publishing the product.

Both PoC and a design prototype may have the appearance, structure, and content and simulate the functions, navigation, and interactions of a real product, but they aren’t. Neither are they released to the general public but tested inside a company or among a small controlled group of users, making changes until the result is market-ready.

Unlike PoC/prototype, an MVP is a fully-functional solution ready for the target market or intended audience. Only an MVP can give a precise answer whether the product solves real problems of real people. It puts the business model to the test, showing whether the consumers appreciate the software enough to pay for it.

MVP development may last up to 6 months, depending on the project complexity and scope.

An MVP is still the simplest version of a software. Usually, it includes just enough functionalities and features (sometimes only one) to attract the initial user base. The aim is to gather feedback from them, see whether it resonates with the stakeholders and consumers, fix bugs, and improve the next version. This way, you can gradually modify an MVP according to users’ needs until it becomes a full-fledged product and reaches the product-market fit.

That is the sunny day scenario. Otherwise, if an MVP fails in the market, there is still a chance for pivoting. PoC/prototyping provides this chance earlier at a dramatically lower cost.

Some of our clients order proof of concept development for attracting investment or winning tenders at the beginning of a project. When it’s time for more significant fundraising or subsequent negotiations rounds, they usually opt for MVP development.

The conclusion is simple: it shouldn’t be PoC vs. MVP but PoC + MVP.

Proof of Concept: Steps to Create

The iterative proof of concept process flow incorporates the design, development, testing, and evaluation processes. Within them, we can distinguish the following smaller steps:

Define the needs

Start by formulating your business goals and the real-life problems that the software or feature should solve. Describe the project idea, its purposes, and its benefits. Brainstorm on what market you wish to enter, the prospective audiences, your ideal customer, how users will use your proposed software or feature, and what it should look like.

Ideally, this stage should involve talks with potential end-users to identify their needs, pain points, and preferences. Those people may be a company’s employees or a sample group of consumers in a new market. You don’t have to interview hundreds of people; several people in the group voicing the same concerns should give you enough to think about.

Research into comparable solutions, if any, should provide many answers.

It would also help visualize your business model to present to the entire team, potential customers, and investors.

This stage should leave you with a list of defined goals and user problems to solve. You can keep updating this document as long as people read it and share their thoughts.

Ideate a solution

Brainstorm the potential solutions to the formulated problems and ways to fill the identified gaps.

The team is likely to come up with several options, so it would be helpful to prioritize them considering the possible costs, your capacities, competition, technical complexity, technologies needed, any timeframe limitations, etc. It makes sense to narrow down the list to the most feasible solutions that can best support your value proposition and fulfill the business goals. This discussion should involve a technical expert who can tell what is possible and what isn’t.

Keep the PoC scope narrow. Focus on the questionable parts of your software and pick 1-3 features to test first. They should directly relate to the users’ critical needs. Present the list of solutions to the end-users and stakeholders you interviewed and record their feedback.

Document the requirements

Write down everything you learned and created so far. It’s important to have engaged technical experts by this time because you need to choose the platforms, programming languages, and tools to develop and test the PoC and, eventually, an MVP.

Assemble your team

It would be enough to recruit an experienced project manager, a programmer, probably a solutions architect, and a UX/UI designer knowledgeable about projects in your domain.

If you choose to hire an in-house team, recruiting them may take as long as creating the POC. The optimal way is to engage a software development agency capable of realizing your idea from A to Z faster and cheaper while complying with all applicable intellectual property policies.

In any case, you need a software development team that has the proper resources, experienced developers, and a good sense of the market and industry.

Realize the idea

At this stage, the expert developer or team codes a rudimentary product with the core functionality based on the decided requirements, features, and solutions.

Depending on the nature of the product and your concerns about it, simultaneously, the designer can develop a low-fidelity or high-fidelity interactive prototype simulating a future user experience (UX).

The goal is to incorporate your proposed solutions into something you can give to potential users and stakeholders to collect feedback. It needn’t represent the ideated product perfectly, so don’t linger at this phase longer than it takes to build a basic testable PoC prototype.

Select the metrics for testing your idea

You need a set of comprehensible metrics to analyze vital information about the PoC and its use. It’s also essential to define the inputs, what output you expect, and what criteria should prove success or failure.

If your tested PoC meets the preset conditions, you can conclude that your idea is practical and can be implemented. If it fails to meet all the success criteria, it counts as a failure.

Test your PoC and gather feedback from intended users and stakeholders

It’s time to let the individuals in the sample group try the PoC prototype. 30-60 people will do. You can involve existing customers or users, if you have any. It’s desirable to create an environment imitating the proposed solution implementation.

Observe and record the people’s interactions with it and ask about their experience and opinions on your product using polls, surveys, and interviews. Be open to criticism and suggestions they may voice.

Assess the features’ performance according to the set success and failure criteria. It will be easy to tell at once whether the PoC addresses the users’ common pain points. Along with confirming the usability, feasibility, and competitive advantages of your solution, you will also be able to spot any UX defects, identify overlooked elements, and find ways to improve the product.

You may also guess whether the proposed product or feature has the potential to succeed in the market. Whenever needed and possible, try to show the PoC to potential customers and measure the simulated conversion rate.

Documenting the users’ feedback and other key performance indicators is essential to the next stage of your proof of concept development. The more information you have about what users want, the more opportunities to improve the product, saving time and money along the way.

Improve the idea realization and move on

Analyze the recorded user feedback to understand what worked and what didn’t. Fix the issues the users mentioned, enhance the core features, cut unnecessary ones, rethink unpopular parts of the design, and implement insightful suggestions. Test the improved PoC prototype again.

A PoC that meets your success criteria is proven to be interesting and doable. This gives you the green light to move to the subsequent stages – designing and implementing the MVP or complete software product or feature.

A failure can mean that the team has to

either solve the identified issues and test and improve the concept until the result satisfies you;
repeat all of the proof of concept steps listed above to create a different PoC;
or give up the idea if the response was mostly and strongly negative.

Even the latter case is not bad as it protects you from greater evils. The time and money you spent on your software proof of concept cannot be compared to the cost of failures that might occur later on.

Let’s sum up the main benefits of proof of concept development.

Several Reasons to Create PoC

Proof of concept development helps prevent costly mistakes associated with false assumptions.

Creating a PoC helps owners discover the software’s limitations for a specific problem and understand the advantages and disadvantages of their product idea.

By detecting potential design flaws before developing the product, teams prevent rework and avoid unnecessary expenses.

Working on the PoC, developers research various technologies and approaches for the optimal implementation of the idea. Multiple PoCs and iterations on a single PoC using different technology and design options help make the best decisions early on.

Knowing the technologies to use, you can find the right development team faster.

The iterative proof of concept process flow allows identifying inconsistencies, fixing issues, and improving or adjusting the features and lays solid ground for a smoother development process, testing, modifications, and launch later on.

It is a fast and cost-effective way to develop unique features or products ahead of the competition.

Developing a POC, project managers can pinpoint risks and obstacles they may face and find ways to alleviate the possible technical problems.

PoC helps PMs address the scope creep while they’re still in the discovery phase.

It can also give the idea about a product’s scalability and help foresee growth and mass-production regarding systems architecture, human resources, etc.

PoC development can boost the team’s confidence and motivation after receiving the first positive user feedback and expert opinions and recommendations.

Investors are more likely to fund proven ideas. A piece of successful proof will convince even the most skeptical stakeholders, attract investors, and facilitate negotiations.

Stakeholders and investors can get an idea of a product’s usability and profitability from vivid illustrations and presentations of actual data obtained during the PoC testing.

Alternative-spaces’s PoC Examples

Many successful projects realized for Alternative-spaces’s customers stemmed from prototypes and proof of concept development. We believe that it is more important for clients to understand the business aspect of PoC, while we can always offer a suitable solution and ensure its technical implementation.

For instance, lately, a healthcare entrepreneur has approached us with a complex system idea. The system would connect governmental entities and healthcare businesses. The endeavor’s success depended on the clinics’ desire to implement it. A prototype made in Figma showed how the service would look and work without writing a single line of code. We made a presentation, and the client took it to the field to validate his hypothesis with the clinics. They accepted the idea with enthusiasm, and currently, we are developing an MVP.

BSTEVR project provides a PoC example. Its founders envisioned a web application that would enable NFL fans to simulate games that wouldn’t have happened in real life and find out the points that might be scored. Users would just enter the team names into the online simulator configurations.

To do this, the BSTEVR founders required a system that would accurately simulate NFL games, calculate the possible results, and deliver descriptions of the games’ key points.

They prepared the project documentation before contacting us. One of Alternative-spaces’s leading developers analyzed it, came up with a solution, and quickly coded a demo version of the complex mechanism. Convinced of the feasibility of their idea and our competence, the founders decided to contract Alternative-spaces to build the MVP.

Alternative-spaces Can Turn Your Idea into a Viable Product too!

Proof of concept development may be the first step towards creating a popular and profitable software product. However, it takes considerable research, decades of custom software development, knowledge accumulated throughout hundreds of projects, an Agile mindset, and constant attention to the technology trends and best practices to choose a perfect technology stack for each unique project and identify underlying issues in advance.

If you have a business idea but don’t know where to start, why not contact Alternative-spaces? Our experts in many domains can offer a free consultation, assist with your idea evaluation after signing an NDA, and eventually help turn your idea into a successful product.

Content created by our partner, Onix-systems.

Source: https://onix-systems.com/blog/the-meaning-and-methods-of-poc-in-software-development