How to build (beyond) an IoT PoC: A conversation with an IoT expert

According to Bain & Company's IoT Customer Survey, 80% of businesses abandon about 60% of their IoT projects at the Proof of Concept (PoC) stage [1]. As the survey shows, a flawed IoT PoC is among the top five reasons these industrial-sector initiatives stall before scaling. And not because the technology fails, but because it's not aligned with real-world operational conditions or business objectives.

A Proof of Concept for the Internet of Things project may yield unreliable results due to incorrect PoC approach, too many hypotheses, incorrect initial calculations, and so on. The good news is that these factors are avoidable with IoT experts by your side.

In a conversation with Mykhaylo Kohut, an Embedded Solutions Architect and IoT expert at N-iX, we discussed what IoT adopters should know to build a scalable PoC. If you're a business or technology leader wanting to validate IoT initiatives and set realistic expectations, this interview is for you. But first, let's review the essentials we need to know about the Proof of Concept for IoT.

What is a Proof of Concept in an IoT project?

An IoT Proof of Concept is a focused validation exercise that tests whether a specific business issue can be addressed using an IoT solution. At the PoC stage of IoT development, companies can validate (or reject) hypotheses related to tasks at any level of the IoT architecture.

A few common examples of Proof of Concept in IoT (layer by layer)

Device layer

• Will our device work from battery power for five years without needing a recharge?
• Can the sensor capture accurate data under varying environmental conditions (temperature, humidity, vibration)?
• Does the device maintain stable connectivity in different locations or under low signal conditions?

Gateway layer

• Can our gateway handle multiple devices simultaneously without dropping connections?
• Is the gateway able to process and filter data locally to reduce latency before sending it to the cloud?
• Can the gateway work with multiple communication standards (e.g., Wi-Fi, Bluetooth, Zigbee)?

Cloud layer

• Is the cloud infrastructure able to scale seamlessly to handle increasing amounts of data from thousands of devices?
• Does the cloud platform support real-time data processing and analytics without delays?
• How well does the cloud platform manage high availability and fault tolerance in case of outages?

Data layer

• Can we ensure the accuracy and consistency of data as it is processed and aggregated from multiple sources?
• How does the system handle incomplete or corrupted sensor data?
• Does the data pipeline support real-time streaming and batch processing for different types of analytics?

UI layer

• Does the UI adapt across different devices (mobile, desktop, tablet) without compromising usability?
• Can the user interface handle complex data visualizations (e.g., graphs, heatmaps, and real-time alerts)?
• Is the UI able to integrate with multiple data sources and present them in an easily digestible format for the end user?

A well-designed IoT concept validation focuses on learning rather than completeness and deliberately limits scope to reduce risk. Common examples across the industries include:

• Monitoring machine vibration and temperature to validate predictive maintenance;
• Tracking asset location and status to improve logistics visibility;
• Collecting energy consumption data to assess optimization potential;
• Testing environmental sensors to support safety or regulatory compliance scenarios.

Key requirements for IoT PoC project

Since Proof of Concept in IoT development validates ideas, its requirements are minimal. An effective concept validation has several important components:

• The idea to be validated;
• Clear tasks that need to be tested;
• Documentation that tracks results.

Usually, the PoC for IoT projects focuses on 1-2 small tasks. If there are more than two tasks, they can be grouped into several PoCs. This focus on a limited number of tasks is necessary to keep execution time short and test the idea's viability.

The end result of IoT PoC is the answer to the "Can it be done?" question. If the answer is "Yes", the team can move to minimum viable product (MVP) development for the IoT project. If the answer is "No", the business can either stop pursuing this idea or ask for another PoC, using the previous findings.

More on topic: AI PoC: Validate AI solutions efficiently

Expert tips to help you build an effective Proof of Concept for an IoT solution

KS: How would you describe an IoT PoC in terms of its importance or priority for an IoT project?

MK: I'd say it's a small price for a bigger win if a business decides to start with it. Or a small discount for a bigger loss if it doesn't. The purpose of PoC in IoT development is to validate whether a specific business problem can be addressed with an IoT solution. But there's no guarantee that it can. So we test whether it makes sense to invest in the solution at all. My personal take is that PoC for any IoT solution is the most important step because it either shows a path or redirects.

KS: What should businesses define before starting an IoT PoC?

MK: Before any development begins, you need a clearly framed use case, measurable evaluation criteria, and defined constraints. That includes what decisions the findings should support, which assets or processes are involved, expected data frequency, acceptable latency, etc.-it all depends on the hypothesis you test. Businesses should also keep in mind that IoT PoCs aren't always validated, and that, too, is a very valuable finding as it saves you from investing in a solution that didn't have a chance in the first place. What's happening during an IoT Proof of Concept stage is always an experiment that requires a readiness to accept that the idea may not work.

KS: As a part of the software development cycle, PoC should have a scope of tasks. How narrow or broad should it be for IoT projects?

MK: A PoC should be intentionally narrow, for IoT or not, but especially for IoT solution development. Going minimal is the best approach here, especially in terms of resources, time, and budget. Focus on one use case, one environment, and a limited number of devices. The goal is not showcase coverage, but learn whether the idea is viable at all. Expanding the scope too early increases complexity and can turn a Proof of Concept into a Minimum Viable Product project that requires way more resources.

KS: What are the most common mistakes companies make during the validation stage of an IoT project?

MK: The most frequent mistake is overengineering. Teams often design the PoC as if it were a final product, which slows delivery and inflates costs. Typically, an IoT concept validation takes 2-4 weeks for basic use cases, and that's the timeframe we at N-iX try to stick to. And this mistake stems from another: having too many things to validate within a single PoC.

KS: How important is hardware choice at the PoC stage?

MK: Hardware matters, but it should not dominate decision-making. For an IoT PoC, it's often better to use off-the-shelf devices or software development kits (SDKs) that approximate real conditions. This approach allows flexibility, reduces upfront investment, and makes it easier to pivot based on early findings without locking into specific hardware decisions. However, custom hardware makes sense in later development stages once requirements have been validated.

KS: What role does connectivity play in a successful IoT PoC?

MK: I'd say the choice of connectivity and network may even be a separate PoC within the IoT project. For example, we may need to test if a wireless network will work under the conditions and systems specified by the clients. If yes, we may offer wireless network options (e.g., WiFi, BLE, mesh, etc.), explain their advantages and disadvantages, and recommend the best option for the given conditions. We may also prepare a small demo on a few devices for a chosen option to show what it will look like. If wireless won't work, we will explain why not and may start verifying another idea to research the alternatives.

KS: You mentioned a few network providers. In general, what role do such tech companies play in the IoT validation stage? How do you choose which component to include?

MK: If the idea is validated and we can move on with our IoT PoC findings, it's our task as experts to choose the components whose characteristics will meet the requirements. There are plenty of different solutions on the market to choose from, and we here perform a "filtering" function as we select the most optimal solution based on different parameters. We also partner with tech companies whose solutions are proven to be reliable and whose support we can count on. These partnerships include AWS, Microsoft Azure, GCP, Wirepas, Nordic Semiconductor, Raspberry Pi, Arduino, MathWorks, and others.

KS: According to many reports, security in IoT is a major focus for businesses. Should security be part of a validation, or is it too early to include security considerations at this point?

MK: Whether to include IoT security as a PoC task depends on what PoC targets. It may even be a separate project, just like connectivity. But if you want to test if the data can be delivered from device A to network B, security isn't the task at this point. It will be considered later.

KS: How do you know when an IoT PoC is ready to move forward?

MK: A Proof of Concept for the Internet of Things has its goals and tasks. If the results it yielded correspond with the assigned tasks, then you're ready to move on. If the results didn't meet expectations, then the idea is invalid and you may need to run another PoC.

KS: What happens after concept validation?

MK: Usually, Proof of Concept for IoT is made of software development kits (SDKs), not on the real hardware, even though there are cases when this may apply. It may sound counterintuitive, but in later development stages, we don't reuse PoCs. Rather, we reuse findings and select components that make the idea work in real life, under real conditions.

KS: What should businesses prepare for after a validated IoT Proof of Concept?

MK: After validation, the next stage is requirements preparation for MVP development.

KS: How many people are usually needed for Proof of Concept for IoT prototyping?

MK: It depends. For example, if your PoC relates to the cloud layer, you'll need a back-end engineer and a DevOps engineer. If you want to validate an IoT solution with a computer vision (CV) component, then you'll need an IoT data visualization and CV specialist, and so on. The logic here is to keep a minimal team of specific experts to work on an IoT PoC project. This approach will allow companies to have the results quickly and be sure of their quality.

KS: How can external IoT experts add value at the PoC stage?

MK: Any company that can properly validate IoT ideas adds value to the project, as the client will understand whether they're worth pursuing. And the clients may stop cooperating with the tech vendor once the PoC results are ready and take it from there with either the in-house development team or another outsourcing company. However, you should be aware of a few issues.

Not every software outsourcing company has the resources to offer development after IoT PoC. If the validation is successful and you'd like to move forward, you'll need to find other tech partners, which will increase development costs and time. So it makes sense to partner with established IoT development companies like N-iX, which have plenty of great-to-have tech partnerships whose solutions or products are necessary for massive IoT solution deployment.

If you take PoC to another vendor for MVP development, it will take the team additional time to familiarize themselves with the concept and understand your case. For the project, it increases costs and the development timeframe. With companies offering full-cycle IoT solution development, those who worked on PoCs usually make up the core team for further development. Plus, they can find additional team members with the required skills faster.

Moreover, experienced IoT development teams help businesses avoid common mistakes and practices that don't work well in specific business domains. We at N-iX have developed IoT solutions for businesses in automotive, healthcare, logistics, fleet management, manufacturing, and other industries. It means we're aware of industry practices in IoT connectivity, data processing, AI integration, edge computing, and more. We bring proven architectures, realistic timelines, and a balanced view of technology and business constraints. This shortens the learning cycle and ensures the PoC produces insights that decision-makers can actually use.

More on topic: An expert's guide to outsourcing IoT development for growth

KS: What would be the best practices for Proof of Concept (PoC) development for IoT?

MK: I have several tips for approaching Proof of Concept (PoC) development for IoT.

1. Involve senior-level experts. It will help you properly estimate requirements and validate the idea quickly.
2. Collaborate with a Project Manager. You'll need a skilled Project Manager to ensure the project is completed within the set time.
3. Start the project when all hardware and resources are available. Especially if you have custom hardware, SDK, and other resources for the team to work with. It will ensure the precision of hypothesis testing and the validity of results.
4. Keep device count low. Limit the PoC devices to those critical to the use case, reducing complexity and enabling focused testing.
5. Use real data sources. Whenever possible, collect data from actual sensors or equipment rather than simulations to ensure results reflect real-world conditions.
6. Measure not just functionality but cost. Alongside technical performance, track the costs of data transmission, device management, and power consumption to evaluate long-term viability. For example, a part of the PoC task can be comparing paid and free connectivity options to determine whether you need to invest in it or can achieve the same result at no extra cost.
7. Document limitations. Identify potential weaknesses early, such as network limitations or power consumption challenges, and document them for later optimization.

KS: Is there such a thing as unsuccessful PoC in IoT?

MK: In my opinion, an unsuccessful PoC in IoT is when the result is compromised by the questions or tasks that are not clear. It jeopardizes the experiment from the get-go, and it's easy to receive false results.However, it's considered successful when it clearly answers the question it was supposed to. And sometimes it shows that the idea isn't viable. That's also a success because you haven't invested a fortune into something without a future.

KS: With your many years of practice in IoT and embedded domains, is there anything you still find fascinating and fresh about Proof of Concept for Internet of Things?

MK: Working on concept validation is always an experiment. The client doesn't know if it will work as they imagined. We don't know if it will work as they imagined. Otherwise, we'd go straight to the development stage. It's a playground for finding the best solution within the set timeframe, limitations, and conditions. It's always thinking within the box rather than outside, which I find more challenging and hence more creative.

KS: How can N-iX expertise help create a reliable PoC for IoT projects?

MK: At N-iX, we offer IoT PoC development services, helping businesses test their IoT ideas and turn them into actionable solutions. Beyond PoC, we provide full-cycle IoT development services, including IoT consulting, embedded and firmware development, connected device engineering, wearables devices and app development, ensuring your project moves seamlessly from proof of concept to scalable, real-world solutions.

From initial concept validation to full-scale implementation, we work closely with you to design the best approach, selecting the ideal tech stack and development methodology within the required timeframe.

Final thoughts

An IoT PoC is more than just a test; it's an important step in turning a concept into a scalable solution. Whether you're at the beginning of your IoT journey or looking to optimize your existing solutions, it's important to include it in your development plan.

While a successful PoC in an IoT project is the first step, it's just the beginning. Transitioning from a validated concept to a scalable deployment requires careful planning, system optimization, and continuous collaboration. With the right strategy and approach, you can avoid the common pitfalls and ensure your IoT project moves from concept to production seamlessly. And if you need expert help with your Proof of Concept for IoT prototyping, N-iX is here to make your IoT idea happen.

Sources:

1. To Scale the Industrial Internet of Things, Don't Forget Hardware | Bain & Company