Key takeaways
- A connected product runs through every stage of a standard hardware build, then adds five more: connectivity, cloud backend, a companion app, device provisioning, and over-the-air updates.
- Choosing a connectivity protocol is a tradeoff between range, power, data rate, and cost. No single protocol wins on all four at once.
- Device provisioning and OTA update infrastructure are easy to leave until late in a project, but they are architecture decisions that shape the firmware from the start, not features to bolt on before launch.
- Security has to span the device, the app, and the cloud backend together. A product can get the device hardened and still ship an insecure companion app.
The IoT product development process runs through the same hardware stages as any physical product, feasibility, electronics, firmware, enclosure, prototype validation, and certification, then adds the work specific to a connected device: choosing a connectivity protocol, building a cloud backend, developing a companion app, provisioning devices with a secure identity, and standing up an infrastructure for firmware updates after the product ships. The connectivity choice made early shapes every one of those additions, so it belongs in the plan from the start rather than as a decision made once the hardware is already designed. See how to develop an IoT device for those decisions.
Where this sits inside the broader hardware life cycle
The general sequence, technical feasibility, requirements, schematics and PCB layout, firmware, enclosure, prototype validation, certification, and the production handoff, is covered stage by stage in the hardware development life cycle. A connected product follows that same sequence for its physical build. What follows here is specific to the parts a sensor-only or standalone product does not need.
| Stage | What it adds for a connected product |
|---|---|
| 1. Feasibility and concept | Connectivity requirement, total cost of ownership, app and cloud scope |
| 2. Device engineering | Hardware and firmware, covered in the general life cycle |
| 3. Connectivity protocol | Range, power, data rate, and cost tradeoffs |
| 4. Cloud backend | Messaging, device state, and data pipeline |
| 5. Companion app | Pairing, control, and account management |
| 6. Device provisioning | Secure identity assigned at manufacturing |
| 7. OTA updates | Infrastructure for firmware updates after launch |
| 8. Security across the stack | Device, app, and cloud treated as one attack surface |
| 9. Certification | Radio, safety, and security requirements for the target market |
Stage 1: Feasibility and concept, with connectivity added
A standard feasibility study asks whether the physics, the certification path, and the target price can coexist. For a connected product, three more questions belong in that same study before engineering begins: what the product actually needs connectivity to do, what it will cost to run the cloud and app side after launch, and whether the core function still works acceptably if the connection drops. A product that only needs connectivity for a notification is a different, cheaper build than one whose core function depends on a live connection.
Stage 2: Device engineering
The hardware and firmware architecture, choosing the microcontroller or system-on-chip, its peripherals, power strategy, and whether firmware runs on a real-time operating system or bare metal, is covered in embedded system design, including how a team decides between a pre-certified module and a custom board for the radio itself. That decision carries into certification and connectivity, covered next.
Stage 3: Choosing a connectivity protocol
No single protocol wins on range, power, data rate, and cost at once, which is why this choice is a tradeoff exercise rather than a default pick.
| Protocol | Typical strength | Typical tradeoff |
|---|---|---|
| Bluetooth Low Energy | Low power, simple phone pairing | Short range, typically well under 300 meters outdoors and far less to a phone |
| Wi-Fi (including HaLow) | High data rate (standard Wi-Fi); HaLow adds roughly a kilometer of range at low power | Higher power draw on standard Wi-Fi; HaLow trades throughput for that range |
| Zigbee / Thread | Low power mesh networking, multi-year battery life | Low data rate, needs a hub or border router |
| LoRaWAN | Long range at very low power | Very low data rate, suited to small periodic messages |
| Cellular (LTE-M, NB-IoT, 5G RedCap) | Works anywhere with carrier coverage, no local gateway needed | Highest per-device running cost; RedCap targets higher data rates than LTE-M or NB-IoT, generally at higher power draw |
Matter, the smart-home interoperability standard built on top of Wi-Fi, Thread, and Bluetooth, continues to expand: its latest revision, released in November 2025, added native camera support and expanded energy-management device types. It is now supported by several major smart-home platforms, though it is still a layer on top of one of the underlying radios above, not a replacement for choosing one. Inventornest’s experience with the underlying hardware decision generalizes directly here: “custom RF work becomes relevant when the required size, antenna arrangement, range, power consumption or production cost cannot be achieved with an available module,” though using a pre-certified module does not automatically remove all testing obligations for the finished product. A pre-certified module remains the starting point until a specific requirement rules it out.
Stage 4: Cloud backend and the device data pipeline
Most connected products talk to the cloud using MQTT, a lightweight publish-subscribe messaging protocol built for constrained devices and formalized as an OASIS standard. On the backend, a common pattern is a device “shadow” or equivalent state document: a record of the device’s last-reported state and any pending desired state, so an app can request a change while the device is offline and the device applies it once it reconnects. The pipeline behind that typically has three stages: ingesting messages as they arrive, processing or filtering them, and storing the result for the app and any analytics to use.
Stage 5: Companion app and device pairing
The companion app is usually scoped and quoted as a separate software project from the hardware, covering pairing, day-to-day control, and account management. It is also a documented source of risk: the Open Worldwide Application Security Project’s mobile risk guidance flags weak or hardcoded credentials and insecure interfaces between a device’s app, cloud, and backend as recurring, serious issues, which makes the app’s security review part of the connected product’s scope, not a separate concern handled later by someone else.
Stage 6: Device provisioning and secure identity
Provisioning is how a device gets a trustworthy identity before it ever reaches a customer, and it is an architecture decision, not a manufacturing-line afterthought. Cloud platforms support zero-touch provisioning, where a device presents a certificate signed by a registered authority and the platform automatically creates its record and assigns permissions, removing manual registration at scale. Standards-based approaches extend the same idea: the GSMA’s IoT SAFE specification uses the SIM itself as a hardware root of trust for cellular-connected devices, and Matter’s commissioning flow, built around a QR code, a secure Bluetooth session, and a device certificate check against a shared compliance ledger, is a fully specified version of the same problem for the smart-home ecosystem.
- Decide whether the device gets its identity at the factory or at first use.
- Confirm the chosen cloud or standards framework before firmware for this is written.
- Plan for revoking or rotating a compromised device’s credentials, not just issuing them.
Stage 7: Over-the-air update infrastructure
An OTA system needs a way to package and sign firmware, a transport to deliver it, and a safe recovery path if an update fails. Major cloud IoT platforms support resilient update schemes, commonly dual-partition designs that let a device roll back automatically to its previous working firmware if a new image fails to boot or pass its own checks. Code signing is standard practice: the update image is signed with a certificate before distribution, and the device verifies that signature before applying it. A standardized manifest format for describing these updates, the IETF’s SUIT specification, was still working through the standards process as a draft at the time of writing, which is worth knowing if a design is being built around it today: the mechanics are mature even where the exact standard is not finalized.
Stage 8: Security across the device, app, and cloud
A connected product’s attack surface spans all three layers at once, and a weakness in any one undermines the others. A hardened device behind an insecure app, or a well-built app talking to a cloud backend with no rate limiting or weak authentication, both fail the same way: a determined attacker finds the weakest layer, not the strongest. The established guidance here, covering device, interface, and ecosystem risks, is widely used as a baseline checklist, though it has not had a major revision since 2018 and should be read as a starting point rather than a complete current threat model. Security and compliance obligations in major markets, including device password and disclosure requirements in the UK and emerging EU cybersecurity rules for connected products, are covered with current dates in how much it costs to develop a hardware product.
Stage 9: Certification for a connected device
A connected device needs the same radio and safety certification any transmitting product needs, covered stage by stage in the hardware development life cycle, plus whatever security or disclosure rules apply in its target markets. A device that transmits intentionally, such as over Wi-Fi or Bluetooth, needs testing at an FCC-recognized test lab before it can be sold in the US. Certification planning belongs in the architecture stage, not after the board is finalized, since the choice between a pre-certified module and a custom radio changes the certification bill more than almost any other single decision.
Frequently asked questions
What are the main stages of IoT product development?
Feasibility and concept, device hardware and firmware, connectivity protocol selection, cloud backend, companion app, device provisioning, over-the-air update infrastructure, security review, and certification.
How is IoT product development different from general hardware development?
It follows the same core hardware stages, then adds connectivity, a cloud backend, a companion app, device provisioning, and an OTA update system, none of which a standalone, non-connected product needs.
Which connectivity protocol should I choose for my IoT product?
It depends on the tradeoff that matters most for the product: Bluetooth Low Energy for short-range, low-power links to a phone; Wi-Fi for high data rate at higher power; Zigbee or Thread for low-power mesh networks; LoRaWAN for long range at very low data rate; and cellular when the device needs to work anywhere without a local gateway.
Do I need a companion app for a connected product?
Most connected products do, for pairing and day-to-day control, and it is typically scoped and priced as a separate software project from the hardware. Its security needs the same attention as the device itself.
Why does device provisioning matter if the product already has a login system?
A login system authenticates a user. Provisioning establishes that the physical device itself is genuine and trustworthy before it ever reaches a customer, which is a separate problem that has to be designed into the firmware and manufacturing process from the start.
What happens if I skip planning for OTA updates?
A product shipped without an update path cannot fix a firmware bug or a security issue after it reaches customers, which is a serious liability for anything that connects to a network. Planning for it from the start is far cheaper than retrofitting it onto firmware already in the field.
Where Inventornest fits
Inventornest’s IoT product design services cover the connectivity, cloud, and device-engineering decisions above as one coordinated build rather than separate handoffs between teams. Their engineering team begins with the same feasibility step applied to any hardware product, then works through which connectivity protocol, provisioning approach, and update infrastructure actually fit the product’s constraints.
Their portfolio includes connected products built across several of the protocols and architectures above. If you are scoping a connected product and want to work through where it sits on this process, the next step is to book a consultation. For expert help with one layer or stage of the build, see our electronics and IoT design consultancy.
