By Igor Lenskii, Chief Product Advertising and marketing Specialist at IoTellect.
The IoT platform market is mature sufficient to have dozens of choices and immature sufficient that lots of them aren’t actually platforms in any respect. Selecting the mistaken one doesn’t normally blow up at deployment. It surfaces later, when margins shrink, initiatives stall, and switching prices are already too excessive.
After years of watching system integrators, OEMs, and enterprise groups navigate this alternative (and generally deeply remorse it), I’ve distilled a 20-point choice guidelines. However earlier than you undergo all twenty, listed below are 5 traps that preserve destroying initiatives and enterprise relationships. These are usually not edge circumstances. They’re patterns.
Lure 1: You’re Evaluating a Dashboard Builder, Not a Platform
A vendor reveals you a slick demo. Good charts, clear UI, knowledge flowing from an MQTT dealer right into a time-series database, some alerts on prime. Seems to be like an IoT platform, proper? It’s not. A dashboard builder with an MQTT dealer bolted on just isn’t an IoT platform. A tool administration software with an online interface isn’t one both. And a single-vertical answer repackaged as one thing “generic” might be the worst offender: it seems to be convincing till you attempt to do one thing exterior that one vertical.
Earlier than you consider anything, be sure the platform covers absolutely the minimal: multi-protocol connectivity (not solely MQTT/HTTP), bi-directional machine management, structured hierarchical knowledge modeling, event-driven processing with correlations and root trigger evaluation, native visualization, API-based integrations, and a safety mannequin that goes past TLS and passwords.
If even certainly one of these is lacking, it’s not an enterprise IoT platform. It’s a part that can require 5 extra elements round it, every with its personal integration price, upkeep burden, and level of failure. Stroll away early.
Lure 2: “MQTT and REST” Is Not a Connectivity Technique
This one is deceptively easy. MQTT and REST work fantastically for contemporary sensors and clear APIs. The primary challenge flows, everyone seems to be blissful. Then comes the second challenge with industrial PLCs, Modbus, OPC UA, and even legacy serial protocols. The platform can’t connect with half the gadgets, and the crew is caught.
Even if you happen to’re constructing only one answer at this time, take into consideration tomorrow. Your subsequent buyer or vertical will virtually definitely carry gadgets that don’t communicate MQTT. And if each unsupported machine requires an costly gateway or the seller’s skilled companies to combine, your margins will erode with each new challenge.
What you really need is broad industrial protocol help overlaying each IT and OT, an SDK or driver framework you should utilize your self, and the power to construct customized protocol adaptors with out calling the seller each time. Gateway and edge connectivity ought to be a part of the deal, not a separate product with a separate price ticket. If the platform locks you into “MQTT/REST only”, you’re choosing a constraint, not a platform.
Lure 3: Weak Knowledge Modeling: the Silent Margin Killer
Knowledge modeling is invisible throughout demos and tends to floor solely when actual cash is already on the desk.
Most platforms provide some type of “device twins” or “digital twins”, primarily a flat construction the place every machine has properties and possibly some metadata. That works for monitoring dashboards. It doesn’t work for actual IoT options the place you want hierarchy: Enterprise → Manufacturing unit → Workshop → Manufacturing Line → Unit, or Constructing → Flooring → Zone → Room → Sensor. These aren’t beauty layers. They outline how knowledge flows, how entry management works, how alerts propagate, and the way operators truly work together with the system.
Ask explicitly: does the platform help a proper, platform-wide knowledge mannequin? Are you able to visually design customized enterprise object hierarchies, not simply flat machine lists? Are you able to outline parameters, operations, occasion sorts, and dynamic object-to-object bindings? Is that this reusable throughout initiatives?
Right here’s a sensible check I at all times suggest: take the platform’s demo and attempt to construct your precise asset hierarchy. Not the seller’s instance. Yours. If it takes greater than a day and nonetheless feels awkward, you have got your reply.
When knowledge modeling is weak, each challenge turns into customized improvement. You hardcode what ought to be configurable, duplicate what ought to be inherited, and each new buyer multiplies the issue as an alternative of reusing the answer. That is how SIs find yourself shedding cash on initiatives that regarded worthwhile on the proposal stage.
Lure 4: Cloud-Solely Deployment is a Time Bomb
Cloud-native is nice. Cloud-only is a severe strategic danger, particularly in industrial IoT, telco, and authorities sectors. A major share of enterprise clients both can’t or received’t put their operational knowledge right into a public cloud. Utility corporations have knowledge residency necessities. Producers need the whole lot behind their firewall. Telcos must run the platform in their very own knowledge facilities. This isn’t a distinct segment concern; it’s the fact for many industrial deployments.
If the platform solely runs within the vendor’s cloud or helps only one public cloud supplier, you’ve put a ceiling in your buyer base. And the seller’s promise of “we’ll add on-prem support later” shouldn’t provide you with any consolation. Cloud-to-on-prem portability is an architectural determination that both exists from day one or prices a fortune to retrofit.
The guidelines is somewhat apparent: on-premise deployment, personal cloud, a number of public clouds (not simply AWS or Azure), hybrid architectures, cloud-provider agnostic operation, and edge deployment. Obligatory for any severe industrial, telco, or MSP-oriented enterprise.
Lure 5: The Edge-Cloud Frankenstein
This lure is especially nasty as a result of it hides behind handsome slides. An “edge solution” and a “cloud platform” that work collectively seamlessly. On paper. In actuality, these are sometimes two separate codebases — generally from two separate acquisitions — duct-taped collectively by way of APIs.
The sensible consequence is painful: what’s constructed for the cloud will get rebuilt for the sting. The crew maintains two platforms as an alternative of 1, wants two units of abilities, and runs two deployment pipelines. Code portability between edge and cloud stays a slide-deck fantasy somewhat than an engineering actuality.
What you want is essentially easy (and surprisingly uncommon): similar codebase throughout edge and central platform, similar improvement instruments, no “rewrite for edge” requirement. When a mannequin, a dashboard, or an alert rule designed within the cloud might be deployed to an edge node with out modification — that’s actual edge-cloud compatibility. Every little thing else will price you months per challenge.
Ask the seller instantly: “Is your edge product the same software as your cloud product?” If the reply includes phrases like “lightweight version” or “seamless integration between our two products”, you already know what you’re coping with.
These 5 Are Simply the Begin
Platform choice has extra dimensions than connectivity and deployment. Suppose vendor maturity, AI readiness (sure, it’s 2026 and MCP servers and improvement brokers are a part of the dialog now), safety structure, pricing transparency, and the uncomfortable query of what occurs if the seller disappears.
The important thing takeaway: platform alternative defines your profitability, scalability, and repute for years to come back. Weak platforms have a approach of silently destroying margins earlier than anybody notices.
I’ve put collectively a complete IoT Platform Choice Guidelines overlaying the total image. It’s designed as a sensible sure/no/possibly software: if too many packing containers keep unchecked, stroll away.
→ Learn the total IoT Platform Choice Guidelines (2026 Version)
