App-Agentur für E‑Mobilität & Ladeinfrastruktur
Wir entwickeln EV-Charging-Apps für Betreiber, Mobility Brands und EV-Plattformen, deren bestehende Lösungen an ihre Grenzen stoßen. Ob Rebuild, verbesserte Brand Experience oder Multi-Brand-Produkt: wir helfen Ihnen, Ihre Plattform weiterzuentwickeln, ohne bestehende Funktionen zu verlieren oder unnötige Risiken für Ihre aktuellen Nutzer:innen zu schaffen.
Kontakt!
Warum Stormotion?
Echte EV-Erfahrung
Seit 2017 entwickeln und launchen wir EV-Charging-Apps in Europa und Australien. Dabei haben wir mit CPO-Flows, eMSP-Logik, White-Label-Anpassungen, Roaming und komplexen Payment-Szenarien gearbeitet.
Entwickelt für Live-Produkte
Die meisten unserer Kund:innen haben bereits ein laufendes Produkt: mit aktiven Nutzer:innen, Backend-Abhängigkeiten und einer Roadmap, die nicht einfach ersetzt werden kann. Deshalb wissen wir, wie man eine Lade-App verbessert oder neu aufsetzt, ohne den laufenden Betrieb zu stören oder Migrationsrisiken für bestehende Nutzer:innen zu schaffen.
Bereit für Wachstum in mehreren Märkten
Die eigentliche Komplexität liegt oft nicht in der Lokalisierung, sondern im Produkt selbst: unterschiedliche Payment-Modelle, regulatorische Anforderungen, Roaming-Partner und White-Label-Setups müssen sauber zusammenspielen. Wir denken diese Anforderungen von Anfang an mit, damit Ihre EV-Charging-App nicht nur für einen Markt oder eine Marke funktioniert, sondern langfristig skalierbar bleibt.
App-Entwicklung für EV Charging: unsere Schwerpunkte
- CPO apps
- White-Label-Platformen
- Terminal Software
- eMSP Apps
- Multi-Context Charging
- Billing & Payments
- B2C & B2B Tools
design von Stormotion
Branded CPO- und Operator-Apps für Fahrer:innen
Viele CPO-Apps kommen irgendwann an einen Punkt, an dem die einfache White-Label-Version nicht mehr ausreicht: Die UI wirkt generisch, das Backend ist veraltet und neue Funktionen lassen sich nur schwer oder gar nicht umsetzen. Wir entwickeln EV-Charging-Apps für Betreiber, die ihre bestehende App modernisieren oder neu aufsetzen möchten, ohne Infrastruktur, aktive Nutzer:innen oder bestehende Workflows zu gefährden.
Ladevorgänge: Start, Steuerung und Abschluss von Charging Sessions
Karte mit Echtzeit-Verfügbarkeit von Ladestationen und Filtern
Tarifanzeige, Session-Historie und In-App-Billing
OCPI/OCPP-Backend-Integration und Roaming Support
design von Stormotion
Multi-Brand- und White-Label-Produkte für EV Charging
Wir entwickeln White-Label-Produkte für EV Charging, bei denen markenspezifische Anpassungen wie Farben, Logos oder Onboarding-Flows sauber vom Produktkern getrennt sind. Ein neuer Kunde sollte nicht automatisch ein neues Repository bedeuten.
Gemeinsamer App Core mit Brand- und Config-Layer pro Kunde
SDK-Erweiterung und White-Label-Anpassung innerhalb bestehender Frameworks
CMS für kundenspezifische Inhalte, Kampagnen und Loyalty-Programme
Multi-Client Release Management ohne ausufernde Codebase
design von Stormotion
Apps für Ladeterminals, Android Kiosks und Payment Terminals
Payment Terminals bringen klare technische Grenzen mit: kleine Screens, eingeschränkte Farbdarstellung, ältere Android-Versionen und Vendor Approval Prozesse, die mehrere Monate Projektlaufzeit beeinflussen können. Für das Truck-Charging-Netzwerk von Milence haben wir eine App auf Basis von Worldline Valina Terminals entwickelt, NDT Security Testing bestanden und einen vollständigen Payment Flow von der Pre-Authorization bis zum Abschluss der Charging Session umgesetzt.
Native Android Apps für Embedded Payment Terminals und Kiosks
Payment Flows mit Bankkarte, RFID, Pre-Authorization und Incremental Reservation
Custom UI innerhalb klarer Hardware-Grenzen: Screen Size, Farben und Performance
Vendor Compliance und Security Testing, z. B. NDT oder vergleichbare Anforderungen
design von Nasir Uddin
eMSP- und Multi-Network Laden-Apps
Fahrer:innen möchten nicht fünf verschiedene Apps für fünf verschiedene Ladenetze nutzen. Wir entwickeln eMSP Apps, die über mehrere Netzwerke und Backend-Systeme hinweg funktionieren – inklusive der Edge Cases, die Standardlösungen oft nicht sauber abdecken.
Multi-Network-Karte mit Echtzeit-Verfügbarkeit von Ladestationen
eRoaming Support und netzwerkübergreifendes Session Management
Abo- und Tariflogik über verschiedene Ladenetze hinweg
Payment Flows mit Apple Pay, Google Pay, Karten, RFID und Pre-Authorization
design von Musemind Mobile
Apps für Public, Home und Workplace Charging
Laden im öffentlichen Raum, zu Hause und am Arbeitsplatz wirkt auf den ersten Blick ähnlich. In der Praxis unterscheiden sich diese Kontexte jedoch deutlich: durch andere Zugriffslogiken, Preismodelle und Nutzergruppen. Viele Apps bilden einen dieser Kontexte gut ab und behandeln die anderen eher als Erweiterung. Wir entwickeln Produkte, bei denen Public, Home und Workplace Charging von Anfang an als gleichwertige Bestandteile der Architektur gedacht werden – nicht als nachträgliche Features in Version 3.
Public Charging: Karte, Roaming, Open Access und Guest Payment Flows
Home Charging: Device Pairing, persönliche Tarife und geplantes Laden
Workplace Charging: Zugriffskontrolle, Kostenverteilung und Fleet- oder Employee Billing
Gemeinsame Account- und Session-Logik über alle drei Kontexte hinweg
design von Ajay Shekhawat
EV Charging Apps mit Abo-, Tarif- und Payment-Logik
Pricing im EV Charging ist selten einfach. Eine einzelne Charging Session kann feste Tarife, zeitbasierte Gebühren, verschiedene Abo-Stufen, Roaming-Aufschläge und Rabatte aus Loyalty-Programmen enthalten. Damit diese Logik in der App zuverlässig funktioniert, müssen Daten entlang der gesamten User Journey sauber verarbeitet werden: vom Karten-Pin über den Session Screen bis hin zu Beleg und Payment-Historie. Wir entwickeln diese Logik mit Blick auf unterschiedliche Märkte, Payment-Systeme und operative Anforderungen.
Abo-Modelle mit Zugriffsrechten und Nutzungslimits
Dynamische Tarifanzeige auf Basis von Echtzeit-Backend-Daten
Payment Flows mit Apple Pay, Google Pay, Karten, RFID und Pre-Authorization
Loyalty-Programme, Promo Codes und Partner-Rabatt-Integrationen
design von Rakibul 🏀
B2C Driver Apps, B2B Portale und Back-Office Tools
Driver Apps und Back-Office Tools werden häufig von unterschiedlichen Teams zu unterschiedlichen Zeitpunkten entwickelt. Das zeigt sich später im Produkt: uneinheitliche Berechtigungen, nicht synchronisierte Session-Daten und Business Logic, die an mehreren Stellen verteilt ist. Wir entwickeln beide Seiten des Produkts und sorgen dafür, dass Driver App, B2B Portal und Back Office von Anfang an zusammenspielen – statt die Integration später nachträglich zu lösen.
Driver App Flows, verbunden mit Berechtigungen und Zugriffslogik im B2B-Portal
Fleet- und Corporate Account Management mit Kostenverteilung
Back-Office-Tools für Stationsmonitoring, Tarifmanagement und Reporting
Gemeinsamer Data Layer für Consumer- und Business-Oberflächen
Unsere Referenzen in der E-Mobilität Entwicklung
Ein skalierbarer Stack für die Entwicklung von EV-Charging-Apps
Programming Languages
Frameworks
Networking & APIs
Backend & Data
Payments & Monetization
External Devices / IoT & Connectivity
Graphics, Video & Audio
Forms & Validation
Analytics & Monitoring
Testing & QA
CI/CD & Delivery
AI / Machine Learning
Admin & CMS
TypeScript
Kotlin
Swift
Kund:innen über unsere Zusammenarbeit
Unsere Kernstärken
1
App Rebuilds und Migration
Die meisten Laden-Apps, an denen wir arbeiten, sind keine neuen Produkte. Es sind bestehende Lösungen, die aus ihrem aktuellen Setup herausgewachsen sind. Wir haben Charging Apps für Betreiber redesignen und modernisieren, bei denen bereits aktive Nutzer:innen, komplexe Backend-Abhängigkeiten und operative Prozesse vorhanden waren, die nicht unterbrochen werden durften.
2
Feature-Parity-Planung für V1 Releases
Bevor wir mit der Entwicklung starten, analysieren wir das bestehende Produkt: Welche Funktionen sind bereits vorhanden? Was muss zwingend in der ersten Version enthalten sein? Und was kann bewusst später umgesetzt werden? So schaffen wir eine klare Grundlage für den Rebuild oder die Weiterentwicklung – ohne unnötige Risiken, besonders für Nutzer:innen, die das Produkt bereits im Alltag verwenden.
3
Public, Home und Workplace Charging in einem Produkt
Auf den ersten Blick wirken Public, Home und Workplace Charging ähnlich. In der Praxis unterscheiden sie sich jedoch deutlich: durch andere Zugriffslogiken, andere Preismodelle und andere Nutzergruppen. Wir haben Produkte entwickelt, in denen all diese Kontexte in einer einzigen App zusammengeführt werden mussten. Entscheidend ist, von Anfang an die richtige Struktur zu schaffen, damit kein Bereich wie ein nachträglich ergänztes Feature wirkt.
4
OCPI/OCPP-Integrationen und Roaming-Logik
Wir haben OCPI bereits in mehreren Projekten integriert, darunter Atlante, zuup und weitere EV-Produkte. Dadurch konnten Roaming zwischen Netzwerken, der Wechsel zwischen Providern und ein zuverlässiges Session Management über verschiedene Backends hinweg umgesetzt werden. Wenn ein Kunde bereits ein eigenes CPMS oder eine Partnerplattform nutzt, versuchen wir nicht, diese Systeme zu umgehen. Wir bauen darauf auf und berücksichtigen ihre bestehenden Möglichkeiten und Grenzen.
5
White-Label-Architektur, die über mehrere Marken skaliert
Wir kennen White-Label-Lösungen aus beiden Perspektiven: als Team, das mit einem bestehenden SDK arbeitet, zum Beispiel bei Atlante auf Basis von Deftpower, und als Entwicklungspartner, der ein Basisprodukt für andere Betreiber aufbaut. Der entscheidende Punkt ist die saubere Trennung zwischen Produktlogik und Brand Layer. So wird nicht jeder neue Kunde automatisch zu einer eigenen Codebase.
6
B2C-App und B2B-Portal, die zusammen funktionieren
Driver Apps sind häufig mit Fleet Management Tools, Corporate Accounts und Back-Office-Systemen verbunden. Werden diese Komponenten getrennt voneinander entwickelt, entstehen früher oder später Inkonsistenzen: Berechtigungen passen nicht zusammen, Session-Daten laufen auseinander und Billing-Logik wird an mehreren Stellen gepflegt. Deshalb entwickeln wir diese Produktbereiche von Anfang an auf einer gemeinsamen Datenbasis. So bleiben Zugriffsrechte, Sessions und Abrechnung über das gesamte System hinweg konsistent.
7
Multi-Market Delivery: Lokalisierung, Payments und Compliance
Wir haben E-Mobilität-Produkte in Europa und Australien gelauncht – mit unterschiedlichen Payment-Systemen, Roaming-Anforderungen, regulatorischen Rahmenbedingungen und Sprachen. Für Atlante haben wir beispielsweise 11 Sprachen in 4 Ländern unterstützt und die UI vollständig über BrowserStack getestet. Die Lokalisierung selbst ist dabei meist der einfachere Teil. Anspruchsvoller ist es, sicherzustellen, dass die Produktlogik über verschiedene Märkte hinweg konsistent und zuverlässig funktioniert.
Wie wir zusammenarbeiten
Product-Based
Talent-Based
Client
Stormotion
Client Supervisor
SM Dev
SM Dev
Client
Stormotion Engineers + Ihr Team
Ein oder mehrere Engineers integrieren sich in Ihr bestehendes Team und arbeiten direkt mit Ihnen zusammen: in Ihren Tools, nach Ihren Prozessen und entlang Ihrer Entwicklungspläne. So bleibt Kontext über Sprints hinweg erhalten, und Ihr Team muss nicht ständig neue Personen in Produktlogik, Roadmap oder technische Abhängigkeiten einarbeiten.
Dieses Modell passt besonders gut, wenn:
- Ihre Plattform vor allem backend-lastig ist und die Mobile App besondere Aufmerksamkeit braucht
- White-Label-Aufgaben anstehen, für die Ihrem internen Team aktuell die Kapazität fehlt
- Sie EV-spezifische Expertise direkt in Ihrem Entwicklungsprozess benötigen, z. B. für OCPI, Charging Sessions oder Payments
Client
Stormotion
Product Owner
SM Dev
SM Dev
SM Dev
SM Dev
Eigenständiges Stormotion Team
Wir können auch das gesamte Produkt übernehmen: Entwicklung, QA, Design und Projektsteuerung. In diesem Modell verantworten wir Roadmap, Releases und laufenden Support, während Sie sich auf Ihr Kerngeschäft konzentrieren können.
Dieses Modell passt besonders gut, wenn:
- Sie eine CPO- oder eMSP App entwickeln oder neu aufsetzen möchten, ohne ein eigenes Team aufzubauen
- Sie ein Multi-Brand-Produkt launchen und dafür ein eingespieltes Team für den gesamten Prozess suchen
- Sie ein bestehendes Live-Produkt modernisieren möchten, ohne den laufenden Betrieb zu unterbrechen
Warum unsere Kunden mit uns weiterarbeiten
Kontakt!9+ Jahre Erfahrung in EV und E‑Mobilität
Seit 2017 entwickeln wir EV Charging-Produkte: CPO Apps, eMSP-Plattformen, White-Label-Lösungen und Software für Payment Terminals. Wir kennen die Branche aus der Praxis: wie Prozesse funktionieren, wo technische Grenzen entstehen und an welchen Stellen Probleme im Live-Betrieb typischerweise auftreten.
3,3 Jahre durchschnittliche Kundenpartnerschaft
Atlante, Deftpower, Milence, Enercity und zuup arbeiten weiterhin mit uns zusammen. Wir sind nicht nur bis zum Launch dabei. Viele unserer EV-Kunden begleiten wir über Jahre hinweg: durch Releases, Migrationen, neue Märkte und kontinuierliche Produktiterationen.
3,7 Jahre durchschnittliche Engineer-Zugehörigkeit
Unsere Engineers bleiben langfristig im Team. Das bedeutet: Die Person, die Ihren Charging Session Flow gebaut hat, ist mit hoher Wahrscheinlichkeit auch dann noch dabei, wenn dieser später erweitert oder angepasst werden muss. So bleibt Produktwissen erhalten, Ramp-up-Zeit wird reduziert und Sie müssen denselben Kontext nicht immer wieder neu erklären.
FAQ
Was kostet die Entwicklung einer EV-Charging-App?
Jedes EV-Projekt ist anders, deshalb lässt sich kein seriöser Festpreis nennen. Gerade im EV-Bereich hängen die Entwicklungskosten einer Charging App von vielen Faktoren ab: bestehender Infrastruktur, Backend-Abhängigkeiten, Payment-Flows, Roaming, White-Label-Anforderungen und Multi-Market-Support.
Eine grundlegende V1 mit zentralen Charging-Szenarien, Karte, Payments und Session Management liegt typischerweise zwischen 50.000 und 70.000 €. Komplexere Lösungen, etwa mit White-Label-Architektur, Multi-Market-Support oder Terminal-Software, können deutlich darüber liegen.
Wie lange dauert es, eine bestehende EV-Charging-App neu aufzusetzen, ohne Live-Nutzer:innen zu stören?
Der Zeitrahmen hängt davon ab, wie komplex das bestehende Produkt ist und wie viel Funktionalität bereits in der ersten Version enthalten sein muss. Bei einem gezielten Rebuild oder Redesign mit klar definiertem Scope dauert ein solches Projekt in der Regel 4 bis 6 Monate. Ein großer Teil der Zeit fließt dabei nicht nur in die Entwicklung selbst, sondern in die Vorbereitung: Was ist bereits vorhanden? Welche Funktionen dürfen nicht verloren gehen? Welche Abhängigkeiten gibt es? Und wie lassen sich Releases so strukturieren, dass bestehende Nutzer:innen nicht beeinträchtigt werden?
Arbeiten Sie mit bestehenden Backends, CPMS-Plattformen und White-Label-SDKs, oder entwickeln Sie neue Apps?
Beides ist möglich. In den meisten EV-Projekten arbeiten wir jedoch mit bestehender Infrastruktur: Backends, CPMS-Plattformen, Partner-Systemen oder White-Label-SDKs.
Wir müssen nicht das gesamte Backend kontrollieren, um eine zuverlässige App Experience zu entwickeln. Und wir würden nicht empfehlen, funktionierende Systeme neu zu bauen, nur damit die Entwicklung für uns einfacher wird. Stattdessen integrieren wir uns in die vorhandene Architektur, berücksichtigen ihre Grenzen und bauen dort weiter, wo es für das Produkt sinnvoll ist.
Können Sie sowohl die Driver App als auch das B2B Portal unterstützen?
Ja. Wir arbeiten sowohl an der Nutzerseite als auch an Back-Office- und B2B-Oberflächen. In vielen EV-Produkten ist genau diese Verbindung entscheidend.
Wenn Driver App und interne Tools von unterschiedlichen Teams oder zu unterschiedlichen Zeitpunkten entwickelt werden, entstehen mit der Zeit oft Inkonsistenzen: Zugriffsrechte passen nicht zusammen, Sessions werden nicht sauber synchronisiert und Billing-Logik unterscheidet sich je nach Systembereich.
Deshalb entwickeln wir beide Seiten idealerweise auf einer gemeinsamen Datenbasis. So bleiben Berechtigungen, Sessions und Abrechnung konsistent – nicht nur zum Launch, sondern auch sechs Monate später.
Wie sichert ihr Vertraulichkeit und Datensicherheit?
Wir verschlüsseln Daten bei Übertragung und Speicherung (AES 256), setzen auf sichere Kommunikationsprotokolle (HTTPS, TLS 1.3) und implementieren Role-Based Access Control sowie Audit Logging.
Wie adressiert ihr regulatorische Anforderungen wie DSGVO oder UK GDPR?
Wir setzen europäische Datenschutzvorgaben (DSGVO, UK GDPR) konsequent um. In unseren Projekten werden personenbezogene Daten nur mit ausdrücklicher Einwilligung und nach dem Prinzip der Datensparsamkeit verarbeitet – mit End-to-End-Verschlüsselung, Zugriffskontrolle und Audit Logging.
Wie stellt ihr Compliance mit europäischen und internationalen Standards sicher?
Wir implementieren alle relevanten Standards und Protokolle – abhängig vom Ladesystem (z. B. IEC 62196, CCS) und der Kommunikationsebene (OCPP, OCPI). Zudem berücksichtigen wir Safety-Standards wie IEC 61851 sowie Datenschutz- und Sicherheitsvorgaben innerhalb der EU.
Könnt ihr Features wie Real-Time Availability, Dynamic Pricing und User Analytics integrieren?
Ja. Diese Features gehören zu unseren Standardleistungen in der App-Entwicklung für Ladeinfrastruktur. Wir empfehlen sie früh im Prozess zu definieren – für optimale Datenarchitektur und Performance. Beispiele dazu finden Sie in unseren Referenzen im Bereich E-Mobilität.
Wir sind gespannt auf Ihr Projekt!
Vielen Dank
Ihre Nachricht wurde gesendet.
Unser Mitarbeiter wird sich so schnell wie möglich bei Ihnen melden. Einen schönen Tag noch!
Zur Startseite
