Proof of concept

A proof of concept (PoC, also called a proof of principle) is an early test showing that the key idea behind a new product or technical solution actually works. It answers whether the solution is feasible at all, not what the product will look like or what it will cost in series production. The output is a simple test sample, a lab setup, a calculation or a simulation, and above all a clear conclusion: the principle works, does not work, or works only under certain conditions.

A PoC focuses on one or a few critical project risks. Usually that is a physical principle (does the mechanism deliver the required force, does the temperature stay within range, does the sensor pick up the signal), the manufacturability of a key part with the chosen process, or the interplay of mechanics, electronics and software. Everything else is deliberately simplified: appearance, final material, operator safety and cost. A proof of concept therefore often looks like a makeshift rig of 3D-printed parts, off-the-shelf components and development boards.

In product development, the PoC comes early, after the initial study and before functional prototypes. On the technology readiness level (TRL) scale, it usually corresponds to level 3, the experimental proof of the key function. It differs from a functional prototype in scope: it validates only the critical principle, not the whole product. It differs from a minimum viable product (MVP) in purpose: an MVP tests whether customers want the product, a PoC whether it is technically feasible.

The scope is usually small, typically days to a few weeks of work. The value of a PoC lies in stopping or redirecting a project before money goes into detailed design, molds and certification.

A proof of concept makes sense when a project rests on an assumption nobody has tested yet: a new mechanism, an unusual combination of materials, a sensor in an environment it was not designed for, or a manufacturing process that even the supplier has no experience with. Typical users are startups preparing for investor meetings, grant and funding applicants who must demonstrate feasibility, and corporate innovation projects where management decides whether to invest in further development.

For products that only adapt a proven solution (a different size, a new housing, a modified existing part), a separate PoC is usually unnecessary, and the team moves straight to a functional prototype or the next design iteration.

The most common mistake is a vague brief. Before you start, write down which hypothesis the PoC tests, what counts as success (for example minimum force, accuracy, run time or power consumption) and under what conditions it will be tested. Without a measurable criterion, the result is easily read the way everyone hoped, and the project continues on shaky ground.

The second risk is mistaking a working PoC for a nearly finished product. A lab sample does not prove that the solution will be manufacturable, reliable, safe and affordable in series production, or that it will pass certification. The opposite mistake is polishing the appearance and design details of a PoC that only needs to answer one question.

If you outsource a PoC, agree in advance on the scope and deliverables (a report, measured data, a CAD model) and on who owns the resulting know-how and intellectual property. Protect sensitive information with a non-disclosure agreement (NDA).