The Internet of Things is what happens when ordinary objects gain a network connection and start producing data. A thermostat reports the room temperature every minute. A pump reports its vibration signature. A fleet of delivery vans reports position, fuel and door-open events. The opportunity is enormous — and so is the number of ways an IoT project can quietly go wrong between the working prototype on a desk and the ten thousand devices in the field.
In this article, Inverge Tech outlines the IoT product layers, typical failure points, and early decisions to avoid a costly rebuild.
It is a systems problem, not a device problem
A successful IoT product is really four products in a trench coat: firmware on the device, a reliable transport layer, a cloud backend that ingests telemetry at scale, and a dashboard humans can act on. Weakness in any one sinks the whole thing.
The most common mistake is to treat the device as the product and the rest as plumbing. Hardware teams build an excellent sensor node, prove it on a bench, and then discover that the "cloud bit" is a separate engineering discipline with its own failure modes — message queues that back up, databases that cannot absorb the write rate, dashboards that time out once there is a month of history. The device was never the hard part. Making the data trustworthy, at scale, for years, is.
Layer one: firmware that can be fixed after it ships
Firmware is the one layer you cannot easily change once devices are installed on customer sites, so it needs to be built with that in mind. Secure boot, signed images and over-the-air updates are not features to add in version two. Without them, the first serious bug or security advisory means a truck roll to every device — and a product that cannot be patched will eventually be a product that is compromised.
Two other decisions matter early. First, how the device behaves when the network is down: it should buffer readings locally and replay them, with timestamps from a clock it can trust, rather than silently dropping data. Second, how it identifies itself: each device needs a unique, unforgeable identity provisioned at manufacture, so the cloud can tell a genuine unit from a cloned one.
Layer two: a transport that survives bad networks
The link between device and cloud is usually the least reliable part of the system, and the protocol choice has to reflect that. MQTT is the default for a reason: it is lightweight, works well over intermittent connections, and its publish–subscribe model maps cleanly onto "many devices, a few consumers". For constrained devices on lossy links, CoAP or LoRaWAN may fit better. HTTP is fine for occasional uploads but unsuitable for frequent or battery-powered communication.
Whatever the protocol, design for message loss and duplication from the start. Give every reading a sequence number and a device timestamp. Make the ingestion side idempotent so a replayed message does not create a second record. Plan for the case where a thousand devices reconnect at once after an outage and all try to flush their buffers together.
Layer three: a pipeline built for time-series data
Telemetry is time-series data, and it has a shape that general-purpose databases handle badly: enormous write volume, mostly recent reads, queries that aggregate over time windows, and a retention policy that downsamples old data rather than keeping it forever. Storing it in an ordinary relational table works for a pilot and falls over at scale, usually at the worst moment.
The pattern that holds up is a broker or streaming layer at the edge of the cloud (an MQTT broker, Kafka, or a managed equivalent), a stream processor that validates and enriches each message, a time-series store for the readings, and a conventional database for device metadata, users and configuration. Alerts and aggregations are computed as data arrives, not by scanning history on every dashboard load.
- Validate at the door. Reject malformed or out-of-range readings before they pollute the store. A sensor reporting minus 300 degrees is a fault, not a data point.
- Downsample deliberately. Keep raw readings for weeks, one-minute averages for months, hourly summaries for years. Decide the policy up front and let the store enforce it.
- Separate hot and cold paths. Real-time alerts run on the stream; historical analysis runs on the store. Mixing them makes both slow.
Layer four: dashboards that lead to action
Devices are just sensors. The value is in turning a firehose of raw telemetry into decisions — alerts that matter, trends that predict failure, and controls that respond in real time. A dashboard that shows every metric for every device is a screen nobody looks at after the first week. A dashboard that shows the twelve devices needing attention today, and why, is one the operations team opens every morning.
The best IoT dashboards are boring on a good day. That is the goal: a screen that is empty because nothing needs attention is a screen doing its job.
Design the interface around the questions people actually ask: what is wrong right now, what is about to go wrong, and what changed since yesterday. Alerts need thresholds that adapt to normal variation, routes to the right person, and a way to acknowledge and silence them, or they become noise within a month and get ignored.
Where IoT is paying off today
The use cases with the clearest return share a trait: the data replaces a decision that used to be made blind, late, or by sending a person to look.
- Predictive maintenance. Vibration, temperature and current draw on motors, pumps and compressors reveal wear weeks before failure. Replacing a bearing on schedule costs a fraction of an unplanned line stop.
- Cold-chain and environmental monitoring. Continuous temperature and humidity logs for food, pharmaceuticals and laboratories, with alerts the moment a threshold is crossed and an audit trail regulators accept.
- Fleet and asset tracking. Location, utilisation and condition of vehicles, containers and equipment — which turns "where is it?" into a query rather than a phone call.
- Smart buildings and energy. Occupancy-driven heating, lighting and ventilation, sub-metering by floor or tenant, and the data to prove efficiency claims.
- Agriculture. Soil moisture, weather and irrigation control at field scale over low-power radio, where a few sensors change how a whole season is managed.
In each case the device is commodity hardware. The value, and the engineering effort, is in the pipeline that turns readings into a decision someone trusts enough to act on.
Security runs through every layer
IoT security failures are rarely exotic. They are default passwords, unencrypted links, devices that trust any server that answers, and update mechanisms that accept unsigned firmware. Each layer needs its own controls: per-device credentials and mutual TLS on the transport, signed firmware and secure boot on the device, least-privilege access and audit logs on the cloud, and role-based permissions on the dashboard. Treat the device fleet as untrusted endpoints, as compromised devices are inevitable.
Pillars of a shippable IoT product
- Secure, updatable device firmware with a unique identity per unit
- A resilient, low-bandwidth transport layer that tolerates loss and reconnection storms
- A cloud pipeline built for time-series data, with validation and retention policies
- Dashboards and alerts that turn telemetry into action rather than into charts
- End-to-end security, from silicon to screen, designed in rather than bolted on
- Observability of the system itself — you need to know when the pipeline is unhealthy before the customer does
Frequently asked questions
Should we build the cloud side ourselves or use a managed IoT platform?
Managed platforms from the major cloud providers handle device identity, the MQTT broker and basic routing well, and they are a sensible starting point. The parts that differentiate your product — the data model, the alerting logic, the dashboard — will be custom either way. The risk to watch is cost at scale, which can climb steeply with message volume, so model it before you commit.
How much data will our devices produce?
Multiply devices by readings per device by frequency, then add headroom. A thousand devices reporting ten values every ten seconds is close to nine million readings a day. That is comfortable for a proper time-series pipeline and catastrophic for a spreadsheet-shaped database, which is why the storage decision has to be made before the fleet grows.
What is the most common reason IoT projects stall?
A prototype that worked with five devices on office Wi-Fi being scaled up without redesigning the transport and storage layers. The symptoms are lost readings, slow dashboards and alerts that fire late. The fix is almost always architectural, and it is far cheaper to get right before deployment than after.
We build the full IoT stack — from the device firmware to the dashboard your team logs into every morning — so the data is not just flowing, but actually useful.