Fallstudie · Mikromobilität · Mobile & IoT
Wie wir eine vollständige E-Scooter-Verleihplattform entwickelt haben — native iOS- und Android-Fahrer-Apps, eine IoT-Telematik-Steuerungsebene, Geofencing und ein Betriebs-Dashboard — für einen Mikromobilitäts-Betreiber, der die Scooter und die städtischen Genehmigungen besaß, aber die Software benötigte. Das Produkt bedient heute 5.000+ zufriedene Nutzer in den USA und der EU.
Der Kunde war ein Mikromobilitäts-Betreiber mit echten Vermögenswerten — einer Flotte von E-Scootern und den städtischen Genehmigungen zum Betrieb —, aber ohne interne Kompetenz für die komplexe Telematik und das mobile Engineering, von denen ein Scooter-Sharing-Geschäft tatsächlich abhängt. Die Hardware zu besitzen, ist nur die halbe Miete; die andere Hälfte ist die Software, die einen geparkten Scooter in einen auffindbaren, entsperrbaren, nachverfolgbaren und abrechenbaren Vermögenswert für Fahrer in den Vereinigten Staaten und der Europäischen Union verwandelt. Die Aufgabe war eine vollständige IT-Plattform: native Fahrer-Apps für iOS und Android, ein Admin-Dashboard zur Verwaltung von Flotte, Preisen und Betriebszonen sowie — der Teil, der über Erfolg oder Misserfolg eines Mikromobilitäts-Produkts entscheidet — eine zuverlässige Kommunikationsschicht zwischen der App und den Scooter-Controllern für ferngesteuertes Sperren, Entsperren und Geschwindigkeitskontrolle. Wir haben sie mit YuSMP Group von Grund auf entwickelt, beginnend mit einer praktischen Hardware-Analyse eines physischen Scooter-Prototyps statt allein anhand von Hersteller-Datenblättern, und ein Produkt geliefert, das nun 5.000+ Nutzer im App Store und bei Google Play unterstützt.
Ein Überblick über das, was die Scooter-Sharing-Entwicklung über iOS, Android und eine IoT-Telematik-Steuerungsebene hinweg geliefert hat.
Die architektonische Entscheidung, die eine Mikromobilitäts-Entwicklung dominiert, ist die Frage, wie das Telefon des Fahrers den Scooter erreicht. Wir haben bewusst ein server-vermitteltes Telematik-Modell gewählt — die App steuert den Controller nie direkt — anstelle eines direkten Steuerungspfads von Gerät zu Telefon. Wenn ein Fahrer einen QR-Code scannt, sendet die App eine Absicht an das Backend; das Backend authentifiziert die Fahrt, prüft Wallet-Guthaben und Zonenregeln und leitet dann einen signierten Befehl über den Mobilfunk-Telematik-Kanal an den Controller des Scooters weiter. Der Controller bestätigt, und erst dann wechselt die App den Fahrtstatus. Diese Indirektion macht die Plattform sicher abrechenbar: Jede Entsperr-, Sperr- und Geofence-Aktion ist ein serverseitiges Ereignis mit Audit-Trail, keine Fire-and-Forget-Bluetooth-Nachricht, die gefälscht oder ohne Aufzeichnung verloren gehen kann. Dieselbe Disziplin der Steuerungsebene fließt in unsere Praxis der individuellen Softwareentwicklung über Mobilitätsprodukte hinweg ein.
Wir haben das Anfrage-Antwort-Protokoll des Controllers auf die schwierige Weise abgebildet: Eine funktionsübergreifende Leitung — ein Business-Analyst, ein Systemarchitekt und ein Backend-Director — arbeitete mit einem physischen Scooter-Prototyp, nicht nur mit einem Controller-Datenblatt, und erstellte detaillierte Sequenzdiagramme, die jede Fahrer-Interaktion abdecken. Der Vergleich unten fasst zusammen, warum sich das Relay-Modell für eine Flotte durchsetzte, die US- und EU-Stadtregulierer zufriedenstellen muss.
| Dimension | Server-Relay (diese Entwicklung) | Direktes Bluetooth | White-Label-SDK |
|---|---|---|---|
| Befehls-Audit-Trail | Jede Aktion ist ein protokolliertes Server-Ereignis | Nur lokal — schwer mit der Abrechnung abzustimmen | Anbieter-kontrolliert, oft undurchsichtig |
| Reichweite zum Scooter | Überall mit Mobilfunk — keine Nähe erforderlich | Telefon muss neben dem Scooter sein | Variiert je nach Anbieter |
| Geofence-Durchsetzung | Server sendet bei Grenzüberschreitung Geschwindigkeit/Stopp | Erfordert App im Vordergrund & Nähe | Mitgeliefert, aber nicht anpassbar |
| Ausfallsicherheit bei Signalabbruch | Befehlswarteschlange + Bestätigungsprotokoll | Stiller Ausfall — Fahrer kann falsch berechnet werden | Abhängig von der SDK-Implementierung |
| Abrechnungsintegrität | Berechnung nur bei bestätigtem Entsperren/Sperren | Schwer zu garantieren | Anbieter-definiert |
| Flotten-Beobachtbarkeit | Zentrales Admin-Dashboard, Echtzeitkarte | Keine zentrale Ansicht | Anbieter-Portal — eingeschränkt |
| Anpassbarkeit & Eigentum | Vollständiger Quellcode — Eigentum des Betreibers | Nur app-seitig | Lizenziert, Lock-in-Risiko |
Plattform-Referenzen: Apple Core Location-Dokumentation, Android Location Services-Referenz.
Der iOS-Client ist in Swift gebaut, mit einem Ein-Bildschirm-zur-Fahrt-Flow: einer Live-Karte naher Scooter, einem QR-Scan-Einstiegspunkt und einer Scooter-Detailkarte, die Akku, geschätzte Reichweite, Startgebühr und Minutenpreis anzeigt, bevor der Fahrer sich festlegt. Die Kartenebene verwendet Apples Core Location für die Position des Fahrers und streamt die GPS-Positionen der Scooter aus dem Backend, sodass die Auswahl die echte Flotte widerspiegelt, ohne durch eine langsame Netzwerk-Roundtrip blockiert zu werden. Der QR-Entsperr-Pfad ist der Punkt, an dem die meisten Fahrer ihren ersten Eindruck vom Produkt gewinnen, und wo wir überproportional viel Engineering-Aufwand investiert haben: scannen, Wallet- und Zonenberechtigung validieren, die Entsperr-Absicht senden und in dem Moment, in dem der Controller bestätigt, einen klaren „Fahrt gestartet"-Status anzeigen.
Da die Controller-Bestätigung bei schwachem Mobilfunk verzögert eintreffen kann, ist der iOS-Flow um explizite Fahrtstatus herum aufgebaut — Leerlauf, Entsperren, Fahrt gestartet, Beenden — statt um eine optimistische Oberfläche, die vorgibt, der Scooter sei entsperrt, bevor dies bestätigt wurde. Ein Fahrer wird nie in eine abrechenbare Fahrt überführt, bevor das Backend eine bestätigte Entsperrung vom Controller hat — die mit Abstand wichtigste Korrektheitseigenschaft in einer Scooter-App. Die End-to-End-iOS-Oberfläche wird im Rahmen unserer Praxis der Mobile App-Entwicklung geliefert.
Der Android-Client ist in Kotlin geschrieben und führt die aktive Fahrt in einem Foreground Service aus. Der Foreground Service ist zwingend erforderlich: Auf den Gerätefamilien von Samsung, Xiaomi, OnePlus und Pixel beenden aggressive Akku-Optimierer reine Hintergrundprozesse innerhalb von Minuten, und eine Scooter-Fahrt kann es sich nicht leisten, mitten in der Fahrt ihre Verbindung zur Fahrtmessungs- und Geofencing-Logik zu verlieren. Der Service hält die Fahrt-Sitzung am Leben, streamt die GPS-Position des Fahrers zur Flottenverfolgung und für Geofence-Prüfungen zurück ans Backend und aktualisiert die Live-Distanz, die verstrichene Zeit und den laufenden Preis auf dem Bildschirm, während er eine Sperrsteuerung während der Fahrt bereitstellt.
Die Geofencing-Logik ist das regulatorische Herz der Plattform. Während sich der Fahrer bewegt, vergleicht das Backend die GPS-Position des Scooters mit den im Admin-Dashboard konfigurierten Betriebszonen-Polygonen. Das Überschreiten in eine Langsamfahrzone sendet einen Geschwindigkeitsbegrenzungsbefehl an den Controller; das Überschreiten einer harten Grenze stoppt den Scooter; das Erreichen einer Parkzone ermöglicht das Fahrtende. Diese serverseitige Durchsetzung ist es, die einer Stadt in den USA oder der EU die Genehmigung der Flotte überhaupt erst ermöglicht, und sie läuft auf derselben Steuerungsebene, die das in den Android Location Services beschriebene Standort-Streaming verarbeitet. Dasselbe Engineering-Team führt iOS und Android im Gleichschritt als Teil unserer Praxis des iOS- und Android-Engineerings.
Das In-App-Wallet lässt einen Fahrer ein Guthaben vorladen und ein Ausgabenlimit festlegen, sodass sich ein einziger abonnementartiger Zahlungsstatus sauber über Fahrten hinweg auflöst, ohne bei jeder Fahrt eine Karte neu autorisieren zu müssen. Darunter sitzt die Telematik-Steuerungsebene — ein Backend, das die Flottenkarte, die Betriebszonen-Polygone, die Befehlswarteschlange pro Scooter und das Abrechnungsbuch hält. Die Befehlswarteschlange ist die ausfallsichere Schicht: Wenn ein Sperr- oder Entsperrbefehl gesendet wird und der Controller nicht bestätigt — abgebrochener Mobilfunk, leerer Akku, Controller-Neustart —, wiederholt die Warteschlange den Versuch mit Backoff und gleicht den Fahrtstatus ab, sodass einem Fahrer nie ein Scooter berechnet wird, der tatsächlich nicht reagiert hat. Bezeichner sind eng gefasst: Der Standort-Stream des Fahrers speist Geofence-Prüfungen und die Flottenverfolgung und wird unter ausdrücklicher, regionsbewusster Einwilligung als Fahrthistorie aufbewahrt, statt als kontinuierliches Tracking-Profil ausgewertet zu werden.
Der Umgang mit Daten ist darauf ausgelegt, mit den DSGVO-Verpflichtungen für Fahrer in der Europäischen Union und den CCPA / CPRA-Verpflichtungen für Fahrer in Kalifornien und den weiteren Vereinigten Staaten in Einklang zu stehen — Standortdaten werden zum betrieblichen Zweck der Fahrt und des Geofencings erhoben, klar offengelegt und nicht zweckentfremdet. Die mit React entwickelte Flotten-Betriebskonsole gibt Mitarbeitern eine Echtzeitkarte, einen Zonen-Editor, Preissteuerungen und den Telematik-Zustand je Scooter.
Compliance-Haltung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Eine fünfphasige Entwicklung, die die Plattform von einem physischen Scooter-Prototyp bis zur Produktion über iOS, Android und eine IoT-Telematik-Steuerungsebene führte.
Praktische Analyse eines physischen Scooter-Prototyps, Abbildung des Controller-Anfrage-Antwort-Protokolls, Sequenzdiagramme der Fahrer-Interaktion, US- + EU-Stadtgenehmigungs- und Geofencing-Anforderungen, Abbildung der DSGVO- + CCPA-Haltung.
Laravel-Backend-Grundgerüst, server-vermitteltes Befehlsmodell, ausfallsichere Befehlswarteschlange mit Bestätigung und Backoff, Flottenkarte, Betriebszonen-Polygonmodell, Abrechnungsbuch.
Swift-iOS-Fahrer-App und Kotlin-Android-Fahrer-App — Live-GPS-Karte, QR-Entsperrung, Fahrtstatus, Foreground-Service-Fahrtmessung, In-App-Wallet und Ausgabenlimit.
Geofence-Durchsetzung mit automatischer Geschwindigkeitsbegrenzung und Stoppzonen, Ausfallsicherheits-QA bei Signalabbruch und niedrigem Akkustand, Tests der Abrechnungsintegrität, Admin-React-Betriebs-Dashboard.
App-Store- + Google-Play-Einreichung in US- und EU-Storefronts, Flotten-Rollout, Echtzeit-Flotten-Beobachtbarkeit und Fahrt-Telemetrie, die in die Preis- und Zonenabstimmung einfließt.
Ein Scooter-Sharing-Geschäft steht und fällt mit seiner Betriebskonsole, daher wurde das React-Admin-Dashboard als erstklassiges Liefergut behandelt und nicht als nachträglicher Gedanke. Mitarbeiter erhalten eine Echtzeitkarte jedes Scooters mit seinem Akkustand, Sperrstatus und Telematik-Zustand und können Einsätze im Feld für den Tausch bei niedrigem Akkustand oder für Umpositionierungen disponieren. Die Preisgestaltung ist vollständig konfigurierbar — Startgebühr, Minutenrate sowie tageszeit- oder zonenbasierte Anpassungen — ohne ein Code-Release, denn Mikromobilitäts-Preise werden ständig gegen Nachfrage und Stadtvereinbarungen abgestimmt. Der Zonen-Editor ist das regulatorische Werkzeug: Mitarbeiter zeichnen und bearbeiten Fahrverbotszonen, Langsamfahrzonen und Parkbereiche als Kartenpolygone, und diese Polygone fließen direkt in die Geofencing-Engine ein, die sie in Echtzeit auf den Scootern durchsetzt. Da Betriebszonen, Preise und Flottenbestand alle hinter derselben Steuerungsebene liegen, kann ein Betreiber eine neue Stadt in den USA oder der EU als Konfigurationsaufgabe aufnehmen — neue Polygone, neue Preise, neue Genehmigungsparameter — statt als Code-Fork, was genau der Hebel ist, den eine Softwareplattform einem Hardware-Geschäft geben soll.
Die Plattform startete im Apple App Store und bei Google Play mit aktiven Storefronts in den Vereinigten Staaten und der Europäischen Union und bedient nun 5.000+ Nutzer mit einer einzigen englischsprachigen Build je Plattform. Mikromobilität ist eine der lokal am stärksten regulierten Softwarekategorien überhaupt, daher verlagert die Architektur stadtspezifische Regeln in die Konfiguration: Jede Betriebszone, Geschwindigkeitsbegrenzung und Parkbeschränkung ist Daten im Admin-Dashboard, kein Codebestand pro Stadt. Einwilligungs-Flows sind auf der Client-Ebene regionsbewusst — Fahrer in der EU und im EWR erhalten einen DSGVO-artigen granularen Einwilligungsbildschirm, der die Verarbeitung von Fahrtstandorten abdeckt, und Fahrer in Kalifornien erhalten im selben Flow eine CCPA-artige „Do Not Sell or Share My Personal Information"-Offenlegung. Die Datenverarbeitungspraktiken sind mit der DSGVO für europäische Nutzer und mit dem Flickenteppich der US-Bundesstaaten-Datenschutzgesetze in Einklang gebracht — CCPA/CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA —, wobei Fahrtstandortdaten auf den betrieblichen Zweck der Fahrt und des Geofencings beschränkt sind.
Auf europäischer Seite ist die Plattform so strukturiert, dass sie den Rollout in Städten in den Niederlanden, Deutschland, Frankreich, Schweden und Irland unterstützt, wo Genehmigungen für geteilte Scooter von nachweisbarem Geofencing und Geschwindigkeitskontrolle abhängen — genau die Fähigkeit, um die herum die Steuerungsebene gebaut wurde. Das Engineering-Team hinter der Entwicklung arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie von Store-Reviews und die Incident-Reaktion — das Zeitfenster, das einem US-orientierten Produktteam und einem EU-Engineering-Team jeden Tag vier Stunden Live-Überlappung verschafft. Sowohl die Altersfreigabe im App Store als auch die Inhaltsbewertung bei Google Play wurden für eine Transport-App kalibriert, die Live-Standortdaten verarbeitet.
Die aktive Roadmap der individuellen Softwareentwicklung umfasst dynamische, nachfragebasierte Preisgestaltung, eine Schaden- und Foto-Prüfung am Fahrtende, eine Belohnungsstufe für Fahrer und tiefergehende Flotten-Zustandsanalysen, die Scooter markieren, die auf Wartung zusteuern, bevor sie im Feld ausfallen. Die Infrastrukturpläne umfassen eine weitere Automatisierung der Telematik-Befehls-Pipeline und eine gehärtete, beobachtbare Steuerungsebene, die in die Cloud & DevOps-Roadmap eingebettet ist, sodass der Betreiber US- und EU-Städte hinzufügen kann, ohne die Architektur neu zu gestalten. Die Plattform bedient den weiteren Bereich Logistik und Mobilität, in dem dieselben GPS-Tracking- und IoT-Steuerungsmuster über geteilte Fahrzeuge und Last-Mile-Flotten hinweg wiederkehren.
Wenn Sie ein E-Scooter- oder Shared-Mobility-Produkt planen, bei dem die Software eine Hardware-Flotte in einen abrechenbaren, regulierungsfreundlichen Dienst für Zielgruppen in den USA und der EU verwandeln muss, haben wir diesen Stack end-to-end ausgeliefert — Fahrer-Apps, Telematik-Steuerungsebene, Geofencing und Betriebs-Dashboard — und können den Entwicklungszeitrahmen erheblich verkürzen. Der Fall ist unter yusmpgroup.ru dokumentiert, und das Engineering-Team dahinter sitzt innerhalb von YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs und mit dedizierten Entwicklerteams für die laufende Lieferung — mit einem MEZ-Arbeitstag und einem garantierten Zeitfenster der Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Reaktion.
Ein Mikromobilitäts-MVP mit iOS- und Android-Fahrer-Apps, einer GPS-Scooter-Karte, QR-Entsperrung, Fahrtmessung und einem einfachen Admin-Dashboard kostet typischerweise 140.000–280.000 $. Eine vollständige IoT-Telematik-Steuerungsebene, Geofencing mit automatischer Geschwindigkeitsbegrenzung, ausfallsicheres Sperr-Handling, ein In-App-Wallet und dynamische Preisgestaltung bringen eine komplette Plattform auf 320.000–700.000 $. Die dominierenden Kostentreiber sind die Kommunikationsschicht zum Scooter-Controller, die Geofencing-Engine und das Betriebs-Dashboard für Flotten-, Preis- und Zonenverwaltung.
Die Fahrer-App kommuniziert nie direkt mit dem Scooter. Ein QR-Scan oder ein Tippen sendet eine Absicht an das Backend, das einen signierten Sperr- oder Entsperrbefehl über den Telematik-Kanal an den Controller des Scooters weiterleitet. Der Controller bestätigt, und die App aktualisiert den Fahrtstatus. Der schwierige Teil ist der ausfallsichere Pfad: Die Befehlswarteschlange muss abgebrochene Mobilfunksignale, niedrigen Akkustand und teilweise Bestätigungen bewältigen, damit einem Fahrer nie ein Scooter berechnet wird, der sich tatsächlich nicht entsperrt hat.
Geofencing definiert virtuelle Grenzen auf der Karte — Fahrverbotszonen, Langsamfahrzonen und Parkbereiche. Wenn die GPS-Position eines Scooters eine Grenze überschreitet, sendet die Plattform dem Controller einen Befehl, die Geschwindigkeit zu reduzieren oder anzuhalten. Dies ist eine zentrale Anforderung an die urbane Sicherheit und Regulierung: Die meisten Städte in den USA und der EU lizenzieren geteilte Scooter unter der Bedingung, dass Betreiber Geschwindigkeitsbegrenzungen durchsetzen und Scooter aus Fußgängerbereichen fernhalten können. Die Geofencing-Engine ist daher nicht optional, sie ist die Genehmigung.
Ein fokussiertes MVP mit einer GPS-Scooter-Karte, QR-Entsperrung, Fahrtmessung, einem In-App-Wallet und beiden Store-Einreichungen dauert typischerweise 16–22 Wochen. Die vollständige IoT-Telematik-Steuerungsebene, Geofencing mit automatischer Geschwindigkeitsbegrenzung, ausfallsicheres Sperr-Handling und das Betriebs-Dashboard fügen 8–12 Wochen hinzu. Die Hardware-Integrations-Discovery — die Arbeit mit einem physischen Scooter-Prototyp, um das Anfrage-Antwort-Protokoll des Controllers abzubilden — wird häufig unterschätzt und sollte als eigene Phase eingeplant werden.
Die Hardware und die städtischen Genehmigungen zu besitzen, ist die eine Hälfte des Geschäfts; die andere Hälfte ist die Software, die einen geparkten Scooter in einen mietbaren, nachverfolgbaren, abrechenbaren Vermögenswert verwandelt. Komplexe Telematik, GPS-Flottenverfolgung, Geofencing und ein zahlungssicheres Fahrt-Wallet sind spezialisierte Engineering-Disziplinen. Ein Team, das diesen Stack für iOS und Android ausgeliefert hat, kann das Controller-Protokoll aus einem physischen Prototyp abbilden, die ausfallsichere Befehlsschicht entwickeln und die Admin-Plattform weitaus schneller aufbauen, als diese Fähigkeit von Grund auf intern aufzubauen.
Verwandte Fallstudien
Native iOS- + Android-Buchungsplattform mit Live-Verfügbarkeit und geobasierter Entdeckung in den USA & der EU.
Fallstudie ansehen → Reise · UmzugMobile Consumer-Plattform mit Karten, standortbasierten Diensten und einer mehrsprachigen Build für internationale Nutzer.
Fallstudie ansehen → Verleih · MarktplatzVerleih-Marktplatz mit Buchungs-Flow, Zahlungen und einem Betriebs-Backoffice in den USA & der EU.
Fallstudie ansehen →
Native iOS-, Android- und plattformübergreifende Apps mit store-fertigen Release-Pipelines.
Mobile App-Entwicklung entdecken →
Maßgeschneiderte Plattformen, die auf Ihr Geschäftsmodell zugeschnitten sind und sauber vom MVP bis zu Millionen von Nutzern skalieren.
Individuelle Softwareentwicklung entdecken →
Gehärtete, beobachtbare Steuerungsebenen und Terraform-Infrastruktur, die über US- und EU-Regionen hinweg skalieren.
Cloud & DevOps entdecken →