IoT Hardware Development: Stages, Costs and Timelines

An IoT product is four products in one — an enclosure, an electronics assembly, embedded firmware and a cloud service — and each has its own schedule, test cycle and failure modes. Teams that budget for the board alone are usually the ones that discover, nine months in, that connectivity provisioning and certification were never funded. The stage map below is what a realistic connected-device program looks like when it is planned properly.

Slips almost never come from the schematic. They come from certification bookings made too late, antenna performance discovered after the enclosure is tooled, provisioning flows nobody owned, and pilot units that fail at the contract manufacturer because no functional test fixture was designed. Each of those is a planning item, which is why we set them as gates rather than as tasks at the end of the plan.

Related reading: electronic product development and electronic design workflow.

The reason IoT programs slip is rarely a single hard problem. It is coupling.

The mechanical team needs the board outline frozen to finish the enclosure, the RF engineer needs the enclosure geometry to predict antenna detuning, the firmware team needs stable hardware to close timing on the radio stack, and the cloud team needs a provisioning identity that only exists once the factory test plan is written.

Each dependency is reasonable on its own; together they form a loop that a serial schedule cannot resolve.

The way out is to break the loop deliberately. Freeze the board outline and connector positions early and treat them as a contract, even if component placement inside that outline keeps moving.

Build an antenna evaluation unit in the real enclosure material before the tool is cut, because plastic thickness, metal trim and even a decorative coating can cost you several dB.

Give firmware a stable bring-up board that is intentionally one revision behind the cosmetic hardware, so driver work continues while mechanical iterates. Define the device identity scheme in the first month, since it determines how the factory provisions units and how the cloud authenticates them.

Programs that do this run roughly parallel and land in nine to twelve months. Programs that discover the coupling late run serially, and each discovery costs a full board or tool iteration measured in weeks, not days.

Development cost is the visible number; the recurring cost is what decides whether the product has a business behind it. A connected device carries cellular or gateway data charges, cloud compute and storage, certificate lifecycle management, an OTA delivery path, and support staff who can read device telemetry.

At a thousand units these look trivial. At a hundred thousand units, a few cents per device per month is a line item that outweighs the entire engineering budget within two years.

Model it before you commit to an architecture. A device that reports once an hour over LTE-M with a small payload might cost $0.30 to $1.00 per month in connectivity, plus perhaps $0.05 to $0.25 in cloud cost if the data pipeline is designed with retention limits.

A device that streams continuously over Wi-Fi shifts the cost to cloud ingestion and storage instead. Either can be fine; what is not fine is discovering the number after the hardware is tooled, because the fix is almost always a hardware change.

Two design choices dominate the recurring bill: how much you process on the device versus in the cloud, and how long you retain raw data. Edge filtering that sends events instead of raw samples can cut ongoing cost by an order of magnitude, at the price of more firmware complexity and a harder debugging story.

Decide that trade-off consciously during architecture, and write the target cost per device per year into the requirements document alongside the BOM target.

If you are scoping a connected product now, our IoT and consumer product development team handles hardware, firmware and cloud under one schedule, our electronic design services cover schematic through certified board bring-up, and low volume manufacturing gets the first few thousand units built with real test coverage.

Radio certification is a fixed-cost, fixed-duration event that behaves like a wall, and it is almost never on the first draft of an IoT schedule.

In the United States a device with an intentional radiator needs FCC testing. In Europe it needs CE under the Radio Equipment Directive. Carriers add their own approval program if you use cellular, and PTCRB or equivalent testing can take longer than the FCC work.

Booking a lab is not instant either, and slots in busy quarters run three to six weeks out.

Pre-certified modules remove most of this. If you use a module that already carries a modular grant, you inherit the radio approval and typically need only unintentional radiator testing plus a permissive change filing, which can cut both weeks and tens of thousands of dollars. The trade is unit cost, board area and a small loss of design freedom, which is usually worth it below fifty thousand units a year.

Whatever route you take, run a pre-scan at an accredited lab before the formal test, using production-intent enclosures and cables. Pre-scan failures are cheap to fix; formal test failures cost the retest fee, a board or shielding change, and another lab slot. Budget for one retest as the expected case rather than the exception, and hold the enclosure tool until the antenna has passed in the real housing.

A single connected device from concept through pilot production typically runs $70,000 to $190,000 in engineering, plus tooling. Simple sensors with a pre-certified module sit at the low end; multi-radio, battery-powered or regulated products sit above it.

Nine to eighteen months from requirements to pilot units is normal. Roughly five to eight months is engineering, and the rest is certification, tooling and the two design iterations most programs need after real-world testing.

In the United States, FCC Part 15 for unintentional radiators plus intentional-radiator testing for the radio; in Europe, CE under the Radio Equipment Directive. Battery products add UN 38.3 for shipping, and safety marks such as UL or ETL apply depending on the market and power source.

Connectivity is not a feature you add to a board; it sets the power budget, the enclosure geometry, the certification bill and the recurring cost per device for the product’s entire life. Changing it after layout means a new antenna keep-out, a new RF test campaign and often a new battery. Lock it in feasibility.

Run a written power budget before committing. Take the sleep current, the active current, the transmit duration and the reporting interval, and compute expected battery life at the worst-case temperature. Teams that skip this step discover the two-year battery claim is a four-month reality after tooling is cut.

A connected device without a reliable over-the-air update path is a recall waiting for a reason. Budget for dual-bank flash so an interrupted update falls back to the previous image, signed images so only your firmware runs, and a staged rollout that pushes to one percent of the fleet before the rest. The flash cost is measured in cents; the alternative is a field service visit measured in tens of dollars per unit.

Work with LA NPDT: if you are moving from here to execution, start with our design optimization or talk to us about low-volume manufacturing.