Connected Product Development: Stack, Costs and How to Build One

An IoT product is five products stacked on top of each other. Hardware, firmware, connectivity, cloud and application each have their own tooling, their own failure modes and their own recurring cost. Teams that treat IoT development as "a device with Wi-Fi" discover the other four layers late, when they are most expensive to fix.

Connectivity is the decision that constrains battery life, bill of materials, certification scope and the recurring cost per device. Choose it before the enclosure, not after.

A realistic first connected product runs nine to fifteen months: two months of architecture and connectivity selection, four to six months of parallel hardware and firmware development through EVT and DVT, two months of certification and pilot production, and continuous cloud work throughout. See our electronic design services and end-to-end development for how these run together.

IoT development is the combined design of hardware, embedded firmware, connectivity, cloud backend and user application required to make a physical product report data and be controlled remotely.

A first connected product typically costs $150,000 to $500,000 across hardware, firmware, cloud, app and certification, plus $0.30 to $5.00 per device per month in ongoing connectivity and cloud cost.

Nine to fifteen months from architecture to pilot production for a first product, with hardware and firmware running in parallel and certification adding six to twelve weeks near the end.

Use BLE when a phone is always nearby, Wi-Fi when the device is mains powered, LTE-M or NB-IoT when devices roam beyond any gateway, and LoRaWAN for large sensor fleets on a single site.

Connected product development is dominated by decisions that have nothing to do with the idea itself. Two teams building the same sensor can end up with a five-fold cost difference and a two-year schedule gap purely from choices about connectivity, power, security and update architecture. Those four decisions should be made deliberately in the first month, because every one of them is expensive to reverse after the enclosure and the certification are done.

The trap is picking cellular for convenience. It removes the gateway problem and adds a permanent per-device bill, a certification burden with the carrier, and an antenna design constraint that will drive at least one enclosure revision. Choose it when the deployment truly has no local infrastructure — not because it is simpler to prototype.

Battery life is set in a spreadsheet, not in firmware optimisation later. Build the budget from measured currents on a development board, apply the duty cycle you actually intend to ship, and add margin for cold temperature capacity loss.

At 115 uA average, a 2,400 mAh primary cell gives roughly 2.4 years nominal, which becomes about 18 months once you derate for self-discharge and cold. If the requirement is a five-year life, the answer is a lower reporting cadence or a different radio — not a firmware sprint at the end of the programme.

A connected product without a reliable update path is a recall waiting to happen. Design the update mechanism in the first firmware sprint, not the last, and prove a failed-update recovery on real hardware before tooling.

Recurring cost per device decides whether a connected business model works. Model it early at your projected fleet size, because the per-device figure looks trivial at 100 units and defines your margin at 100,000.

Radio certification is schedule-critical and sequence-dependent. Pre-certified modules remove most of the burden but not all of it: the host product still needs unintentional-radiator testing, and any antenna change invalidates the module's certification.