Question 1

Wie funktioniert die wöchentliche Kündigung wirklich?

Accepted Answer

Beende jede Woche mit einer einzigen Nachricht. Keine Frist, kein Exit-Gespräch, kein Kleingedrucktes. Wir rechnen wöchentlich ab, du bist also maximal die laufende Woche gebunden.

Question 2

Was, wenn die Arbeit mich nicht überzeugt?

Accepted Answer

Es steht in deinem Vertrag: Sag es uns, und wir erstatten diese Woche. Keine Rückfragen, keine Rechnungen zum Streiten, keine Eskalationscalls. Einzige Regel: Erstattungen gelten für die letzte Woche.

Question 3

Warum trackt ihr keine Stunden?

Accepted Answer

Weil Stunden die falsche Metrik sind. Wenn wir auf abrechenbare Stunden optimieren, optimieren wir nicht auf dein Ergebnis. Der Deal ist einfacher: Jede Woche müssen wir die nächste verdienen. Wenn wir das nicht tun, zahlst du nicht. Wir können null Stunden oder sechzig investieren. Was zählt, ist, ob du umgehauen bist.

Question 4

Was bedeutet „Erwartungen losgelöst von der Realität“?

Accepted Answer

Wir arbeiten mit Operators, nicht mit Lottogewinnern. Wenn eine Anforderung Physik, Gesetz oder Drittanbieter-Systeme brechen würde, sagen wir das, und wenn wir uns nicht ausrichten können, gehen wir. Die Garantie ist gegenseitig: Du kannst uns jede Woche feuern; wir können uns auch selbst feuern.

Question 5

Welche Protokolle und Stacks unterstützt ihr?

Accepted Answer

LoRaWAN für Long-Range/Low-Power, MQTT für allgemeine Telemetrie, Zigbee für Short-Range-Mesh und Standard-HTTP/WebSockets für Geräte mit höherer Bandbreite. Wir wählen den Stack, der zu Power-Budget und Reichweite passt – nicht den, der uns vertraut ist.

Question 6

Könnt ihr Device-Fleet-Management im großen Maßstab?

Accepted Answer

Ja. Wir deployen auf AWS IoT Core, Azure IoT Hub, ThingsBoard oder self-hosted MQTT-Cluster, je nach Daten-Residency und Skalierung. Provisioning, Zertifikats-Rotation, OTA-Updates, Device Shadowing und flottenweite Telemetrie sind ab Tag eins erstklassige Themen – kein v2-Problem.

Question 7

Baut ihr die Firmware oder nur die Cloud-Seite?

Accepted Answer

Nein, Firmware bauen wir nicht. Wir schreiben die Decoder und Encoder für deine IoT-Geräte, bauen die Infrastruktur, die ihre Daten ingestiert, und kümmern uns um alles auf Applikations- und Monitoring-Seite. Wenn du die Firmware selbst geschrieben brauchst, vermitteln wir dich an einen Hardware-Partner. Aber die Hardware-zu-Dashboard-Pipeline oberhalb der Firmware-Schicht ist unser Spielfeld.

Question 8

Unsere Flotte hat Geräte von fünf verschiedenen Herstellern, die alle anders sprechen. Bekommt ihr das in den Griff?

Accepted Answer

Ja, das ist der Job. Wir haben Payloads dekodiert, bei denen die Doku falsch, lückenhaft oder im Widerspruch zur Firmware war. Wir schreiben Decoder pro Hersteller, normalisieren alles auf ein einheitliches Schema und bauen das Monitoring, das anschlägt, wenn ein Hersteller sein Payload-Format bei einem Firmware-Update still verändert. Multi-Vendor-Realität ist der Default in echten Deployments, nicht die Ausnahme.

Question 9

Was kostet ein IoT-Pilot end-to-end?

Accepted Answer

Single-Vendor-Pilot mit 10–50 Geräten, LoRaWAN-Gateway, Decoder und einem einfachen Dashboard: 18.000–35.000 €. Multi-Vendor-Pilot mit 100–500 Geräten, Fleet-Management, OTA und SLA-Dashboards: 40.000–90.000 €. Stadt-Rollouts (ab 5.000 Geräte) laufen als mehrstufige Programme – ab 150.000 € allein für Software, Hardware und Connectivity quotieren wir separat. Gateway-Kosten, LoRaWAN-Netzgebühren (Helium, TTN, Private) und Mobilfunk-Datenpläne weisen wir getrennt aus, damit dich nicht im dritten Monat eine Überraschung trifft.

Question 10

Wann solltet ihr KEIN LoRaWAN einsetzen?

Accepted Answer

Wenn Latenz zählt (LoRaWAN hat nur Uplink-Fenster, Zustellung im Sekunden- bis Minutenbereich). Wenn die Payload über ~50–200 Byte pro Nachricht hinausgeht. Wenn du Many-to-Many-Messaging brauchst. Wenn hohe Duty-Cycle-Telemetrie nötig ist (EU868-Duty-Cycle-Grenzen schränken die Sendehäufigkeit ein). In diesen Fällen: NB-IoT oder LTE-M für stromsparendes Mobilfunk, WLAN, wenn Strom kein Thema ist, Zigbee oder Bluetooth Mesh für Indoor-Mesh, und schlichtes MQTT-over-Cellular für Flotten mit mehr Bandbreite. Wir sagen dir, welches Funkprotokoll der Use Case wirklich braucht – nicht das, das gerade trendet.

IoT-Entwicklung

Worauf sind wir im IoT spezialisiert?

Was sind beispielhafte IoT-Anwendungsfälle?

Wie wir Software entwickeln

Discovery-Phase

Erste Iteration

Folge-Iterationen

Wartung

Weiterentwicklung / Übergabe

Beweise statt Versprechen

Was Kunden sagen

FAQs

Mehr aus KI & Frontier-Tech

Lern uns kennen