Phase 3: Proof of Concept
Proving the riskiest part of the idea in real hardware, as cheaply and quickly as possible.
On this page
A proof of concept is a rough build of only the part of the product that might not work. It is not a prototype. It is not meant to be shown to investors, customers, or anyone who will judge it on appearance. Its one job is to answer the question does the riskiest part work in real hardware?
Why this phase exists
Feasibility works on paper. Paper is cheap but it has limits. Some questions can only be settled by making something and measuring it: whether a mechanism binds, whether a seal holds, whether a sensor can read through the housing, whether a user can operate the control with gloves on. Proof of Concept exists for those questions, and only those.
Everything that is already known to work is left out. If the product is a known kind of enclosure around a novel mechanism, the proof of concept is the mechanism, held together with whatever is at hand. If the novelty is in the electronics, the proof of concept is a development board and some wires, not a finished circuit board.
What a good proof of concept looks like
- Ugly. Off-the-shelf parts, 3D prints, hand-cut metal, hot glue, a cardboard housing. Appearance costs money and proves nothing.
- Narrow. It tests one or two risks from the Feasibility list, not the whole product.
- Measured. It is built so that the result is a number, a pass/fail, or a video, not an impression.
- Fast. Days or a few weeks. If it is taking months, it has turned into a prototype.
- Disposable. Nothing from it is expected to survive into the final design, although some of it might.
Key takeaway A proof of concept answers one question with hardware. A prototype answers the question "does the whole thing work together?" Mixing the two produces an expensive, late answer to both.
Proof of concept versus prototype
The two words are used interchangeably in everyday conversation, and that causes real problems in quotes and contracts. The difference:
| Proof of Concept | Prototype | |
|---|---|---|
| Purpose | Prove the risky part works | Prove the whole product works and feels right |
| Scope | One subsystem, or one mechanism | The complete product |
| Appearance | Irrelevant | Matters; often close to final |
| Parts | Whatever is available | Chosen for the design, often custom |
| Number built | One, maybe two | A few |
| Who sees it | The engineering team and the owner | Investors, test users, sometimes customers |
| Cost | Low | Significant |
A firm that quotes "a prototype" when the idea has not been proven is either planning to do Proof of Concept inside the prototype budget, or planning a polished build of an unproven idea. Ask which.
What comes out
- The hardware itself, with test results.
- A short report: what was tested, how, and what happened.
- A revised requirements document. Proof of Concept often tightens numbers that were still estimates, and sometimes changes a "shall" to a "should" when the measured result shows the original target was unnecessary.
- A gate decision. If the risky part works, the project can move to Prototype with much more confidence. If it does not, the options are a different approach, a changed requirement, or stopping.
Typical cost and duration
Mostly labor, plus a small parts budget. Usually billed hourly, because the number of attempts needed is not known in advance. Parts at this stage are bought one or two at a time at retail or small-quantity prices, which is normal and does not reflect the production cost.
Common mistake Showing the proof of concept to people who will judge it as a product. It will look terrible, because it is supposed to. An investor or retailer who sees it may remember the ugliness, not the result. Share the test result, keep the hardware in the shop.
What to ask a firm about this phase
- "Which risk is this proof of concept testing, and what result would count as a pass?"
- "What will be learned if it fails?"
- "How much of this will carry forward into the prototype?" (The honest answer is usually "not much," and that is fine.)
Try this (15 minutes) Describe the cheapest possible build that would prove the product's key feature works. Then list everything that could be left out of that build. If the list is short, the key feature is probably not yet clearly identified.