Product
Your IoT prototype is not a product. Here are the six things that make it one.
A working demo on a development board is a start, not a finish line. These are the gaps we close between a prototype and something you can ship and support for years.
The prototype is the fun part. A board on a bench, a sensor reading appearing on a dashboard, a stakeholder nodding. Then someone asks when it can ship to a thousand customers, and the honest answer is that most of the work has not started. Below are the six capabilities that separate a demo from a product, in the order we usually tackle them.
1. Provisioning and identity
A prototype has credentials typed in by an engineer. A product needs every device to have its own identity, issued at manufacturing or first boot, without a human in the loop. That means a certificate strategy, a registration flow and a way to revoke a compromised unit. If you cannot answer 'how does device number 4,000 get its credentials?' you do not have a product yet.
2. Over-the-air updates
You will ship bugs. The only question is whether fixing them costs a firmware image or a site visit. OTA is not a feature for later; it shapes the partition layout, the bootloader and the storage budget from day one. Retrofitting it is one of the most expensive mistakes in connected hardware.
3. Behaviour when the network is gone
Demos happen on office Wi-Fi. Products live in basements, on trucks and behind corporate firewalls. Decide what the device does with no connectivity: buffer, degrade, alert locally? How much data can it hold, and what happens when the buffer is full? These decisions define the hardware you need and the user experience you can promise.
4. Observability for the fleet, not the device
One device on a bench is easy to debug. Five thousand in the field are not. You need fleet-level dashboards (check-in rates, firmware versions, error distributions) and the ability to pull logs from a specific unit without asking the customer to do anything. Design the telemetry for the support engineer, not just for the end user.
5. Security you can explain
Secure boot, signed firmware, encrypted transport, least-privilege cloud permissions, a process for rotating keys. None of this is exotic, but all of it has to be designed in. Increasingly, customers and regulators will ask you to document it: the EU Cyber Resilience Act and similar regimes make 'we'll add security later' a commercial risk, not just a technical one.
6. A support model
Who gets paged when the fleet check-in rate drops at 2am? Who ships the firmware fix, and how is it tested? What does the customer see while it is happening? A product is a service commitment with hardware attached. Write the runbook before launch, staff the on-call rotation, and price the support into the product.
A prototype proves the idea works. A product proves you can keep it working, for every unit, for years, without heroics.
Sequencing the work
We usually take a prototype through a short architecture phase that answers all six questions on paper, then build provisioning and OTA first, because everything else depends on being able to update the device safely. Offline behaviour and observability follow, with security threaded through each. The support model is designed alongside, not afterwards. Done this way, the path from bench to fleet is measured in months, not years, and it does not require a rewrite halfway.