Wer ein IoT-Gerät entwickeln lassen möchte, steht vor dem ersten Meeting mit einem potenziellen Entwicklungspartner oft vor einer praktischen Frage: Was soll ich überhaupt mitbringen, und was wird von mir erwartet? Das erste Gespräch ist kein Test, aber es ist ein Indikator. Wie ein Partner auf unvollständige Anforderungen reagiert, welche Fragen er stellt und welche Risiken er von sich aus anspricht, sagt mehr über seine Erfahrung aus als jede Referenzliste. Wer ein Hardwareprodukt entwickeln will, sollte dieses Gespräch vorbereitet angehen.
Dieser Artikel richtet sich an CTOs, Produktmanager und Gründer, die eine IoT-Produktentwicklung konkret anstoßen wollen. Die folgenden Abschnitte zeigen, welche Fragen im ersten Meeting gestellt werden sollten, welche Antworten auf Erfahrung hindeuten und wo Teams typischerweise Fehler machen.
Was ein guter IoT-Partner im ersten Gespräch erwartet
Ein erfahrener IoT-Entwicklungspartner erwartet keine fertige Spezifikation. Er erwartet aber eine klare Problemdefinition: Was soll das Gerät tun, unter welchen Bedingungen, für welchen Markt, und welche Constraints gelten? Typische Eingangsparameter sind Zielstückkosten bei Serienvolumen (z.B. unter 15 EUR bei 5.000 Stück), grobe Formfaktorgrenzen (Platinengröße, Gehäusetyp), Betriebsumgebung (Temperaturbereich, IP-Schutzklasse) und ein realistischer Zeithorizont bis zum Markteintritt.
Was Entwicklungspartner regelmäßig unterschätzen, sehen: Teams, die mit einem groben Konzept ankommen, aber keine Aussage zu Zielkosten oder Zertifizierungsumfang machen können. Das verzögert die Angebotserstellung nicht nur, sondern signalisiert dem Partner, dass das Projekt intern noch nicht ausreichend priorisiert wurde. Ein häufiger Fehler ist es, das erste Gespräch als reine Informationsabfrage zu behandeln. Wer Elektronikentwicklung outsourcen will, sollte vorbereitet sein, eigene Entscheidungen zu treffen, nicht nur Fragen zu stellen.
Technische Kernfragen zur Konnektivität und Hardware
Konnektivität ist eine der kritischsten Architekturentscheidungen im frühen Stadium. Die Wahl zwischen BLE, Wi-Fi, NB-IoT, LTE-M oder LoRa bestimmt nicht nur die Antennenkonstruktion und RF-Zertifizierungstiefe, sondern direkt den Stromverbrauch und damit die Akkulaufzeit. BLE 5.x mit einem Connection-Interval von 1 Sekunde kann unter 10 µA im Durchschnitt liegen, Wi-Fi mit aktiver Übertragung zieht typischerweise 80–200 mA. Diese Differenz ist bei einem 300 mAh Akku der Unterschied zwischen 2 Jahren und 8 Stunden Laufzeit.
Folgende Fragen sollten im ersten Meeting explizit geklärt werden:
- Welche Datenrate wird tatsächlich benötigt, und in welchem Intervall?
- Ist eine Gateway-Infrastruktur vorhanden, oder muss das Gerät direkt ins Internet?
- Welche Funkzulassungen sind für die Zielmärkte erforderlich (CE, FCC, ISED)?
- Soll ein zertifiziertes Funkmodul verwendet werden, oder ist eine eigene RF-Schaltung geplant?
Die Entscheidung für ein zertifiziertes Modul (z.B. u-blox, Nordic, Murata) reduziert den Zertifizierungsaufwand erheblich, erhöht aber die Stückkosten um typischerweise 2–6 EUR bei Kleinserien. Eine eigene RF-Schaltung kann bei Volumen über 50.000 Stück wirtschaftlich sein, erfordert aber EMC-Testing mit Vorlaufzeiten von 6–10 Wochen. Wer diesen Trade-off nicht explizit adressiert, riskiert ein Redesign nach dem ersten EMC-Vortest.
Auf der Hardware-Seite gilt: Mikrocontrollerauswahl und Peripherieanbindung sollten nicht isoliert betrachtet werden. Ein STM32 mit ausreichend RAM für einen RTOS-Stack wie FreeRTOS oder Zephyr ist eine andere Entscheidung als ein Low-Power-MCU mit minimalem Footprint. Wer ein Hardware-Design mit Simulation in Auftrag gibt, sollte dem Partner frühzeitig mitteilen, ob sicherheitsrelevante Normen (IEC 62443, IEC 60601) eine Rolle spielen, da diese die Komponentenauswahl und Dokumentationspflichten direkt beeinflussen.
Fragen zu Zeitplan, Zertifizierung und Serienproduktion
Realistische Zeitplanung ist eine der häufigsten Konfliktquellen zwischen Auftraggebern und Entwicklungsdienstleistern. Ein erster Prototyp eines IoT-Geräts mit neuer RF-Komponente und angepasster Firmware braucht realistisch 10–16 Wochen bis zur funktionsfähigen Hardware, abhängig von Komponentenverfügbarkeit und Iterationstiefe. CE-Zertifizierung mit RED-Richtlinie dauert nach Einreichung 6–12 Wochen, FCC-Zulassung für den US-Markt 8–14 Wochen. Diese Zeiträume sind nicht verhandelbar.
Typische Fragen, die im ersten Meeting gestellt werden sollten:
- Wie viele Hardware-Iterationen sind im Angebot enthalten, und was kostet eine zusätzliche Revision?
- Wer übernimmt die Koordination mit dem Testlabor, und ist das im Scope?
- Welche Unterlagen werden für die Serienfertigung übergeben (Gerber, BOM, Bestückungsplan, Testspezifikation)?
- Ist der Partner in der Lage, einen EMS-Dienstleister zu koordinieren, oder endet der Scope beim Prototyp?
Ein häufig unterschätztes Risiko: Komponentenengpässe bei langen Lieferzeiten für spezifische ICs (aktuell 2026 betreffen Engpässe insbesondere bestimmte Power-Management-ICs und RF-Transceiver). Ein erfahrener Dienstleister plant alternative Footprints bereits im Schaltplan ein. Wer das nicht tut, riskiert einen Produktionsstopp bei der ersten Serienlieferung.
Wie man Anforderungen klar und präzise kommuniziert
Unvollständige Anforderungen sind der häufigste Grund für Scope-Creep und Budgetüberschreitungen bei der Hardwareentwicklung. Das Problem liegt selten in mangelndem Wissen, sondern in fehlender Struktur. Eine brauchbare Anforderungsdokumentation für ein IoT-Gerät umfasst mindestens: funktionale Anforderungen (was das Gerät tun muss), nicht-funktionale Anforderungen (Laufzeit, Latenz, Robustheit), Schnittstellenbeschreibungen (Sensoren, Aktoren, Cloud-Backend), und Randbedingungen (Zielkosten, Zertifizierungsumfang, Produktionsvolumen).
Anforderungen sollten messbar formuliert sein. „Lange Akkulaufzeit“ ist keine Anforderung. „Mindestens 12 Monate Betrieb mit einer CR2032 bei einem Übertragungsintervall von 15 Minuten und einer Nutzlast von 20 Byte“ ist eine Anforderung, auf deren Basis ein Entwickler eine Energiebilanz aufstellen kann. Wer ein Embedded-System-Prototyp bauen lassen will, sollte diesen Unterschied kennen, bevor er ein Angebot einholt.
Ein weiterer häufiger Fehler: Anforderungen werden als Lösungen formuliert. „Wir brauchen einen STM32L4“ ist eine Lösungsvorgabe, keine Anforderung. Sie schränkt den Lösungsraum ein, ohne den eigentlichen Bedarf zu kommunizieren. Ein erfahrener Partner wird diese Vorgabe hinterfragen und prüfen, ob sie mit den tatsächlichen Systemanforderungen übereinstimmt.
Woran man einen erfahrenen IoT-Entwicklungspartner erkennt
Erfahrung zeigt sich nicht im Portfolio, sondern im Gesprächsverhalten. Ein erfahrener IoT-Dienstleister stellt im ersten Gespräch mehr Fragen, als er Antworten gibt. Er fragt nach Zertifizierungsumfang, Zielmarkt, Skalierungsplan und bekannten Risiken, bevor er über Technologieauswahl spricht. Er nennt Risiken proaktiv, nicht auf Nachfrage.
Konkrete Indikatoren für Erfahrung:
- Der Partner benennt spezifische Risiken für das beschriebene Projekt, nicht generische Herausforderungen.
- Er kann Zeitrahmen und Kostenbereiche für Zertifizierungsschritte aus dem Gedächtnis nennen.
- Er spricht über DFM (Design for Manufacturability) und EMC bereits in der Konzeptphase.
- Er unterscheidet zwischen dem, was er selbst entwickelt, und dem, was er koordiniert oder outgesourct.
Eine häufige Fehleinschätzung: Viele Teams wählen einen Partner primär nach dem niedrigsten Angebotspreis. Bei der Beauftragung der Firmware-Entwicklung gilt jedoch, dass ein günstigeres Angebot oft bedeutet, dass Iterationsrunden, Zertifizierungsunterstützung oder Produktionsübergabe nicht im Scope enthalten sind. Die Gesamtkosten, um ein IoT-Produkt zur Serienreife zu bringen, liegen mit einem unerfahrenen Partner regelmäßig 30–60% über dem ursprünglichen Angebot. Wer mehr über unseren Ansatz erfahren möchte, findet dort konkrete Einblicke in unsere Arbeitsweise.
Ein letzter Prüfpunkt: Wie geht der Partner mit Unklarheiten um? Wer sofort ein fixes Angebot macht, ohne Rückfragen zu stellen, hat entweder sehr viel Erfahrung mit exakt diesem Gerätetyp, oder er hat die Komplexität nicht erfasst. In den meisten Fällen ist es Letzteres.
Wie wir bei Oxeltech IoT-Projekte von Anfang an strukturieren
Wir begleiten IoT-Projekte vom ersten technischen Briefing bis zur Serienproduktion, mit klarer Verantwortung in jeder Phase. Das umfasst konkret:
- Technische Analyse der Anforderungen mit expliziter Bewertung von Zertifizierungsrisiken und Komponentenverfügbarkeit
- Hardware-Design und Schaltungsentwicklung mit integrierter EMC-Strategie und DFM-Optimierung
- Firmware-Entwicklung auf Basis von FreeRTOS oder Zephyr, abgestimmt auf die gewählte MCU-Architektur (ARM Cortex, STM32, NXP)
- Integration drahtloser Kommunikationstechnologien wie BLE, Wi-Fi, NB-IoT, LTE-M und LoRa
- Unterstützung bei CE-, FCC- und weiteren Zulassungsverfahren sowie Übergabe serienreifer Produktionsdokumentation
Wir haben über 20 Hardwareprodukte erfolgreich zur Serienreife gebracht, darunter IoT-Geräte für Medizintechnik, industrielle Automatisierung und Consumer Electronics. Wer ein konkretes Projekt hat und wissen möchte, welche Schritte als Nächstes sinnvoll sind, kann direkt über unser Kontaktformular ein erstes Gespräch anfragen. Kein generisches Erstgespräch, sondern eine technische Einschätzung auf Basis des beschriebenen Projekts.
