The IoT product development process has seven stages: requirements and feasibility, architecture and component selection, design of the board, enclosure and firmware, prototyping and field testing, production readiness, series production, and commissioning and remote operation. What turns a bench prototype into devices that run in the field for years is the right decision at each stage, taken on time.
The costliest mistakes come from carrying early choices about connectivity, power and environment into series production without testing them on site.
Why so many IoT projects stall at the prototype
The pattern 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".
What unplanned development costs
IoT devices are no longer the exception; they are part of everyday business infrastructure:
IoT Analytics expects the number of connected IoT devices 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 reports 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 puts cellular IoT connections at around 4.5 billion at the end of 2025.
At this scale, a 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: regulations such as the EU Cyber Resilience Act require manufacturers of products with digital elements to handle vulnerabilities and provide security updates over the product's life, with obligations phasing in over the coming years. A device that cannot be updated remotely will struggle to meet that bar. In Turkey, regulation reaches field devices directly too: the automatic meter reading obligation brings communication hardware to the meters of industrial users.
Seven stages from idea to series production
- 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 layout, mechanical enclosure, embedded software 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. This loop may take several rounds, and that is normal.
- Compliance and production readiness. Requirements such as the enclosure's ingress protection (IP) rating, CE conformity assessment for devices with radios, and electromagnetic compatibility 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.
Stage by stage: outputs, and 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 |
Common mistakes
- 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 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, SCADA or 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.
- 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.
- Ignoring the equipment already on site. PLCs, 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.
Livestock farming is a good example of 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.
Next step
If you have a 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.