The IoT product development process is the work of turning a measurement or control idea into a connected device that runs in the field for years, is managed remotely and can be built in volume. Its seven stages are feasibility, architecture, design (board, enclosure, firmware), prototyping and field testing, compliance and production readiness, series production, and commissioning and remote operation.
Key takeaways
- Each of the seven stages of IoT product development produces a concrete output; a skipped stage comes back as a field failure.
- The costliest mistakes come from carrying connectivity, power and environment decisions into series production without testing them on site.
- Over-the-air (OTA) updates and device authentication are planned at the design stage, not bolted on later.
- The main obligations of the EU Cyber Resilience Act apply from 11 December 2027; a device that cannot be updated will struggle to meet them.
- At Digital Bridge the board, enclosure, firmware and management dashboard are designed by one team, and the technical feasibility study is free.
Why do so many IoT projects stall at the prototype?
The typical way an IoT project stalls at the prototype is familiar. A team builds a working prototype in a few weeks from an off-the-shelf development board, a handful of sensors and a cloud dashboard. The demo goes well and management says, "Let's build two hundred of these."
Then the problems arrive one by one. The development board is not fit for the field, the enclosure lets in moisture, the battery dies in weeks, the unit in the basement never reports, and when a software bug appears someone has to visit every device.
None of these problems is technically unsolvable. What they have in common is that a prototype answers "does it work?", whereas a product must answer "does it work in the field for years, in hundreds of units, and can we maintain it?" The second question needs a different process; and when hardware comes from one company, firmware from another and the dashboard from a third, every field fault turns into an email thread that begins with "nothing wrong on our side".
Why does unplanned IoT development cost so much?
IoT devices are no longer the exception; they are part of everyday business infrastructure:
According to IoT Analytics' State of IoT 2025 report, published in October 2025, the number of connected IoT devices is expected to grow 14% to 21.1 billion in 2025 and reach 39 billion by 2030. (IoT Analytics — State of IoT 2025)
The business use cases are well established too. Eurostat's "Use of Internet of Things in enterprises" data show that in 2021, 29% of EU enterprises with 10 or more employees used IoT devices or systems; of these, 72% used them to secure their premises, 30% to manage energy consumption and 24% for condition-based maintenance. On the cellular side, the Ericsson Mobility Report (June 2026) puts cellular IoT connections worldwide at around 4.5 billion at the end of 2025.
At this scale, an IoT design flaw affects a whole fleet rather than one device. A hardware change discovered late means a board revision, new tooling and replacing units already in the field; caught at the design stage, the same issue is a drawing correction.
Expectations on security are shifting as well. The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to handle vulnerabilities throughout the product's life; according to the European Commission, the Act entered into force on 10 December 2024, reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. A device that cannot be updated remotely will struggle to meet that bar. In Türkiye, regulation reaches field devices directly too: the automatic meter reading obligation brings communication hardware to the meters of industrial users.
What are the stages of the IoT product development process?
- Requirements and feasibility. What will the device measure or control, where will it be installed, where does its power come from, and which software will receive its data? Environmental conditions (temperature, humidity, dust, water, vibration), expected volumes and target lifetime are written down here; collecting them in a technical specification makes conversations with suppliers far easier. This is also the moment to ask honestly whether an off-the-shelf device already does the job.
- Architecture and component selection. Processor, sensors, connectivity, power source and enclosure class are decided. Connectivity deserves particular care because it drives battery size, antenna design and running costs; we compare the options in our LoRa vs NB-IoT vs cellular guide, and if LoRa wins, choosing a LoRaWAN gateway shapes the network side. Choosing components with long-term availability avoids the "this part is discontinued" crisis in year two of production.
- Design: board, enclosure, firmware, dashboard. Schematic and PCB (printed circuit board) layout, mechanical enclosure, embedded software (firmware) architecture and the web/mobile management panel are designed together. Antenna placement must be discussed alongside the enclosure, power management alongside the firmware, and the data model alongside the dashboard. The protocol the device uses to send data upstream is settled here too; for lightweight messaging over constrained links, the MQTT protocol is a common choice. Over-the-air (OTA) updates and device authentication go into the design here; they are not bolted on later. How the device will join the network should be thought through alongside the principles in our OT security for SCADA guide.
- Prototyping and field testing. Prototypes are tested at real installation points, not just in the lab: signal, battery drain, temperature and humidity, ease of mounting. Environments such as reefer truck temperature monitoring, with constant vibration and door openings, or smart greenhouse automation, where condensation never goes away, cannot be reproduced in a lab. Every issue found in the field goes back into the design before series production; it is normal for this loop to take several rounds.
- Compliance and production readiness. Requirements such as the enclosure's ingress protection (IP) rating, CE conformity assessment for devices with radios, and electromagnetic compatibility (EMC) are settled. Design for manufacture is reviewed, and a test rig is built so every unit can be checked before shipping. We look at protection ratings separately in our IP rating explainer. In hospitals, electromagnetic compatibility and disinfectant-proof tags matter even more, as our guide to hospital medical equipment tracking explains.
- Series production. The approved design goes into production and every unit passes a functional test before dispatch. Serial number, firmware version and identity credentials are recorded for each device; only then can a field problem be traced back to a production batch. The serial number can be carried by a barcode on the enclosure or by a suitable RFID tag type. For measuring devices, calibration records are kept at this stage as well; in regulated uses such as pharmaceutical warehouse temperature mapping, data from an uncalibrated sensor is not accepted.
- Commissioning and remote operation. Devices are installed, software is configured and data flow to existing systems is verified. From then on, device health (signal, battery, last contact) is monitored from a central remote monitoring platform; software issues are fixed remotely and hardware faults on site. Remote pump station monitoring, with sites spread over a wide area, is one of the most typical examples of this stage.
IoT development stage outputs: what goes wrong if you skip them?
| Stage | Concrete output | Field problem if skipped |
|---|---|---|
| Feasibility | Written requirements and feasibility assessment | A device that solves the wrong problem |
| Architecture | Component list, connectivity and power decisions | Short battery life, devices out of coverage |
| Design | PCB, enclosure drawings, firmware architecture, OTA plan | Devices that cannot be updated and must be removed |
| Field testing | Test report and design revisions | Design flaws multiplied in production |
| Production readiness | Compliance file, test rig | Faulty units shipped unnoticed |
| Series production | Tested, registered devices | Batch faults that cannot be traced |
| Operation | Monitoring panel, update process | A fleet that quietly stops reporting |
The stages of IoT development depend on each other: when a field-test round runs long, compliance work and the production date slip with it. To track that schedule within your own team, SmartPM, the project management software in our Smart product family, lays the stages out on a Gantt chart with dependencies; when a predecessor runs over, the tasks that follow move forward automatically, the critical path stays visible, and milestones such as prototype sign-off are marked on the chart. To buy SmartPM, fill in the SmartPM sales form.
What do IoT development time and cost depend on?
The time and budget for IoT product development cannot be given as a single figure; they vary from project to project with a few decisive factors:
- New design or adaptation? Adapting an existing design takes far less time than designing a new device from scratch.
- Number of field-test rounds. Field testing usually stretches the schedule most; early access to installation points shortens it.
- Compliance requirements. For devices with radios, CE conformity assessment and EMC work add to the schedule and the budget.
- Enclosure and environment. A high protection rating, direct sun, vibration or condensation call for extra design and testing.
- Volume and integration. Production quantity, test rig needs and the software the data must reach define the scope.
A realistic timeline and cost are set out, phase by phase, in the written proposal that follows the feasibility study.
Common mistakes in IoT device development
- Mistaking a development board for a product. A bench board is not a production design in terms of power draw, size, temperature tolerance or unit cost.
- Leaving connectivity until last. Changing technology after the antenna and enclosure are designed reopens most of the design.
- Not working out the power budget on paper. A battery-life estimate that ignores sleep current, daily transmissions and how long the radio stays on in weak signal will not hold in the field; measure at the real installation point.
- Underestimating the environment. Heat inside an enclosure in direct sun, condensation, vibration and pressure washing are the most common causes of faults that never show up in the lab. A water tank level monitoring device on a roof or hilltop faces most of them at once.
- Not planning for updates. With no remote update path, every bug fix becomes a site visit.
- Forgetting who will use the data. If device data never reaches an ERP (enterprise resource planning) system, SCADA or a decision dashboard, the project measures things but creates no value. That is why connecting meter and sensor data to a decision panel, as in hospital building energy management, is part of the project.
- Ignoring the equipment already on site. PLCs (programmable logic controllers), meters and power analysers in a plant mostly speak Modbus RTU or TCP, while HVAC and heating plant in buildings is usually run through BACnet building automation. If a new device cannot talk to these protocols, the integration gets rewritten on site.
- Splitting hardware and software between suppliers. Split responsibility slows down every fault investigation.
Examples of IoT devices in harsh field conditions
Livestock farming is a good example of IoT devices working in harsh conditions: humidity and ammonia in the barn, sun and dust on pasture. We cover this application in our guide to the livestock monitoring system. In open fields, irrigation automation and remote monitoring devices have to cope with mud, sun and no mains power.
Not every project needs a device designed from scratch. In warehouses and in the field, off-the-shelf readers and terminals are often combined with the right software; RFID inventory and asset tracking and handheld terminal stock counting describe that route.
Stores look similar: in self-checkout kiosk and retail digital signage management projects the hardware is largely standard, and the real difference lies in central management and integration software.
How we develop IoT devices at Digital Bridge
Electronics and PCB design, mechanical enclosures, embedded software and web/mobile management panels all sit within the same team at Digital Bridge. That means antenna and enclosure, power management and firmware, data model and dashboard are designed together from the start, and there is one party responsible when something goes wrong in the field.
- Our technical feasibility study is free. We tell you in writing whether the project is feasible and which route makes sense. If an existing product already meets your needs, we say so; our industrial products range covers kiosks, card access control, industrial data terminals and meter reading.
- One team from design to installation. In our IoT device design and manufacturing service, needs analysis, design, prototyping and field testing, series production, installation and commissioning are handled by the same project team, with scope, phases and cost set out in a written proposal. Who owns the design files and source code is written into that proposal too; our guide to software contracts and source code explains why it matters.
- We test in the field. We trial prototypes at real installation points and feed the findings back into the design before series production. Every unit is tested before dispatch.
- We connect the data to your business systems. Through system integration we pass device data to your ERP, SCADA or in-house software via API, and where field teams need it we build a mobile app.
- We keep an eye on the fleet. Device status is tracked through a remote monitoring panel; we resolve software issues remotely and hardware faults on site.
For a concrete example, see how we design the meter-mounted communication device around site coverage in our automatic meter reading guide, or the field sensor networks in our guide to soil moisture sensors for precision agriculture. Our connectivity, protection-rating and field-device guides are all collected in the IoT & Hardware hub.
How do you start an IoT device project?
If you have an IoT device in mind, write a one-page brief before any development starts: what it will measure or do, where it will be installed (with photos), its power source, the expected quantity and the software its data should reach. Then get in touch through our contact page and we will work through the technical feasibility with you.