Not sure whether to build a PoC, prototype, or MVP first? This guide breaks down what each stage proves, what it leaves unproven, and what you need before approaching a contract manufacturer.
Most hardware founders walk into their first manufacturer meeting with the wrong artifact. Not because they didn't work hard enough, but because nobody told them that a PoC, a prototype, and an MVP are three completely different things that answer three completely different questions.
A PoC tests whether the riskiest technical assumption can actually work. A prototype tests whether the product can perform, fit, assemble, and function as intended across real-world conditions. An MVP tests whether a defined customer group will adopt, use, or pay for the minimum viable version of the product. None of these automatically proves that your product is ready for tooling or mass manufacturing.
The confusion costs hardware founders months of wasted time and budget. You build something, call it an MVP, show it to a contract manufacturer, and they hand it back. The enclosure may not be manufacturable as designed. The electronics aren't integrated properly. Tolerances may be misaligned with the production process. The assembly sequence doesn't exist. Starting over at that point is expensive. This guide helps you identify the right validation build before moving into hardware product development, tooling, and production.
Before a hardware product moves into manufacturing, founders need to validate different risks at different stages. A PoC confirms technical feasibility, a prototype verifies that the product can function and be used as intended, and an MVP shows whether a defined customer group will use or pay for it. After that, DFM review, EVT, DVT, PVT, and manufacturer-ready documentation are needed before tooling and production scale.
A PoC, prototype, and MVP are not interchangeable versions of an early product. They are different validation tools.
| Stage | Main question | Main risk reduced | Typical output | What it usually does not prove |
| PoC | Can the core technology or principle work? | Technical feasibility | Test rig, circuit, mechanism, experiment | Usability, demand, manufacturability |
| Prototype | Can the product work and be used as intended? | Product design, function, usability | Functional model, 3D-printed enclosure, integrated build | Repeatable production at target cost |
| MVP | Will a defined customer group use, pay for, or validate the core outcome? | Market and adoption | Limited real-use product, pilot unit, small batch | Tooling and full-scale production readiness |
A useful rule is simple: a PoC tests the idea, a prototype tests the product, and an MVP tests the market. The stages may overlap, but every build needs one clear job.
POC: "Can this critical technical principle actually work?" You're not building a product yet. You're running an experiment on the one assumption that, if wrong, kills the whole idea.
Prototype: "Can this product perform and be used as intended?" You know the technology works. Now you're finding out whether the actual product - the shape, the interaction, the performance - makes sense.
MVP: "Will a defined customer group find enough value in this product to adopt or pay for it?" You have a product. Now you're finding out whether the market actually wants it.
This is where founders get into trouble. Every stage deliberately leaves things unproven, and that's fine, as long as you know what those things are.
A PoC leaves usability, aesthetics, cost, and manufacturability unproven. That's by design. A prototype leaves market demand and production scalability unproven. An MVP leaves full feature depth, tooling readiness, supply chain reliability, and cost optimization unproven. Knowing what you're not answering at each stage matters as much as knowing what you are.
Software founders have absorbed a version of the MVP concept where you ship something rough, collect feedback, push an update, and iterate. That cycle can take days. For hardware, that same cycle takes weeks and costs real money. When you make a change to a physical product, you don't push a patch. You build a new version.
The word "viable" in MVP has two very different meanings in hardware, and both matter:
Customer viability: Does the product solve a real problem strongly enough for someone to adopt or buy it?
Manufacturing viability: Can this product be built repeatedly, at the right quality, at a cost that makes the business work?
A product can be completely viable to customers and still be unfit for production. Founders find this out at the worst possible time, after they've committed to tooling.
A 3D-printed enclosure is not automatically ready for the plastic injection molding process. The material behaves differently. Wall thickness requirements are different. Draft angles, tolerances, assembly sequence, fastener design, sealing: none of these are automatically solved because you have a printed part that looks right.
A printed prototype that fits together by hand often cannot be assembled in a production line. Electronics integration, component sourcing, and quality checks are separate problems entirely. The printed shell is a starting point, not a finish line.
A hardware PoC is a focused experiment. It's not an early version of the final product. It's a test designed to reduce one major technical uncertainty before you invest further. The output is evidence, not a product.
Build a PoC when your idea depends on something that hasn't been proven in the specific combination you need. Examples include:
✓ Can the sensor achieve the required accuracy in the intended environment?
✓ Can the battery support the intended operating time under real load?
✓ Can the wireless connection stay stable in a metal enclosure or noisy RF environment?
✓ Can the mechanism generate enough torque, force, or movement for the application?
✓ Can the selected material, embedded system, or thermal design deliver the required function?
You're not designing a product yet. You're running a test to answer one question.
A PoC should produce measurable results, not just a visual demonstration. Before you move to the next stage, the PoC should document:
✓ Test objective: What assumption is being tested?
✓ Assumptions tested: What do you expect to be true?
✓ Test setup: How was the test conducted?
✓ Pass or fail criteria: What result confirms the assumption?
✓ Measurement results: What did the test actually show?
✓ Technical limitations: What did you discover that you didn't expect?
✓ Engineering recommendation: Should you proceed, pivot, or test further?
If you can't fill in these fields, you don't have a PoC result. You have a demo.
Before you invest in product design, make sure you have tested the technical assumption most likely to derail the idea.
The prototype is where the concept becomes something physical that can be handled, tested, and improved. It's also where most founders spend the most time, and where the most important manufacturing decisions start to form.
Not all prototypes serve the same purpose. Choosing the wrong type wastes time:
Looks-like prototype: Focuses on visual design, dimensions, ergonomics, and product communication. It doesn't function, but it shows stakeholders what the product will look like and how it will be held or used. Useful for early investor conversations and industrial design review.
Works-like prototype: Focuses on functional performance: mechanism, electronics, sensor performance, airflow, load, or motion. It may look rough. It's built to test whether the product actually does what it's supposed to do.
Integrated prototype: Combines form and function for real-world evaluation. This is the version you test with users, show to manufacturers, and use to begin a contract manufacturing discussion.
Many hardware products use all three stages, although the sequence depends on the product’s biggest unresolved risk.
Before your prototype reaches real users, it should demonstrate:
✓ Product size and handling feel right for the intended user
✓ Ergonomics work in practice, not just in CAD
✓ Ease of use is clear without a manual
✓ Core functional performance meets requirements
✓ Assembly fits correctly and can be repeated
✓ Basic durability survives expected handling
✓ Heat, vibration, sealing, or load performance is within range
✓ Charging, maintenance, cleaning, and service access are practical
If users have to be coached on how to use your prototype, that's feedback, not a pass.
Also Read: How To Build a Product Prototype - 7 Steps
A hardware MVP is the minimum real product that delivers a meaningful result for a specific target customer. Not a demo. Not a prototype. A product that someone actually uses and that proves they find it valuable enough to continue using or paying for.
Your MVP should focus on solving one critical job, not showcasing a feature list. Real examples of focused hardware MVPs:
✓ A medical-support device that performs one intended care function reliably
✓ An IoT device that captures and transmits one essential data point consistently
✓ An industrial product that reduces one identified operational problem in a measurable way
✓ A clean-tech device that completes one core process task without failure
If your MVP tries to do everything your final product will do, it's not an MVP. It's a first version that isn't ready yet.
Customers using your MVP doesn't mean you're ready to scale. Before you commit to manufacturing, your MVP still needs to demonstrate:
✓ Reliability over repeated use cycles
✓ Safety under real operating conditions
✓ Repairability and serviceability
✓ Component sourcing is stable and not single-supplier dependent
✓ Customer willingness to pay at a price that makes unit economics work
✓ Manufacturing feasibility at the volumes you're planning
The right first build depends on your biggest unanswered question, not the label that sounds most impressive. If the underlying technology remains uncertain, an MVP can waste time and money.
| Your biggest uncertainty | What you should build first |
| Can the technology, mechanism, sensor, or circuit work? | PoC |
| Will users understand, trust, or operate the product? | Prototype |
| Will a defined customer group use, pay for, or validate the core outcome? | MVP |
| Can the product be repeatedly produced at target cost and quality? | Engineering validation and DFM prototype |
List every assumption that must be true for the product to succeed. Rank them by impact and uncertainty. A high-impact, high-uncertainty assumption should shape your next build.
If sensing technology is uncertain, start with a PoC. If users struggle with the physical interaction, build a prototype. If you lack adoption evidence, create a focused MVP pilot.
Work through these questions in order:
1. Is there a high-risk technical assumption that could invalidate everything? If yes, build a PoC.
2. Is the product's form, function, or usability still uncertain? If yes, build a prototype.
3. Is there enough evidence that a specific customer will adopt or pay for the product? If not, build an MVP before committing to tooling.
4. Is the product engineering-ready for DFM review, tooling, and pilot production? If not, you're not ready to manufacture yet, regardless of how good the MVP feedback was.
The sequence isn't always linear. Prototype testing sometimes exposes a technical problem that sends you back to a PoC. That's normal. Plan for it.
The right artifact changes depending on who you're talking to. Most founders default to showing the same thing to everyone, and it rarely works for all three audiences.
What investors need depends on the type of product and the risk they're evaluating:
✓ For deep-tech or engineering-heavy ideas, a PoC with documented results gives investors confidence the technical foundation is real
✓ For most hardware products, a functional prototype is the minimum for product credibility
✓ Early customer feedback, even informal commitments or pilot interest, reduces market risk in the investor's mind
✓ A clear product roadmap with an estimated manufacturing pathway shows you understand the path from prototype to revenue
Investors who understand hardware know the difference between a demo and a validated product. Don't oversell your stage.
A customer pilot requires the product to be functional, safe, and durable enough to send into the real world. Before running a pilot, your prototype or MVP should demonstrate functional reliability under normal use, basic user safety, durability through realistic handling, core feature readiness for the specific use case, and a structured way to collect and measure feedback. An informal "try this and tell me what you think" is not a pilot. It's a focus group.
CMs need more than a prototype to have a real conversation. Before you approach a manufacturer, prepare: preliminary mechanical CAD drawings, a Bill of Materials with component intent, material specifications, an assembly concept, expected production volumes, target unit cost, physical prototype samples they can reference, a list of known testing requirements, identified design risks, and any process assumptions you've already made.
Arriving with a 3D-printed shell and a concept deck gets you a polite response. Arriving with CAD, BOM, and a working prototype gets you a quote.
Give manufacturers the engineering inputs needed for a real production discussion.
Most founders think the path is: MVP works, customers like it, go to manufacturing. The actual path has several critical steps in between, and skipping them is where the expensive rebuilds happen.
These three validation stages exist to convert your market evidence into manufacturing evidence:
Engineering Validation Testing (EVT): Does the integrated engineering design (electronics, firmware, mechanical assembly) work as intended? This is where you find design flaws before they become tooling problems.
Design Validation Testing (DVT): Does the near-final design meet your functional, reliability, usability, safety, and compliance requirements? DVT uses near-production parts and tests them under real-world conditions. This is your last chance to make design changes before tooling.
Production Validation Testing (PVT): Can your suppliers, manufacturing processes, assembly line, and quality checks actually produce consistent units? PVT runs a pilot production batch to confirm the process works, not just the product.
Founders who skip EVT and DVT discover the same problems during their first production run, at full manufacturing cost.
Design for manufacturing review is not a box to tick after design is "finished." It's a process that should start at the engineering prototype stage and run through EVT and DVT.
Before you commit to tooling, resolve: material selection for the production process, wall thickness and draft angles for molding, part count and simplification opportunities, tolerance stack-up across the assembly, fastener and snap-fit design, PCB layout and component sourcing, assembly sequence and production test method, packaging and shipping risk, supplier capability and lead times, and serviceability for maintenance and replacement parts.
Every one of these discovered after tooling becomes a mold revision, a delayed launch, and a budget overrun.
Also Read: 10 Common DFM Mistakes You Must Avoid (And How to Avoid Them)
Documentation is not engineering paperwork. It is part of a sound compliance and IP strategy, helping you retain control of your product when you hand it to a manufacturer.
Before production begins, you should own and control:
✓ Approved CAD files with revision history
✓ Engineering drawings with tolerances
✓ Bill of Materials with approved suppliers and alternates
✓ Material specifications
✓ DFM report signed off by your engineering team
✓ Assembly instructions
✓ Test protocols for functional and quality testing
✓ Firmware or embedded-system documentation
✓ Supplier-ready manufacturing files
✓ Product requirements document
If a manufacturer holds any of these and you don't, you don't fully own your product. This matters more than most founders realize until they need to switch suppliers or negotiate pricing.
Most expensive rebuild situations come from three predictable mistakes.
Spending weeks building a polished enclosure and refined UI around a mechanism that hasn't been proven yet is one of the most common early-stage mistakes. PoCs should be fast and focused on the one assumption that could kill the project. If the core doesn't work, the enclosure is wasted effort. Prove the mechanism first. Everything else comes after.
A convincing prototype is not an MVP. It may look like the final product and demonstrate the core function, but it hasn't proven that real customers will use it, pay for it, or continue using it. More importantly, a prototype treated as an MVP skips customer validation and often skips DFM. Founders who do this discover manufacturing problems after tooling costs are committed, not before.
DFM problems discovered during tooling are not design reviews. They're emergencies. Changes to enclosure geometry, material selection, assembly sequence, component layout, and tolerances after tooling is cut mean mold revisions, production delays, and cost overruns. DFM thinking needs to inform prototype decisions, not clean them up afterward.
No. A prototype proves the product concept, interaction, or performance. An MVP delivers a minimum usable outcome to a real customer group and collects evidence of adoption or willingness to pay. You can have a great prototype that completely fails as an MVP, and that's useful information to have before manufacturing.
Usually, when a high-risk technical assumption remains unproven. If you're building with established technologies and known mechanisms, you may not need a dedicated PoC stage. The test is simple: is there a single assumption that, if wrong, invalidates the whole product? If yes, test it first.
Yes, but only if the prototype has gone through enough iteration to deliver a reliable, usable outcome to real customers, and if you've collected actual evidence of adoption or feedback. A prototype that impresses at a demo is not automatically an MVP.
Yes, where 3D printing is appropriate for the product's quantity, material requirements, and testing goals. 3D printing works well for small pilot batches, user testing, and functional validation. It does not confirm that the product is ready for injection molding.
Not necessarily. It must first pass a DFM review covering material choice, draft angles, wall thickness, part geometry, tolerances, assembly method, and tooling constraints. MVP feedback tells you customers want the product. DFM review tells you whether the product can actually be manufactured at scale.
Yes. For Class II and Class III medical device designs, regulated lab equipment, and safety-critical industrial products, an MVP cannot reach real end users before appropriate regulatory review, safety validation, or certification. In these categories, the "MVP" is typically the unit that enters clinical testing or regulatory submission, not one that goes straight to market. Founders building in regulated sectors need to plan their validation stages around compliance requirements from the start, not retrofit compliance after the product is built.
Not sure whether your product needs a PoC, prototype, or MVP first?
iMAC Design & Engineering Services works with hardware founders across all three stages: PoC feasibility assessment, prototype development, and manufacturing-ready engineering documentation. The process follows a structured seven-stage path: Design Research, Innovation & IP Strategy, Product Design, Engineering, Prototyping, Tooling, and Manufacturing, designed to move founders from concept validation to production without the expensive rebuilds that come from skipping stages.
If you have a hardware idea but aren't sure whether you need a PoC, prototype, or MVP first, iMAC can help you identify the highest-risk assumption in your product, define the right first build, and develop the validation plan and documentation you need before approaching a contract manufacturer.
Talk to iMAC's product development team to start with a structured feasibility review.
Download Brochure
