Top 10 IoT Tools and Platforms Every Developer Must Check in 2026

As the Founder and CEO at Acquaint Softtech, I find this article more useful as evidence than as advice. Six of the ten platforms it recommended in 2018 no longer exist in the form described. IBM retired Watson IoT. GE's Predix was dismantled and sold in pieces. Carriots is gone, ThingWorx has changed owners, and the rest have been absorbed or renamed. That is a sixty percent failure rate over eight years, and it is the most important thing an IoT article can tell you, which is why our software product development teams now choose IoT architecture around survivability before features.

The devices did not disappear. Sensors installed in 2018 are still on walls, in vehicles and inside machinery, and many of them were speaking to a cloud service that has since been switched off. Somebody paid to re-integrate every one of those fleets. So this rewrite gives you the current list, but it spends more time on the question the original never asked: how do you pick a platform that will still be there when your hardware is halfway through its ten-year life?

---

The article defined IoT correctly and then listed ten vendors with a sentence each. The definition still holds. The list does not, and a list without selection criteria was never going to age well, because it told you what existed rather than how to choose.

So this version starts with the choosing, gives an honest post-mortem on the old list, then names the platforms worth your time and the protocol decisions that protect you when one of them closes.

Match Your Project to the Right IoT Platform

Platform choice follows device count, connectivity, and who maintains it, not brand familiarity. Find the row that describes what you are building.

What you are building	Sensible starting point	Why
Prototype or proof of concept	Node-RED with MQTT	Working demo in days, nothing locked in
Under 1,000 devices, small team	Losant or Particle	Managed, quick, predictable pricing
Large fleet, existing AWS estate	AWS IoT Core	Integrates with what you already run
Large fleet, Microsoft estate	Azure IoT	Same logic, different ecosystem
Data must stay on your servers	ThingsBoard or EMQX	Self-hosted, open source, no exit risk
Cellular devices in the field	Particle or Balena	SIM, provisioning and updates included
Consumer or smart-building work	Home Assistant	Huge device support, local control
Millions of messages per second	EMQX or a managed broker	Built for broker throughput specifically

 Notice that four of those rows point to open source. That is not ideology; it is the practical response to what happened between 2018 and now. When you host the platform yourself, a vendor's business decisions stop being your operational risk, and that trade is usually worth the extra work of running it. Deciding which side of that line you sit on is the first thing we settle in discovery workshop services for connected products.

What Happened to the 2018 List

Only two platforms from the original ten remain intact and recommended under the same name. Here is what happened to each, because the pattern matters more than the individual outcomes.

2018 recommendation	Status in 2026	What it means
Amazon Web Services IoT	Active and strong	Still a default choice
Microsoft Azure IoT	Active and strong	Still a default choice
IBM Watson IoT	Retired	Customers had to migrate elsewhere
GE Predix	Broken up and sold	Assets folded into a new entity
ThingWorx	Sold, new ownership	Continuity now a commercial question
Cisco IoT Cloud Connect	Repositioned	No longer a general developer platform
Salesforce IoT Cloud	Discontinued	Function absorbed into wider CRM
Carriots	Gone	Acquired, then wound down
Oracle IoT Cloud	Deprioritised	Not a mainstream recommendation
Kaa	Still available	Smaller community than in 2018

The pattern worth learning

IBM's own cloud documentation records the deprecation of Watson IoT Platform, and it followed Google withdrawing its IoT Core service on a similar timeline. Two of the largest technology companies in the world concluded that a standalone IoT platform was not a business they wanted, and they exited. Nothing about your architecture caused that, and nothing about your architecture could have prevented it. What your architecture can control is how expensive the exit is for you.

The single-vendor risk is highest where the platform owns your device identity, your message format and your data model at the same time. Separate those three and a shutdown becomes a project rather than a crisis.

Send me the platform your devices connect to, and I will tell you its current status, what a migration would involve, and how to structure the move so it does not happen to you again.

The 10 Platforms Worth Checking in 2026

These ten cover the realistic range from weekend prototype to industrial fleet. Each entry says what it is good at and what it is not.

1. AWS IoT Core

The most complete managed offering, with device shadows, rules routing into the wider AWS estate, fleet provisioning and over-the-air updates. Choose it when you already run on AWS. Be aware that costs scale with message volume in ways that surprise teams, and that deep use of proprietary services is exactly the lock-in this article warns about.

2. Azure IoT

Microsoft's equivalent, strong in industrial settings and where Active Directory, Power BI and existing enterprise agreements already exist. Device provisioning and edge deployment are mature. The same cost and lock-in caveats apply, and the choice between it and AWS is usually decided by your existing estate rather than by capability.

3. ThingsBoard

The open-source platform most teams land on when they want dashboards, rule chains and device management without a vendor relationship. Available as a managed service or self-hosted. Choose it when data residency matters or when you want the option to move providers without changing your application.

4. EMQX

A high-performance MQTT broker built for very large device counts and message rates, available open source and managed. This is the right choice when your problem is throughput and reliability of messaging rather than dashboards, and it pairs well with your own application layer on top.

5. Node-RED

A flow-based tool for wiring devices, APIs and services together visually. It is the fastest way to prove an idea works, and it runs happily on a Raspberry Pi. Treat it as a prototyping and integration tool rather than the backbone of a production fleet, and you will get enormous value from it.

6. Losant

A developer-friendly managed platform covering device management, workflows and dashboards, suited to small and mid-sized fleets. It is a good middle path for teams who want speed without running infrastructure, and pricing is more predictable than usage-based hyperscaler billing at modest scale.

7. Particle

Hardware, connectivity, and cloud in one package, including cellular modules and SIMs. This removes an enormous amount of work for products that ship into the field with no Wi-Fi. The trade is a tighter tie to their hardware ecosystem, which is a reasonable exchange for a small team shipping a physical product.

8. Balena

Focused on the problem most IoT projects underestimate: deploying and updating software on fleets of Linux devices safely. Containerised delivery, rollback and remote access. If your devices are gateways or edge computers rather than tiny sensors, this solves the operational half of the job.

9. Home Assistant

The strongest platform for consumer, residential and smart-building work, with support for a very wide range of devices and full local control. It is open source with an unusually active community, and for building automation projects it will often outperform a commercial platform at a fraction of the cost.

10. Grafana with a time-series database

Not an IoT platform, and deliberately included. A great deal of what teams want from a platform is storage, alerting, and dashboards over sensor data, which Grafana paired with a time-series database delivers without any IoT vendor at all. Building this layer is standard backend work, and teams typically hire Python developers or their Node equivalents for the ingestion and processing around it.

How to Avoid Being Stranded Again

Four architectural decisions determine whether a platform shutdown costs you weeks or years. They cost almost nothing to apply at the start and are expensive to retrofit.

Speak an open protocol

Use MQTT as your device transport rather than a vendor-specific SDK wherever the hardware allows. It is the de facto standard for constrained devices, every serious platform supports it, and it means the conversation between your device and the cloud does not depend on who owns the cloud. Firmware written against MQTT can be pointed at a different broker with a configuration change.

Own your device identity

Device credentials and certificates should be issued and tracked by something you control, not generated inside a platform you rent. When identity lives in the vendor, migrating a fleet means physically reprovisioning devices, which is where the real cost of a platform exit is buried.

Keep a copy of the raw data

Stream raw telemetry into your own storage in parallel with whatever the platform does with it. Storage is cheap, and history is irreplaceable. Teams that skipped this step during the platform shutdowns of the last few years lost years of readings they can never recover, and the pipeline for it is routine work for anyone you hire data engineers to build.

Assume firmware updates are permanent infrastructure

Over-the-air update capability is not a feature to add later. A device you cannot update is a device you cannot fix, cannot secure, and cannot migrate. Build it first, test the rollback path, and treat it as seriously as the product feature it protects.

The Regulation That Changes IoT Budgets

Connected products sold in the EU now carry legal security obligations that did not exist when this article was written. If you sell hardware into Europe, this affects your build cost and your support commitments.

The EU Cyber Resilience Act sets cybersecurity requirements for products with digital elements, covering secure development, vulnerability handling and the duty to provide security updates for a defined support period. In practical terms, it moves firmware maintenance from a goodwill activity to a contractual and regulatory one, and it applies to the manufacturer regardless of where the device was designed.

What it means for a project plan

Budget for a support window rather than a launch. A device sold in 2026 may carry an update obligation for years afterwards, which means signing keys, build pipelines and a team capable of shipping firmware must exist for that whole period. Teams that hire DevOps engineers for the release pipeline early find this straightforward; teams that hand-build firmware releases find it very expensive later.

The UK and Australia have moved in a similar direction on consumer connected-device security, so a product built to the EU standard is generally well placed for those markets too. Treating security as a launch checkbox rather than a lifecycle commitment is now the more expensive option, and it is why we scope firmware upkeep inside support and maintenance services rather than leaving it unowned.

What an IoT Build Costs

IoT projects cost more than equivalent web projects because the device, the cloud, and the operations are three separate builds. These are prevailing market ranges rather than fixed quotes.

Location	Senior engineering rate	Relative cost
New York, USA	USD 110 to 200 / hour	Highest
United States (national)	USD 90 to 170 / hour	Very high
Australia	AUD 110 to 200 / hour	High
United Kingdom	GBP 65 to 130 / hour	High
Europe (EU)	EUR 70 to 140 / hour	High
India (Acquaint Softtech)	USD 25 to 49 / hour	Up to 40% lower

Scope	What it covers	Estimated cost (USD)
Proof of concept	Few devices, dashboard, one flow	10,000 to 30,000
Pilot deployment	Provisioning, updates, alerting	35,000 to 90,000
Production platform	Fleet scale, security, integrations	90,000 to 300,000
Platform migration	Move fleet off a dying vendor	25,000 to 120,000
Ongoing operations	Per year, after launch	20 to 25% of build cost

The last row is higher than for a typical web product, and it is not padding. Connected devices need firmware releases, certificate rotation, security patching, and fleet monitoring for as long as they are in service, and under the new EU rules that period is defined rather than discretionary. 

Companies that treat IoT as a project rather than an ongoing service consistently underestimate the total by a wide margin. For how the software half of that sits inside a broader budget, our guide to web application development cost breaks down the surrounding line items.

Where the analytics layer matters more than the devices, the cost centre shifts again, and teams hire AI/ML engineers to turn telemetry into predictions rather than dashboards. Our write-up of an AI-powered guest experience platform shows what that looks like once sensor data starts driving decisions rather than charts.

Frequently Asked Questions