Insights · 5 min read
IoT platform development goes wrong when teams obsess over the dashboard and forget the device layer. What telemetry and OTA updates taught us.
By GGP Editorial
An IoT platform looks simple in a pitch deck: a map, some sensors, a dashboard with charts, and a button that turns something on. The demo is easy to build, and it is the least useful part of the whole system. The parts that make or break an IoT project are the device layer, the data pipeline, and what happens when a device goes dark at three in the morning.
We have built enough of these at GlobeSoft to know where the real schedule hides. Here is the practical version.
Every IoT system starts with hardware you do not control. Sensors, gateways, meters, trackers. They run on constrained hardware, they lose power, they lose signal, and they report wrong readings when their battery is low.
The platform has to assume the device is unreliable. That one assumption changes how you design everything else. Messages need unique IDs so you can deduplicate. Timestamps have to come from the device, or be assigned the moment a message arrives, because arrival order is not the same as event order. And you need a clear rule for what "offline" means, because a device that sends nothing for five minutes is different from one that sends nothing for five days.
We had a tracker fleet once where a handful of units reported stale GPS for hours because a firmware bug kept caching the last fix. The platform showed the vehicles in the wrong place, and the client only noticed when a customer complained. The fix was on our side, but the lesson was on theirs: the platform has to flag stale data, not just display it.
Skip this layer and you will spend your launch month chasing ghost alerts.
A handful of devices is easy. A fleet is a different project. When thousands of devices each send a reading every few seconds, the problem stops being "how do I show a chart" and becomes "how do I store and query this without the bill eating the margin".
The usual pattern looks like this:
| Layer | What it does | Common stack |
|---|---|---|
| Ingest | Receives device messages, deduplicates, orders them | Go or Java, MQTT broker |
| Hot storage | Recent data for live dashboards and alerts | Redis |
| Cold storage | Historical data for reports and analytics | MySQL or a time-series store |
| Rules | Thresholds and alerts on incoming streams | Java, Python |
| Control | Commands sent back down to devices | Go or Java |
The goal is not to collect everything forever. A good rule of thumb is to keep the last thirty days of raw telemetry hot and roll older data into hourly or daily aggregates. Most reporting questions are about trends, not individual readings, and aggregates cost a fraction to store and query. Storage cost is where most IoT budgets quietly disappear.
A device in the field that you cannot update is a liability. Requirements change, bugs surface, and certificates expire. If your only fix is a technician visit, your platform has a ceiling.
Over-the-air updates, signed firmware, and per-device credentials sound like extra work at the start, but they are the difference between a platform you can run for years and one you abandon. Version the firmware, sign the images, and test the downgrade path, because you will use it. A botched update that bricks a fleet is a support problem no amount of dashboard polish fixes.
On security, treat every device as already compromised. Give it only the access it needs, rotate keys, and log everything. It is cheaper to do this up front than to explain a breach later.
The stall rarely comes from the technology. It comes from a client who has never seen a device in production and cannot tell you what "normal" looks like. If nobody can define the failure cases, the platform cannot handle them.
That is why we start every IoT engagement with a written spec of the failure modes: what happens when a device goes offline, when a reading is out of range, when the power fails mid-update. The answers are unglamorous, and they are what keep the project on schedule.
We run these builds the way we run the rest of our work at GlobeSoft: a China-based engineering team, a defined overlap window for calls with clients in Brazil, South Africa, Singapore, or the US, and a written trail for everything in between. IoT, finance, property, payments, whatever your industry is, if it is legal, we will build it.
Tell us what you are building and where you are today. We typically reply within 24 hours.
