The IoT Platform Trap: Why Companies Are Burning Thousands on Free Software
The IoT market has an open secret. One that many service providers don't like to talk about because it threatens their business model.
Anyone shopping for an IoT platform gets flooded with glossy brochures and proprietary brand names. But look under the hood, and you'll often find nothing more than open-source technology – frequently ThingsBoard, Grafana, or ChirpStack – repackaged and resold at a premium.
The result: Companies pay license fees for software that's actually freely available. And they usually pay per device – a pricing model that quickly becomes a problem at scale.
This article analyzes the phenomenon, breaks down the actual costs, and shows alternatives.
Table of Contents
- The White-Label Business Model: How the Platform Trap Works
- The Cost Analysis: What Per-Device Pricing Really Costs
- Why Open Source Doesn't Mean "Free"
- The Hidden Cost Factor: Vendor Lock-In
- Checklist: How to Protect Yourself from the Platform Trap
- The Alternative Model: Paying for Engineering Instead of Licenses
- Conclusion: Know What You're Paying For
The White-Label Business Model: How the Platform Trap Works
The principle is simple: a service provider takes a free open-source platform like ThingsBoard, installs it on their own servers, slaps their own logo on it, and sells access as their "proprietary IoT platform" – complete with monthly per-device license fees.
Technically, this is perfectly legal. Open-source licenses like Apache 2.0 (ThingsBoard) or MIT (ChirpStack) explicitly permit commercial use and rebranding.
But: In many cases, the customer doesn't know that the software at its core is free. And they're paying per device for something that causes no additional costs on the provider's server.
The Open-Source Foundation That Few Know About
Most commercial IoT platforms in the mid-market segment are built on a handful of open-source projects:
| Function | Open-Source Solution | License |
|---|---|---|
| Device Management & Dashboards | ThingsBoard | Apache 2.0 |
| LoRaWAN Network Server | ChirpStack | MIT |
| Visualization & Monitoring | Grafana | AGPL 3.0 |
| Data Flows & Automation | Node-RED | Apache 2.0 |
| MQTT Broker | Mosquitto | EPL 2.0 |
According to the Eclipse Foundation IoT Survey, over 60% of professional IoT developers use open-source components in their projects. This is not a niche phenomenon – it's the industry standard.
How to Spot a White-Label Provider
Not every provider that uses open source is doing white-labeling. What matters is transparency. Here's a checklist:
- Check the login page: Does the interface bear a striking resemblance to ThingsBoard or Grafana – just with a different logo?
- Ask about the technology stack: Reputable providers name their stack openly. Those who deflect often have something to hide.
- Test data export: Can you download a full database dump? Or is your data locked in a proprietary format?
- Review the API documentation: Does the API documentation reference ThingsBoard or ChirpStack endpoints?
- Read the contract terms: Are there clauses that make switching to another provider difficult?
If three or more of these points apply, you're very likely dealing with a white-label product.
The Cost Analysis: What Per-Device Pricing Really Costs
To make the problem tangible, a concrete calculation helps. The following figures are based on market-standard prices that can be derived from publicly available pricing pages of various IoT platforms.
Scenario: A mid-sized company wants to operate 500 sensors – for building monitoring, cold chain monitoring, or smart office applications, for example.
Model A: Per-Device SaaS (White-Label or Proprietary)
Prices vary by provider. Typical market prices for IoT SaaS range between €1 and €5 per device per month. For this calculation, a conservative midpoint of €3 is used.
| Item | Calculation |
|---|---|
| Price per device | €3.00 / month |
| Monthly cost (500 devices) | 500 × €3.00 = €1,500 |
| Annual cost | €18,000 |
| Annual cost at 2,000 devices | 2,000 × €3.00 × 12 = €72,000 |
The central problem with this model: Costs scale linearly with the number of devices. Every new sensor costs exactly the same – regardless of whether the server is already under capacity or not.
Model B: Infrastructure Pricing (Managed Open Source)
With infrastructure pricing, the customer doesn't pay per device but for the actual infrastructure and operations. 500 IoT sensors generate relatively little load – a single dedicated server is sufficient in most cases.
| Item | Cost |
|---|---|
| Server infrastructure (dedicated, backups, traffic) | flat rate |
| Managed operations (updates, security, 24/7 monitoring) | flat rate |
| Typical total cost (500 devices) | approx. €600 / month |
| Annual cost | €7,200 |
| Annual cost at 2,000 devices (larger server) | approx. €9,600 |
The Difference: €10,800 per Year – and the Gap Keeps Growing
At 500 devices, the difference is 60%. But the real effect shows at scale: at 2,000 devices, the company pays €72,000 in the SaaS model – but only around €9,600 in the infrastructure model. That's a difference of over 85%.
The reason is simple: server costs grow logarithmically, not linearly. 2,000 sensors don't need four times the infrastructure of 500 – they need perhaps 30% more.
Why Open Source Doesn't Mean "Free"
At this point, an important objection is warranted: if the software is free, why does operating it cost anything at all?
The answer is familiar to anyone who has ever built a house. Bricks are cheap. The architect and the builders are not.
Building an IoT platform from open-source components and operating it securely requires three disciplines:
1. Architecture & Setup
Installing open-source software is the easy part. The real work lies in the decisions:
- Which database fits the use case? PostgreSQL for relational data, TimescaleDB for time series, InfluxDB for high-frequency sensor data?
- How is the communication between gateways and server secured? VPN tunnels, mTLS, certificate management?
- What does the failover strategy look like if the primary server goes down?
- How are the individual components (MQTT broker, application server, database) meaningfully orchestrated?
These decisions determine whether a platform still runs stably after six months or collapses under load.
2. Ongoing Operations & Security
Software ages. Every month, new security vulnerabilities are discovered in dependencies. Server hardware fails. Disks fill up. TLS certificates expire.
Professional operations include:
- Security patching: Applying security updates promptly, before known vulnerabilities are exploited
- 24/7 Monitoring: Heartbeat checks, resource monitoring, alerting on anomalies
- Backup & disaster recovery: Automated backups, tested restore procedures, geo-redundant storage
- Capacity planning: Scaling up in time, before load becomes critical
This work is necessary – regardless of whether it's handled in-house or outsourced to a specialized operator. The only question is whether you pay a flat operations fee for it or an artificial per-device license.
3. Custom Development
Standard platforms quickly hit their limits in practice. Typical customizations that almost every project needs:
- Payload decoders: Sensor data arrives as binary bytes and must be converted into readable values – individually for each sensor type
- System integration: Data doesn't just need to land on dashboards but must flow into existing ERP, SAP, or CRM systems
- Custom dashboards: The standard interface is rarely enough – custom visualizations for different user groups are the norm
The Hidden Cost Factor: Vendor Lock-In
Perhaps the biggest cost factor with proprietary IoT platforms is invisible: vendor lock-in.
According to a study by Eseye, 94% of surveyed companies report struggling with unexpected challenges in IoT projects. One of the most common reasons: dependency on the platform provider.
How Vendor Lock-In Works
The pattern is always similar:
- No database access: The customer has no direct access to the database. Export is only possible in proprietary formats – or not at all.
- Proprietary APIs: The interfaces follow no standard. A migration means rebuilding all integrations from scratch.
- Contractual binding: Minimum contract terms of 12–36 months, combined with automatic renewal.
- Data loss on cancellation: Historical sensor data is lost after cancellation because no complete export is possible.
What the Alternative Looks Like
With an open-source-based setup and a transparent operator:
- The database belongs to the customer. A complete dump is possible at any time.
- The configuration is documented and exportable.
- The stack is based on open standards – switching operators doesn't require migrating the software.
- There is no lock-in: the customer stays because the service is right, not because they're trapped.
Checklist: How to Protect Yourself from the Platform Trap
Before committing to an IoT platform, ask these seven questions:
-
"What technology stack is your platform built on?" – Reputable providers answer openly. Evasive answers are a warning sign.
-
"Can I get a complete database dump of my data?" – If not: vendor lock-in.
-
"What happens to my data if I cancel?" – The only acceptable answer: complete export in a standard format.
-
"How is the price structured?" – Per-device pricing without a transparent breakdown suggests margin maximization.
-
"Which open-source components do you use?" – An honest answer builds trust. Silence creates dependency.
-
"Can I run the platform myself if I choose to?" – With open-source-based setups: yes. With proprietary platforms: no.
-
"Is there a minimum contract term?" – Flexibility shows that the provider is confident in the quality of their service.
The Alternative Model: Paying for Engineering Instead of Licenses
The solution to the white-label problem isn't doing everything yourself. Most companies have neither the time nor the staff to run an IoT stack on their own.
The solution is a different pricing model: infrastructure pricing. Instead of artificial per-device licenses, the customer pays for what actually costs money:
- Server infrastructure: Dedicated servers, backups, traffic
- Engineering: Architecture, setup, custom development
- Operations: Ongoing management, monitoring, security
This is the approach that providers like merkaio, among others, pursue. The key difference: costs don't scale linearly with the number of devices but with actual infrastructure usage.
Conclusion: Know What You're Paying For
The IoT platform trap isn't malicious intent – it's a business model that thrives on a lack of transparency. Those who understand the technology stack behind the glossy marketing can make informed decisions.
The three key takeaways:
- Many IoT platforms are built on free open-source software. That's not a problem – but it should be communicated transparently.
- Per-device license fees have no technical basis. Server costs don't scale linearly with the number of devices.
- Vendor lock-in is the biggest hidden cost factor. Those without access to their data and configurations pay double when switching.
The informed customer pays for real engineering – not for artificial licenses.
Frequently Asked Questions
Is open-source software really free?▼
How can I tell if my IoT provider uses white-labeling?▼
What does it cost to run an IoT platform yourself?▼
What is vendor lock-in with IoT platforms?▼
How much can you save with infrastructure pricing?▼
What open-source platforms exist for IoT?▼
Written by
Timo Wevelsiep
Co-Founder & CEO
Co-Founder of merkaio. Building IoT infrastructure and managed operations for companies worldwide. Focused on LoRaWAN, open-source IoT platforms and scalable sensor deployments.
LinkedInReady to build your IoT project?
From idea to production - we guide your IoT journey.