Die IoT-Plattform-Falle: Warum Unternehmen Tausende Euro für kostenlose Software verbrennen

Der IoT-Markt hat ein offenes Geheimnis. Eines, über das viele Dienstleister ungern sprechen, weil es ihr Geschäftsmodell gefährdet.

Wer sich nach einer IoT-Plattform umsieht, wird mit Hochglanz-Broschüren und proprietären Markennamen überhäuft. Doch wer unter die Haube schaut, findet dort oft nur Open-Source-Technologie – häufig ThingsBoard, Grafana oder ChirpStack – die neu verpackt und teuer weiterverkauft wird.

Das Ergebnis: Unternehmen zahlen Lizenzgebühren für Software, die eigentlich frei verfügbar ist. Und sie zahlen meist pro Gerät – ein Preismodell, das bei Skalierung schnell zum Problem wird.

Dieser Artikel analysiert das Phänomen, rechnet konkret vor, was es kostet, und zeigt Alternativen auf.

Inhaltsverzeichnis

• Das White-Label-Geschäftsmodell: So funktioniert die Plattform-Falle
  • Die Open-Source-Basis, die kaum jemand kennt
  • Woran erkennt man White-Label-Anbieter?
• Die Kostenanalyse: Was das Pro-Gerät-Modell wirklich kostet
  • Modell A: Pro-Gerät-SaaS (White-Label oder proprietär)
  • Modell B: Infrastructure-Pricing (Managed Open Source)
  • Der Unterschied: 10.800 € pro Jahr – und die Schere öffnet sich
• Warum Open Source nicht "kostenlos" bedeutet
  • 1. Architektur & Aufbau
  • 2. Laufender Betrieb & Sicherheit
  • 3. Individuelle Anpassung
• Der versteckte Kostenfaktor: Vendor Lock-in
  • Wie Vendor Lock-in funktioniert
  • Wie die Alternative aussieht
• Checkliste: So schützen Sie sich vor der Plattform-Falle
• Das alternative Modell: Zahlen für Engineering statt für Lizenzen
• Fazit: Wissen, wofür man zahlt

Das White-Label-Geschäftsmodell: So funktioniert die Plattform-Falle

Das Prinzip ist einfach: Ein Dienstleister nimmt eine kostenlose Open-Source-Plattform wie ThingsBoard, installiert sie auf eigenen Servern, versieht sie mit dem eigenen Logo und verkauft den Zugang als „eigene IoT-Plattform" – inklusive monatlicher Pro-Gerät-Lizenzgebühren.

Technisch ist das völlig legal. Open-Source-Lizenzen wie Apache 2.0 (ThingsBoard) oder MIT (ChirpStack) erlauben die kommerzielle Nutzung und das Rebranding ausdrücklich.

Aber: Der Kunde weiß in vielen Fällen nicht, dass die Software im Kern kostenlos ist. Und er zahlt pro Gerät für etwas, das auf dem Server des Anbieters keine zusätzlichen Kosten verursacht.

Die Open-Source-Basis, die kaum jemand kennt

Die meisten kommerziellen IoT-Plattformen im Mittelstandsbereich basieren auf einer Handvoll Open-Source-Projekte:

Laut der Eclipse Foundation IoT Survey nutzen über 60% der professionellen IoT-Entwickler Open-Source-Komponenten in ihren Projekten. Das ist kein Nischenphänomen – es ist der Industriestandard.

Woran erkennt man White-Label-Anbieter?

Nicht jeder Anbieter, der Open Source nutzt, betreibt White-Labeling. Entscheidend ist die Transparenz. Hier eine Checkliste:

• Login-Seite prüfen: Ähnelt die Oberfläche auffällig ThingsBoard oder Grafana – nur mit anderem Logo?
• Technologie-Stack erfragen: Seriöse Anbieter benennen ihren Stack offen. Wer ausweicht, hat oft etwas zu verbergen.
• Datenexport testen: Lässt sich ein vollständiger Datenbank-Dump herunterladen? Oder sind die Daten in einem proprietären Format gefangen?
• API-Dokumentation prüfen: Verweist die API-Doku auf ThingsBoard- oder ChirpStack-Endpunkte?
• Vertragsbedingungen lesen: Gibt es Klauseln, die den Wechsel zu einem anderen Anbieter erschweren?

Wenn drei oder mehr dieser Punkte zutreffen, handelt es sich mit hoher Wahrscheinlichkeit um ein White-Label-Produkt.

Die Kostenanalyse: Was das Pro-Gerät-Modell wirklich kostet

Um das Problem greifbar zu machen, hilft eine konkrete Rechnung. Die folgenden Zahlen basieren auf marktüblichen Preisen, die sich aus öffentlich einsehbaren Pricing-Seiten verschiedener IoT-Plattformen ableiten lassen.

Szenario: Ein mittelständisches Unternehmen möchte 500 Sensoren betreiben – etwa für Gebäudemonitoring, Kühlkettenüberwachung oder Smart-Office-Anwendungen.

Modell A: Pro-Gerät-SaaS (White-Label oder proprietär)

Die Preise variieren je nach Anbieter. Typische Marktpreise für IoT-SaaS liegen zwischen 1 und 5 Euro pro Gerät und Monat. Für die Berechnung wird ein konservativer Mittelwert von 3 Euro angesetzt.

Das zentrale Problem dieses Modells: Die Kosten skalieren linear mit der Geräteanzahl. Jeder neue Sensor kostet exakt gleich viel – unabhängig davon, ob der Server bereits ausgelastet ist oder nicht.

Modell B: Infrastructure-Pricing (Managed Open Source)

Beim Infrastructure-Pricing zahlt der Kunde nicht pro Gerät, sondern für die tatsächliche Infrastruktur und den Betrieb. 500 IoT-Sensoren erzeugen vergleichsweise wenig Last – ein einzelner dedizierter Server reicht in den meisten Fällen aus.

Der Unterschied: 10.800 € pro Jahr – und die Schere öffnet sich

Bei 500 Geräten beträgt die Differenz 60%. Doch der eigentliche Effekt zeigt sich bei Skalierung: Bei 2.000 Geräten zahlt das Unternehmen im SaaS-Modell 72.000 € – im Infrastructure-Modell nur rund 9.600 €. Das ist eine Differenz von über 85%.

Der Grund ist einfach: Serverkosten steigen logarithmisch, nicht linear. 2.000 Sensoren brauchen nicht viermal so viel Infrastruktur wie 500 – sie brauchen vielleicht 30% mehr.

Warum Open Source nicht "kostenlos" bedeutet

An dieser Stelle ist ein wichtiger Einwand berechtigt: Wenn die Software frei ist, warum kostet der Betrieb dann überhaupt etwas?

Die Antwort kennt jeder, der schon einmal ein Haus gebaut hat. Ziegelsteine sind günstig. Der Architekt und die Handwerker sind es nicht.

Eine IoT-Plattform aus Open-Source-Komponenten aufzubauen und sicher zu betreiben, erfordert drei Disziplinen:

1. Architektur & Aufbau

Open-Source-Software zu installieren ist der einfache Teil. Die eigentliche Arbeit steckt in den Entscheidungen:

• Welche Datenbank passt zum Use Case? PostgreSQL für relationale Daten, TimescaleDB für Zeitreihen, InfluxDB für High-Frequency-Sensordaten?
• Wie wird die Kommunikation zwischen Gateways und Server abgesichert? VPN-Tunnel, mTLS, Zertifikatsmanagement?
• Wie sieht die Failover-Strategie aus, wenn der Primary-Server ausfällt?
• Wie werden die einzelnen Komponenten (MQTT Broker, Application Server, Datenbank) sinnvoll orchestriert?

Diese Entscheidungen bestimmen, ob eine Plattform nach sechs Monaten noch stabil läuft oder unter der Last zusammenbricht.

2. Laufender Betrieb & Sicherheit

Software altert. Jeden Monat werden neue Sicherheitslücken in Abhängigkeiten entdeckt. Server-Hardware fällt aus. Festplatten laufen voll. TLS-Zertifikate laufen ab.

Ein professioneller Betrieb umfasst:

• Security Patching: Sicherheits-Updates zeitnah einspielen, bevor bekannte Schwachstellen ausgenutzt werden
• 24/7 Monitoring: Heartbeat-Checks, Ressourcen-Monitoring, Alerting bei Anomalien
• Backup & Disaster Recovery: Automatisierte Backups, getestete Restore-Prozeduren, georedundante Speicherung
• Kapazitätsplanung: Rechtzeitiges Hochskalieren, bevor die Last kritisch wird

Diese Arbeit fällt an – unabhängig davon, ob sie intern erledigt wird oder an einen spezialisierten Betreiber ausgelagert ist. Die Frage ist nur, ob man dafür eine pauschale Operations-Gebühr zahlt oder eine künstliche Pro-Gerät-Lizenz.

3. Individuelle Anpassung

Standardplattformen stoßen in der Praxis schnell an Grenzen. Typische Anpassungen, die fast jedes Projekt braucht:

• Payload Decoder: Sensordaten kommen als binäre Bytes an und müssen in lesbare Werte umgewandelt werden – für jeden Sensortyp individuell
• System-Integration: Daten müssen nicht nur auf Dashboards landen, sondern in bestehende ERP-, SAP- oder CRM-Systeme fließen
• Custom Dashboards: Die Standard-Oberfläche reicht selten aus – individuelle Visualisierungen für verschiedene Nutzergruppen sind die Regel

Der versteckte Kostenfaktor: Vendor Lock-in

Der vielleicht größte Kostenfaktor bei proprietären IoT-Plattformen ist unsichtbar: der Vendor Lock-in.

Laut einer Studie von Eseye geben 94% der befragten Unternehmen an, dass sie bei IoT-Projekten mit unerwarteten Herausforderungen kämpfen. Einer der häufigsten Gründe: die Abhängigkeit vom Plattform-Anbieter.

Wie Vendor Lock-in funktioniert

Das Muster ist immer ähnlich:

1. Kein Datenbank-Zugriff: Der Kunde hat keinen direkten Zugang zur Datenbank. Ein Export ist nur in proprietären Formaten möglich – oder gar nicht.
2. Proprietäre APIs: Die Schnittstellen folgen keinem Standard. Eine Migration bedeutet, alle Integrationen neu zu bauen.
3. Vertragliche Bindung: Mindestlaufzeiten von 12–36 Monaten, kombiniert mit automatischer Verlängerung.
4. Datenverlust bei Kündigung: Historische Sensordaten sind nach der Kündigung verloren, weil kein vollständiger Export möglich ist.

Wie die Alternative aussieht

Bei einem Open-Source-basierten Setup mit einem transparenten Betreiber gilt:

• Die Datenbank gehört dem Kunden. Ein vollständiger Dump ist jederzeit möglich.
• Die Konfiguration ist dokumentiert und exportierbar.
• Der Stack basiert auf offenen Standards – ein Wechsel des Betreibers erfordert keine Migration der Software.
• Es gibt keinen Lock-in: Der Kunde bleibt, weil der Service stimmt, nicht weil er gefangen ist.

Checkliste: So schützen Sie sich vor der Plattform-Falle

Bevor Sie sich für eine IoT-Plattform entscheiden, stellen Sie diese sieben Fragen:

1. „Auf welchem Technologie-Stack basiert Ihre Plattform?" – Seriöse Anbieter antworten offen. Ausweichende Antworten sind ein Warnsignal.

2. „Kann ich einen vollständigen Datenbank-Dump meiner Daten erhalten?" – Wenn nein: Vendor Lock-in.

3. „Was passiert mit meinen Daten, wenn ich kündige?" – Die einzig akzeptable Antwort: vollständiger Export in einem Standardformat.

4. „Wie setzt sich der Preis zusammen?" – Pro-Gerät-Preise ohne transparente Aufschlüsselung deuten auf Margenmaximierung hin.

5. „Welche Open-Source-Komponenten nutzen Sie?" – Eine ehrliche Antwort schafft Vertrauen. Schweigen schafft Abhängigkeit.

6. „Kann ich die Plattform auch selbst betreiben, wenn ich möchte?" – Bei Open-Source-basierten Setups: ja. Bei proprietären Plattformen: nein.

7. „Gibt es eine Mindestvertragslaufzeit?" – Flexibilität zeigt, dass der Anbieter von der Qualität seines Service überzeugt ist.

Das alternative Modell: Zahlen für Engineering statt für Lizenzen

Die Lösung für das White-Label-Problem ist nicht, alles selbst zu machen. Die meisten Unternehmen haben weder die Zeit noch das Personal, einen IoT-Stack selbst zu betreiben.

Die Lösung ist ein anderes Preismodell: Infrastructure-Pricing. Statt künstlicher Pro-Gerät-Lizenzen zahlt der Kunde für das, was tatsächlich Geld kostet:

• Serverinfrastruktur: Dedizierte Server, Backups, Traffic
• Engineering: Architektur, Aufbau, individuelle Anpassung
• Operations: Laufender Betrieb, Monitoring, Security

Das ist der Ansatz, den unter anderem Anbieter wie merkaio verfolgen. Der entscheidende Unterschied: Die Kosten steigen nicht linear mit der Geräteanzahl, sondern mit der tatsächlichen Infrastruktur-Nutzung.

Fazit: Wissen, wofür man zahlt

Die IoT-Plattform-Falle ist kein böser Wille – es ist ein Geschäftsmodell, das von der Intransparenz lebt. Wer den Technologie-Stack hinter dem Hochglanz-Marketing versteht, kann fundierte Entscheidungen treffen.

Die drei wichtigsten Takeaways:

1. Viele IoT-Plattformen basieren auf kostenloser Open-Source-Software. Das ist kein Problem – aber es sollte transparent kommuniziert werden.
2. Pro-Gerät-Lizenzgebühren haben keine technische Grundlage. Die Serverkosten steigen nicht linear mit der Geräteanzahl.
3. Vendor Lock-in ist der größte versteckte Kostenfaktor. Wer keinen Zugang zu seinen Daten und Konfigurationen hat, zahlt beim Wechsel doppelt.

Der informierte Kunde zahlt für echtes Engineering – nicht für künstliche Lizenzen.