In short
A proof of concept (PoC), in German Machbarkeitsnachweis, is a deliberately small test that shows whether an idea, technology or architecture can work under real conditions. A PoC answers exactly one question: "Does this work at all, and in the way we need it to?" It is not a product, not a prototype for users and not a first expansion stage, but an instrument for gaining insight.
In software development and in system selection in e-commerce, the PoC is the most important means of avoiding expensive wrong decisions early on. Anyone evaluating a new platform, a framework or an integration can believe data sheets, demos and references, or check for themselves whether the critical points hold up in their own environment. The PoC is the second option.
What a proof of concept is and what it is not
The term is often used sloppily. A PoC is not a finished partial product. It may be ugly, incomplete and unmaintainable, as long as it answers the initial question cleanly. It is typically discarded after evaluation or archived as a knowledge base, not reused as a foundation for production.
Meaning and origin of the term
Literally, proof of concept means "proof that the concept works". The expression does not come from software development. It has been documented since the late 1960s, at that time for a development phase in which experimental hardware was built and tested. Today it is also common in engineering and drug development. The core is usually the same: proof that a concept holds up before time and money flow into full implementation.
In IT security, the term has a meaning of its own. There, a PoC often refers to sample code that exploits a vulnerability and thus proves that it is real and exploitable. Well-known security vulnerabilities such as Heartbleed (CVE-2014-0160) became tangible for defenders and attackers alike through publicly available PoC exploits.
PoC vs prototype vs MVP: the differences
Proof of concept, prototype and minimum viable product (MVP) are often mentioned in the same breath, but they test three different risks. The PoC asks about feasibility, the prototype about usability, the MVP about the market. The table sets the three formats side by side.
| Criterion | Proof of concept | Prototype | MVP |
|---|---|---|---|
| Key question | Is it technically and functionally feasible? | What does it look like, and can users cope with it? | Do real customers use the product, and does it pay for itself? |
| Risk tested | Technology, integration, load, data quality | Operation, comprehensibility, acceptance | Demand, willingness to pay, business model |
| Audience | Project team, decision-makers | Future users, stakeholders | Real customers on the market |
| Typical form | Technical test set-up, often without an interface | Wireframe, click model or designed draft, often without real logic | Working product with a few core functions |
| Quality standard | Low, throwaway code permitted | Medium, focus on operation and design | Production-ready, including security, data protection and operation |
| Effort | Small and firmly limited | Small to medium, in iterations | Considerably higher, moves into continuous operation |
| Result | Decision: continue, adapt or stop | User feedback and a revised concept | Usage and market data for further development |
| What happens next | Findings flow into implementation; the code is rewritten | Serves as a template for design and development | Is developed further step by step |
Two definitions help with classification. Eric Ries, who made the MVP well known with the lean startup method, describes it as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The Nielsen Norman Group calls a user interface prototype a hypothesis: a candidate solution for a particular design problem. The guide to MVP development shows how an MVP is created step by step.
A fourth term is often confused with the MVP: the pilot. It tests whether a solution works in real operation with selected users, for example at one location or with one customer group. A pilot is close to production and ends with roll-out or a correction. In some teams, a PoC is also called a "technical prototype". What matters is the question the trial is supposed to answer; the label is secondary.
The distinction is important because the terms raise different expectations. If a PoC is treated as an MVP, hastily written test code ends up in production. If an MVP is sold as a PoC, those involved underestimate the effort for quality, security and operation.
In short: the PoC proves that it works. The prototype shows how it feels. The MVP shows whether anyone wants it.
When a PoC, when a prototype, when an MVP?
Which format fits is decided by the biggest open question in the project. Three checking questions sort this out:
- Is it unclear whether it works technically? Then a PoC first. Typical triggers are a new platform, a critical interface, expected load peaks or an AI component whose result quality nobody can predict.
- Is it unclear whether users understand and accept the solution? Then a prototype. A clickable prototype shows in tests with future users where the process gets stuck, before the first line of production code is written.
- Is it unclear whether customers will use the offering or pay for it? Then an MVP. Only a test on the market answers this question, and for that the product has to stand up to real customers.
The PoC is therefore the right tool when there is a concrete technical or organisational risk that can be isolated and measured with limited effort. Without such a risk, it is busywork with a project name. If the technology is mature and has been tried and tested many times in similar environments, a reference check with conversations with existing users is often enough.
The typical sequence
In software projects, the formats often follow one another: the PoC clarifies the technology, the prototype the operation, the MVP the market, and finally a pilot tests operation. This chain is not mandatory. If the biggest risk lies in user guidance, for example with a customer portal for dealers, the prototype comes first.
PoC and prototype can also run in parallel, because they answer different questions and are often built by different people: the PoC by developers, the prototype by UX designers. It is important that each stage ends with a conscious decision. Anyone who slides from the prototype into the MVP without evaluation gives away the advantage for which the stages exist.
How a proof of concept runs in six steps
A PoC without a clear question becomes a tinkering project. The following steps have proven themselves for technical evaluations.
- Formulate a hypothesis. Not "We are testing framework X" but "Framework X can map our pricing logic with customer-specific tiers while serving 200 requests per second." A verifiable statement is the prerequisite for a clear result.
- Define success criteria in advance. What counts as passed, what as failed? Measurable criteria prevent the result from being glossed over afterwards. They are derived from the requirements. If these are not yet available in writing, it is worth having a requirements specification drawn up first.
- Limit the scope. Test only the risks, not the overall system. The biggest unknowns come first; standard functions are left out.
- Set a time frame. A PoC without a deadline gets out of hand. A few weeks are usual for technical evaluations; days are enough for smaller questions.
- Create realistic conditions. Real data volumes, real interfaces, real edge cases. A PoC with toy data proves little.
- Document the result and decide. At the end there is a clear recommendation with reasons: continue, adapt or stop. Even a failed PoC is a success if it prevents an expensive wrong decision.
In everyday agile work: the spike
In agile teams, a very small, technical PoC is often called a spike. The term became known through extreme programming. It means the simplest possible program that addresses only the problem under investigation and ignores everything else. The XP rule recommends assigning a pair of developers to it for one to two weeks and openly expects the code to be thrown away afterwards. A PoC for a platform choice is larger but follows the same logic.
Typical questions a PoC answers in e-commerce
- Can our pricing and discount logic be mapped in the target platform without special solutions?
- How robust is the connection to ERP and PIM with real data volumes and error cases?
- Can the architecture withstand the expected peak loads, for example during promotional periods?
- How much effort is involved in migrating product and customer data?
- Can the teams actually operate and extend the new technology?
An example: platform selection at a mid-sized company
A common use case is deciding on a commerce framework. With a modular, code-heavy system such as MedusaJS, the value of a PoC lies in the fact that many properties only become apparent in your own context. Such a PoC usually runs for four to eight weeks and has a fixed scope: a standard storefront, a payment provider, an ERP connection and a clearly defined use case.
The goal is not the finished shop but a reliable answer as to whether the framework works as promised under the actual requirements. You can find the classification in the entry on MedusaJS.
Points often emerge that are missing from data sheets: licence boundaries for functions such as rights management or corporate log-in, the effort for individual pricing logic, the maturity of integrations or the frequency of breaking changes between releases. A PoC that deliberately includes these points as test cases gives decision-makers more substance than any presentation.
Evaluating and documenting results
The value of a PoC only comes from its evaluation. A short results report with a fixed structure makes sense: initial question, approach, measured values, observed problems, assessment against the criteria defined in advance and a recommendation.
The separation of observation and interpretation is important. "Importing 40,000 items took 35 minutes" is an observation. "That is sufficient for our overnight run" is an assessment that has to be measured against a window defined in advance.
Open risks also belong in the report. No PoC covers everything. What has not been tested should be explicitly named as untested, so that decision-makers know the framework of residual risk.
A simple traffic light logic per hypothesis has proven itself: confirmed, partially confirmed, refuted. For partially confirmed hypotheses, the report states what is still missing for confirmation and how much effort it would take to check it.
Weighing up costs and benefits
A PoC costs time and money, and that belongs in the calculation too. Comparing it with the risk it covers helps as orientation. If a platform decision ties up a large budget over several years, a PoC that costs only a small part of it is cheap insurance. For small, easily reversible decisions, on the other hand, the effort is rarely worthwhile. The rule of thumb: the more expensive and the harder to reverse the decision, the more likely a PoC is to be worthwhile.
It is also important who bears the costs. With external service providers, the PoC should be commissioned as a separate, clearly described package with a fixed scope and a fixed end. This protects both sides from a test unnoticeably turning into a project.
Common mistakes
The PoC becomes the product. The classic mistake: the test goes well, the deadline pressure is high, and the code goes into production. Later it turns out that architecture, tests and security were never planned, and the project starts with technical debt. The rule is: whatever was created as a PoC is rebuilt or at least thoroughly reworked.
No defined end. Without success criteria and a deadline, every PoC becomes a permanent project. It consumes resources without leading to a decision.
The wrong questions. What is easy is tested, not what is risky. A PoC that only shows the happy path merely confirms what was already clear.
Bias. If the PoC is carried out by advocates of a solution, the result is often friendlier than reality. Critical questions should be asked by someone who has not already made the decision.
Skipping the PoC. The opposite mistake is widespread. Anyone who starts straight away with an MVP builds in architectural decisions that are difficult to revise later. A short, focused PoC is as a rule cheaper than correcting a wrong platform choice.
The wrong format. A PoC is supposed to clarify whether users can cope with an ordering process, or a click model is supposed to prove that the ERP interface can withstand the load. Neither format can answer that question. Clarify the question first, then choose the format.
PoC, discovery and tender
In larger projects, the PoC does not stand alone. It is part of a sequence of requirements clarification, evaluation, decision and implementation. In the preliminary phase, a discovery phase clarifies what the system has to do. The PoC then tests the riskiest assumptions.
In public tenders or selection procedures with several bidders, the PoC is occasionally used as an evaluation stage: the providers build a defined excerpt, and the results are compared against the same criteria. This increases comparability but causes effort on both sides and should be remunerated appropriately.
The PoC is particularly widespread in AI projects, because the quality of the results is hard to predict. Whether a language model delivers product texts of the required quality or reliably classifies customer enquiries is best tested with real data.
Here too, the rule applies that a successful PoC does not yet mean a production-ready system. The gap between demo and operation, with monitoring, data protection and error handling, is regularly underestimated.
Outlook
Generative tools considerably shorten the way to a working test set-up. With AI coding assistants and vibe coding, what used to take weeks can now sometimes be created in days. This does not change the logic of the PoC, but it does sharpen one risk: when a result is created quickly and looks good, the temptation grows to take it for more than it is.
The discipline of defining the hypothesis and success criteria in advance and assessing the result soberly is therefore becoming more important, not less. For decision-makers, the rule remains stable: a PoC is an investment in information. It should be small, answer a clear question and make a decision possible at the end, in whichever direction.
Frequently asked questions about the proof of concept
What is a proof of concept?
A proof of concept (PoC) is a proof of feasibility: a small, time-limited test that shows, with data that is as realistic as possible, whether an idea or technology works under real conditions. At the end, there is a decision about how to proceed.
What does PoC mean?
PoC is the abbreviation for proof of concept, i.e. proof that the concept works, usually called Machbarkeitsnachweis in German. In IT security, PoC also stands for sample code that proves a vulnerability can actually be exploited.
What is the difference between a PoC and an MVP?
A PoC answers the question of technical feasibility and is usually only visible internally. An MVP is a production-ready minimal product that shows with real customers whether the offering can sustain itself on the market.
What is the difference between a PoC and a prototype?
The PoC tests whether something works technically and often does without an interface. The prototype shows how a solution can be operated and often only pretends to work behind the scenes. The PoC is aimed at the project team, the prototype at future users.
How long should a PoC take?
As short as possible. Four to eight weeks are usual for technical platform evaluations; days are often enough for individual questions.
Who should carry out a PoC?
A team with sufficient technical depth that does not profit solely from a particular result. It is often worked out jointly by internal specialists and external partners.
Is the PoC code reused later?
As a rule, no. Findings and architectural decisions flow into the implementation; the code itself is rewritten or thoroughly reworked.
Further sources
The German Wikipedia article on the proof of concept offers a general overview, and the English-language article covers the history of the term since the 1960s. The security vulnerability mentioned is documented in the National Vulnerability Database entry on CVE-2014-0160.
The MVP definition comes from Eric Ries' 2009 article "Minimum Viable Product: a guide", and the description of the prototype as a hypothesis from the Nielsen Norman Group article "UX Prototypes: Low Fidelity vs. High Fidelity".