In this article, EnCata reveals and decomposes the terms Proof-of-Concept, Minimum Viable Product, and Prototype using real-world examples for clarity.
Our team frequently encounters questions about the differences between Proof-of-Concept (PoC), Prototype, and Minimum Viable Product (MVP). This isn't surprising: each of the three validates a concept, and a "prototype," as a product form, essentially embodies that "minimum viability. Let's see how they work in the new hardware product development process.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54d923634296f944c4e0_667befc72a528da2e47ec921_1.jpeg)
When customers approach us with requests to "develop a prototype/PoC/MVP for a future device," we immediately ask clarifying questions because there's a chance we might envision different outcomes. "Where will this device variant be used?" "Will you show it to your audience?" "Are you planning to demonstrate it at a trade show?" "Are you confident in the concept's feasibility?" To avoid misunderstandings for both the customer and the contractor, it's essential to understand the differences between these terms, what they influence, and to what extent.
Can PoC and MVP be Prototypes?
Before giving a definitive answer, let's first clarify the meaning of the word "prototype" within the hardware engineering realm. Wikipedia states that a prototype is a rough model. Going back to hardware development, when we interact with the target audience and seek feedback on our device's functionality, we provide a more adapted version of our product (it has the primary function and it works), but it's still a rough model.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54d923634296f944c4c8_667bf4bca5445918d23d0441_2.jpeg)
It's also important to remember that this approach is used in both hardware and software, adding another layer of confusion. In software development, contractors face fewer iterations because the product isn't physically tangible. In simple terms, it's easier to make adjustments. When we talk about a hardware product, it's often impossible to make unnoticed changes to an existing sub-version, necessitating the creation of a new, refined sub-version. This characteristic of hardware development leads to having several prototypes within one version, such as an MVP.
That being said, the answer is "yes." PoC and MVP are prototypes. Then the question arises, can we distinguish "prototype" as an independent entity? We can. At least, classical classification offers such a product version and highlights the differences between PoC, Prototype, and MVP. We'll explain each in more detail further on.
What is the meaning of Proof-of-Concept in Hardware Development?
Proof-of-Concept (PoC) is a tangible demonstration that your idea or concept is technically feasible. PoC appears at the earliest stage of development. To save resources and focus on the main goal, simple, accessible, and often temporary components and materials are used for hypothesis testing. For example, microcomputers like Arduino or Raspberry Pi for control; gears made from 3D printers or Lego sets; cardboard or 3D printed enclosures, without considering design and ergonomics; breadboards for connecting components or hand soldering; simple battery packs or power adapters.
Let's look at examples of situations where you would need a proof-of-concept:
Demonstrating Technical Feasibility
No matter how impressive your concept is, "trust but verify." PoC helps reduce anxiety related to launching a new product, as at this stage, you have a primary mechanism made from the cheapest materials. Thus, questions related to further steps disappear.
Illustration: A team plans to develop a smart pet feeder that automatically dispenses food portions according to the schedule and user instructions.
Working Principle:
- The feeder's mobile app transmits data about the need to dispense a food portion to the microcontroller.
- Stepper motors drive the dosing mechanism to dispense the portions set in the app.
- After dispensing the necessary portion, the dosing mechanism goes into storage mode to prevent accidental food release and protect the hopper from the pet.
- Ultrasonic or infrared sensors measure the food level in the container.
- If the food level is below the set threshold, the microcontroller sends a notification to the user via the mobile app.
To bring the concept to life, engineers need to validate the main mechanism, specifically the dispensing of a certain amount of food. For validation, this mechanism needs to be created in the physical world, which is what PoC is. As we know, components can be "improvised."
The team decided to implement this mechanism using NEMA 17 stepper motors, plastic gears, and levers to assemble the mechanism. They used the ESP32 controller to execute commands from the mobile app and transmit operation status and food level in the hopper. For the feeder to function correctly, they used HC-SR04 ultrasonic food level sensors.
The PoC version does not require additional consumer-oriented features. In the case of the feeder, such a "bonus" could be an automatic feeding schedule that allows the owner to set specific times or intervals for automatic feeding without manually triggering the mechanism via the app each time.
Attracting Investments
Your request for investment will be much more successful if you have a reduced version of your device on hand: everything can be seen firsthand without resorting to abstractions.
Even if you've prepared a detailed product development plan, including sensor integration for food level detection, improving the mobile app, and developing the final enclosure design, market analysis confirming high demand for smart pet devices, and a business model including pricing, marketing strategy, and sales channels, without a PoC, this set will look like a "collection of fairy tales."
Once the basic version of the feeder is ready, you can demonstrate its operation to potential investors, showing how the device dispenses food on command from the mobile app. This will set you apart from "theorist" teams by showing that you've invested in the product's development intellectually and practically. Additionally, PoC will allow you to answer investors' questions, engage them in idea generation, and thus increase the chances of securing investment.
Breaking down the Prototype
We have validated the concept for technical feasibility, and it is feasible. However, this is still not enough to consider the product finished and ready for mass production. It's time to implement all the product's features, detail the design, test the "concept" in real-world conditions, and show it to focus groups.
At this stage, the team will use more reliable and efficient components: advanced microcontrollers (e.g., ESP8266/ESP32 with integrated Wi-Fi module), high-quality motors and drive mechanisms, often made of metal or structural plastic, printed circuit boards (PCBs) of the required sizes, power supplies optimized for your product, rechargeable batteries, and charge management systems. Unlike PoC, device prototypes usually have an enclosure, but not necessarily finalized.
Let's consider the contexts where you would need a prototype of a smart pet feeder:
Testing Functionality and Component Interaction
You've confirmed that the technologies to realize your idea exist. Now you need to move a level higher and ensure the seamless interaction of all components of the future device so that the user feels comfortable using it.
Returning to the example of the smart feeder, at this stage, the team will create drawings and 3D models of all components, assemble the mechanism using the chosen base, integrate the food level sensors and connect them to the microcontroller, develop software to control the feeder via the mobile app, and set up the notification system for low food levels. Each of these points has its nuances. For instance, it's necessary to ensure that when the low food level sensor triggers, the controller promptly sends a notification to the user via the mobile app, and the low level is set so that there's one or two portions of food left in the feeder. This gives the user time to refill the hopper. The timing of the notification is crucial, as one of the additional consumer-oriented features is the ability to set a scheduled feeding plan. If this function fails, the smart feeder loses its advantage.
Collecting User Feedback
Late-stage Prototypes (TRL-6 and TRL-7) can be used for initial contact with the target audience. You can show potential users the device's functionality and technical characteristics, demonstrating it in action. Potential users, in turn, will share their thoughts, provide feedback during trials, and suggest improvements. You can also observe them, which sometimes is even more important than feedback from focus groups. This way, you'll get answers to the question, "How do users like my device?" and identify early adopters before the product hits the market.
Preparing for Mass Production
Developing a prototype includes testing assembly and production methods for parts. This, in turn, helps prepare the device for mass production by thinking through step by step which technologies are best for manufacturing and which are not, as well as the most advantageous component layout.
For example, the feeder's enclosure is 3D printed, and components are inserted manually. It turns out that certain parts of the enclosure are too fragile, leading to breakages during assembly. In the future, injection molding will be used to produce a more durable enclosure.
Decomposing the MVP
MVP (Minimum Viable Product) represents a late version of a product which is ready for real user interaction: it has been refined based on feedback from focus groups. The materials and components used are those that will be in the final product: molded plastic, serial motors, precise infrared or ultrasonic sensors, rechargeable batteries, or constant network connection.
It's essential to remember that the primary goal of an MVP is a thorough analysis of the user experience. While prototypes aim to verify how all parts of the device work together, an MVP for demonstrating to the target audience includes only the most necessary for the user functions. The MVP is a test of the product's viability from a business model perspective. However, the device at this stage is ready for use. An MVP product should be stable and convenient enough for real use by the target audience.
Market Demand Testing and Minimizing Financial Risks Before Mass Production
By analyzing sales and feedback, you can determine if there is potential to scale the product. If the MVP receives positive feedback and good sales, it confirms that the product is in demand on the market and its release will not be associated with high financial risks.
After receiving feedback from the target audience of the smart pet feeder at the Prototype stage, the team refined the enclosure (the new one was made by injection molding), added an uninterruptible power supply with lithium-ion batteries to ensure pets are not left without food in case of power outages, replaced the HC-SR04 ultrasonic sensor with the VL53L0X laser infrared sensor to increase the accuracy of determining the remaining feed volume in the hopper, improved the app for managing the feeder by adding an extended feeding scheduler and enhanced the notification mechanism for low feed levels.
Next, the team launches a crowdfunding campaign on Kickstarter, which they believe will help test the market and attract investments. They release a limited batch of the product and test it in several pet stores and online platforms in the city or region, conducting research with pet owners.
Next, the team launches a crowdfunding campaign on Kickstarter, which they believe will help test the market and attract investments. They release a limited batch of the product and test it in several pet stores and online platforms in the city or region, conducting research with pet owners.
Our Projects
In the EnCata portfolio, there are many projects for which we have created POC/Prototype/MVP. In this article, we would like to talk about a smart rodent detector and the LeanKey warehouse robot.
Smart Rodent Detector
A startup company had an idea to create a device for counting rodents. The customer came to EnCata with a technology variant for such a device. The essence was to use an ultrasonic sensor to detect rodents. We tested this method and realized it didn't work as the customer wanted. This technology did not perform the main function of the device due to insufficient accuracy.
EnCata proposed a different solution – using sensors that, in theory, would detect rodents by their movement with 100% probability. Moreover, this method could be more energy-efficient and less costly. Additionally, using such a sensor would allow increasing the detection area inside the trap by placing it across the bottom.
Our "theoretical" confidence was not enough, so we developed a PoC for a smart rodent detector. We created a board with a sensor and a cardboard box where we placed a hamster. The sensor, placed at the bottom of the box, detected the rodent and sent a signal to close the circuit.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54da23634296f944c4ed_618cd9a29d2ece5236735d7d_%25D0%25B3%25D0%25B8%25D1%2584%25D0%25BA%25D0%25B0%25201.gif)
Our solution was successful, prompting a move to the next stage of product development. We did not spend efforts on designing and manufacturing the body, developing a mobile app, and hardware for data transmission. When demonstrating to the customer, it was enough to say: “See how the diode lights up. In the final version, a notification will be sent to the smartphone instead.”
Once we determined that the concept was technically feasible, we moved on to creating a prototype of the device.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54d923634296f944c4ce_667bf4ce0652fcd48eb52961_3D%2520model%2520of%2520a%2520smart%2520rodent%2520detector.jpeg)
The team developed a scheme to efficiently transmit data to the customer’s server. The scheme was based on NB-IoT technology. The PCB was placed in the upper part of the device, ensuring energy-saving mode when operating in the mobile network. We worked on the device layout and adapted the electronic part to the device dimensions. We also developed a system to protect the electronics inside the detector from potential rodent damage.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54d923634296f944c4d1_667bf4f1c4f6558a8cf5bb75_Prototype%2520rotend%2520detector.jpeg)
As a result, we created a prototype to test engineering solutions and components, and demonstrated it to the customer. In the Prototype version, the team used modern components that are close to those that will be used in the final device.
MVP LeanKey
Our portfolio includes an example of an internal project currently at the MVP stage – the LeanKey warehouse robot. LeanKey is a mechatronic device in the form of a mobile robotic platform. The product operates autonomously and can be integrated into external IT systems.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54d923634296f944c4e4_667bf19f7eb65b6dfaf749cb_LeanKey.jpeg)
The Prototype version helped us test the interaction of all units and components in conditions close to real ones, improve the design for greater load capacity (increased to 200 kg), and develop software that allows the robot to make independent decisions for moving the cart depending on the situation: when it is ready to be moved to the next section in the shop floor, along which trajectory to move, how to recognize obstacles and avoid collisions.
![](https://cdn.prod.website-files.com/5df74601f137553ef4caed09/66bb54da23634296f944c4f1_667bf1b02e5a2d4db079a2a7_Leankey%2520inside.jpeg)
For the MVP, we used the following components:
- Movement system: Standard motor wheels, ensuring stable and reliable movement.
- Sensor system: Lidar for basic navigation, IMU for determining position and movement, ultrasonic sensors for collision prevention.
- Camera: Digital camera for tracking floor markers, helping to navigate the space.
The LeanKey MVP is a device with basic but essential functionality that can already be used in warehouses or production for process automation: it can move along user-set points based on data from a built map of the premises, determine the optimal path, and adjust the route during the process. Therefore, our team is already working on identifying and forming market demand.
In closing
The development of hardware products is generally associated with several key product versions, each with its own goals and requirements.
The goal of a PoC is to check the technical feasibility of the concept. At this stage, a minimally viable version of the product is created, demonstrating the basic working principles. PoC helps determine whether the proposed idea can be realized in practice, identifies key technical risks, and provides a foundation for further improvements. PoC components are often simple and may be temporary or makeshift.
A prototype represents a more advanced version of the product, where all key units and components are tested in conditions close to real ones. With Prototype versions, structural solutions are worked out, the design is improved, and the functionality of the device is increased. The prototype allows for more detailed testing, receiving feedback from focus groups, and making necessary adjustments before mass production. Prototype components are more durable and accurate than those in the PoC but may still differ from the final product version.
MVP is a minimally viable product that includes all the main functions and is ready for use in the real market. At this stage, the product already has an industrial design, stable and tested components, and can be integrated into existing user systems. MVP allows testing the product in real conditions, collecting user feedback, assessing market demand, and making final adjustments before launching mass production.
Each version – PoC, Prototype, and MVP – plays its unique role in the hardware product development process. Understanding these differences and correctly applying each stage will help you approach product development methodically and predict its outcomes in advance.