In enterprise software development, one type of project stands out from most others – a Proof of Concept. At times, you may come across planning or technical questions that have far-reaching consequences and no clear or easy answer. In these cases, it can be a good idea to spend a small amount of time and resources to build either a single example project or even a series of similar projects using various languages or libraries to determine what works and what does not. These kinds of projects are called Proof of Concepts (or POCs).
What Is a POC?
A Proof of Concept (POC) is a small, accelerated project with a very limited scope and schedule meant to investigate a single concept. POCs serve as a critical tool for reducing risk and validating ideas before committing significant resources to full-scale development. Whether you’re introducing a brand-new product, evaluating a new technology stack, or testing user behavior, a POC helps answer key questions early on. It allows teams to explore feasibility, uncover potential roadblocks, and gain stakeholder buy-in without the heavy investment of a complete implementation.
At the beginning, a clear set of measurable goals should be defined. These goals or deliverables will be used later to prove whether or not the concept is valid. Never forget that the deliverable of a POC is the validation of the concept; not the sample project that is built. The code developed within a POC may be used later within a new product if the concept is validated, but that should not be the primary goal. In most cases, to fit within a reduced timeline, the POC’s scope is often so sparse that typical deliverables are omitted (such as a proper design, documentation, unit tests, integration tests, etc.).
When to Use a POC
Not every idea needs a POC, but in the right situations, it can be the difference between a well-informed decision and a costly mistake. A POC is most useful when uncertainty exists—whether it’s about technical feasibility, stakeholder buy-in, or user adoption. Instead of diving headfirst into full development, a POC lets teams test the waters, validate assumptions, and adjust course as needed.
Here are some key scenarios where running a POC can provide clarity and direction.
New Product (or New Module)
If you’re considering building a new product or adding a module to an existing one, creating a mock-up of a Minimum Viable Product (MVP) can help bring your vision to life. A well-executed MVP serves as a powerful tool for gaining stakeholder buy-in, especially when seeking funding, as it provides a tangible way to demonstrate the concept and its potential value.
Consider who is most equipped to handle creating the MVP. Most design teams can create clickable mock-ups of a brand-new product faster than an engineering team can while updates to existing products are often more efficiently handled within the existing codebase. Team size also plays a role. If you have a smaller team, you may not have dedicated design staff with the bandwidth for a POC, so you’ll have to get creative and shift workloads as needed.
When working on a POC, never create more than is needed to validate the central concept! It’s common to skip whole sub-systems like data storage, testing, and authentication, but don’t stress; those will come later. Remember, the deliverable of a POC is validation, not perfection, so don’t waste valuable time on unnecessary details.
In these situations, defining clear deliverables will be more challenging. Sometimes, success is as simple as answering, “Will the board/leadership/investors fund this new product or module?” If funding is secured, your first priority is to add in the scope that was removed for the sake of time. Failure to do so will ensure that the product is doomed (from an engineering perspective) from the beginning, and nobody wants that.
Tech Stack and Product Evaluation
Another common genesis for a POC is to explore using a new third-party product or technical stack. For example, say that your current stack is getting a bit dated, or maybe a new requirement adds the need for a third-party dependency.
Often, a single stack or library is obvious, so you build a portion of your concept out with that new stack or dependency and then evaluate the results against your initial acceptance criteria. This exercise shows you how well the proposed project will integrate into your existing infrastructure. If you run into any issues, it’s much easier to pivot a POC than a fully planned and staffed project.
When multiple options exist, it becomes more complicated. For example, the existing project may have a new requirement for adding graphs to an existing UI. A product evaluation POC may start by finding all components that could provide the existing functionality. Once the list of possible products is defined, they will need to be filtered for business requirements, such as subscription or procurement costs, integration complexity, ease of use, and even how the aesthetics might match your existing UI.
If a clear choice doesn’t present itself, a build-off may be needed. Pick an instance of a graph that will need to be implemented, and add the same graph with each of the products you’re testing out. After adding multiple instances of the same graph, it should be easier to pick the most appropriate product just by looking at the product spec sheets.
User Acceptance
A recent concept I was asked to validate was whether users calling into the company’s phone line would accept the option to transfer to an online form via an SMS link. Before committing to a full product implementation, company leadership wanted to determine whether customers would be willing to move directly to an online portal during the call.
To keep the scope manageable, we started with a single call type (i.e., a single intent) as our initial focus. This allowed us to deploy the new functionality—controlled by a feature flag—in just three weeks, from ideation to production. The experiment’s metrics confirmed that a portion of customers were willing to transfer their conversation to a self-service portal on their phone. While it wasn’t the majority, the number was significant enough to justify further exploration.
As a follow-up, we expanded the POC to additional call types. Interestingly, we found that willingness to transfer varied depending on the type of call, offering valuable insights for future iterations.
Important Considerations
As useful as a POC can be to quickly examine complex scenarios, there are many things POCs are not useful for. A POC SHOULD expend the minimum amount of resources (such as time, staff, and money) needed to prove or disprove a concept. A POC SHOULD NOT be used as a means to shortcut proper development practices to super-charge a new project by bypassing the best practices that have been well established.
If you dive straight into full development without revisiting and incorporating proper testing, deployment processes, designs, and documentation, your development team will be stuck playing catch-up for multiple cycles. This will lead to inefficiencies, technical debt, and potential long-term setbacks.
Let’s discuss some of the most important considerations for engineers embarking on a POC.
Managing Expectations
From my experience, I always put more energy into managing expectations I expect to. It’s hard to transition management’s expectations after a short intense POC with wildly successful results back to business-as-usual. In the real world outside of a POC, delivery times are longer and end-user changes seem more minute because you’re back to producing artifacts that they care less about (ie., designs, documents, and testing).
Failure is ALWAYS an Option
Almost all POCs carry associated risk that the concept will not be viable (it’s in the name). Another way to say this is that failure is always an option. If you’re not working with this basic understanding, both amongst the participants and stakeholders, then you may not actually be running a POC. You’re likely running something else entirely! It’s hard to overstate how important it is that everyone involved is aligned on the expected goals and deliverables.
Feature Flags
Most POCs should not be deployed into production unless an actual part of the concept must be proven by actual customer interactions. In this case, extra care should be taken to ensure that if something unexpected happens, the new functionality can be disabled or hidden behind a feature flag. This is especially relevant when dealing with external partners that might not see your short-term project with the same level of urgency as you do.
In a recent POC that involved sending URLs with a newly registered domain via SMS, we found out how important the ability to disable the new functionality was. A network carrier decided our newly registered domain seemed like spam and added it to their default deny list. We had been live for less than 6 business days when our messages stopped being delivered. We were able to turn off the feature flag for this specific functionality to minimize an unfortunate customer experience.
Clear communications
During the following weeks (waiting for the service provider ticket to be resolved), I was thankful that I had clearly communicated with stakeholders. Everyone was on the same page that although we would be pushing the new functionality to production, there was much follow-up work needed if this were to be a long-term solution.
In particular, I listed a few steps that would be needed to show the network carriers that our messages were not spam. For example, the sender should be clearly identified, all messages were to customers with an existing business relationship, and did originate from a customer request.
Because the central question of this POC was specific to validating if customers would accept a transfer to online forms, we knew that a series of follow-on updates would be needed. In the confusion following having our messages blocked, I was able to copy and paste the previous conversation that outlined the steps needed next and the possible outcomes if not implemented. It was then much easier to explain that this was one of the calculated risks that we had previously discussed.
Conclusion
While POCs can be a very useful tool, it is important to be careful how you implement them. At the beginning of the project, a clear set of measurable goals should be established with a pre-agreed upon definition of success. The scope should be set as small as possible and only include requirements that will contribute to either proving the primary concept or exposing possible alternate concepts to be explored. Throughout the entire project, it is vital that everyone from the developers to the stakeholders share a common understanding of the goals and metrics that will be used.
I appreciate you taking the time to read my insights on POCs! If you found this helpful and want to dive deeper into software development best practices, emerging technologies, and industry insights, be sure to check out The Keyhole Dev Blog. We regularly share expert perspectives from our team to help you navigate the ever-evolving tech landscape. Thanks for reading!
