Als die erste Generation von Ladestationsbetreibern (CPO) ihre Netzwerke ausbaute, war die Beauftragung eines kommerziellen CPMS (Managementsystem für Ladestationen) keine ernsthafte Option. Die verfügbaren Plattformen steckten in den Anfängen, waren oft an bestimmte Hardwarefamilien gebunden und selten für die Komplexität gebaut, mit der ein wachsender Betreiber tatsächlich zu tun hatte: Tarifstrukturen über mehrere Märkte, Roaming mit vielen Partnern, Abrechnungsintegrationen auf Unternehmensniveau, Hardware von Herstellern, die keine fremde Software zertifizieren wollten.
Also bauten die Betreiber selbst. Die Entscheidung war rational. Ein gut ausgestattetes internes Team konnte etwas schaffen, das genau den Anforderungen des Unternehmens entsprach, ohne Einschränkungen durch Anbieter und ohne Produkt-Roadmaps, die von den Kunden und Prioritäten anderer geprägt waren. Der Markt für kommerzielle CPMS hatte noch keine Plattform hervorgebracht, der man den Kern des eigenen Betriebs hätte anvertrauen können.
Diese Plattformen erfüllten einen echten Zweck. Viele steuern noch heute Tausende Ladepunkte. Die Argumente für den Eigenbau waren stichhaltig. Geändert hat sich, ob dieselbe Logik heute noch trägt.
Ein Muster, das die Softwarebranche schon kennt
Vor zwei Jahrzehnten vollzog sich in der Unternehmenssoftware ein vergleichbarer Wandel, getrieben von denselben strukturellen Bedingungen: eine Kategorie, die schneller reifte, als die etablierten Anbieter erwartet hatten, und eine rationale Entscheidung, die sich mit ihr verschob. Unternehmen mit selbst entwickelten CRM-Tools machten keinen Fehler. Die kommerziellen Alternativen waren entweder unausgereift oder, im Fall von Siebel, auf Lizenzmodelle und Implementierungszyklen ausgelegt, die für die meisten Organisationen ohne eigenes Beratungsbudget nicht praktikabel waren. Etwas zu bauen, das den tatsächlichen Anforderungen des Unternehmens entsprach, war die rationale Entscheidung.
Mit Salesforce kam nicht einfach ein besseres Produkt auf den Markt. Die Kategorie reifte so weit, dass sich die Rechnung änderte. Siebel erreichte 2002 seinen Höchststand mit 45 % des CRM-Markts. Vier Jahre später war der Standard ein völlig anderer. Unternehmen, die nach diesem Wendepunkt weiter ihre eigene CRM-Infrastruktur bauten und pflegten, bezogen keine prinzipientreue Position; sie trugen Entwicklungsaufwand, der wettbewerblich keinen Sinn mehr ergab. Niemand behauptet, dass der ursprüngliche Eigenbau falsch war; die Kategorie reifte um sie herum, und die rationale Entscheidung verschob sich.
Der CPMS-Markt durchläuft denselben Wandel. Für Betreiber mit proprietären Plattformen ist die Kategorie gereift. Offen ist nur noch, ob sie handeln, solange alle Optionen offenstehen, oder warten, bis die Plattform den Betrieb ernsthaft einschränkt.
AMPECO basiert auf genau diesem Prinzip: Die Wartung der Infrastruktur erfolgt zentral für 200+ Betreiber, differenzierende Funktionen entwickelt und besitzt jedes Netzwerk selbst.
Was sich wirklich geändert hat
Seit die meisten Entscheidungen für ein Inhouse-CPMS getroffen wurden, haben sich drei Dinge grundlegend verändert.
Kommerzielle Plattformen haben sich seit 2016 stark entwickelt
Die meisten Betreiber, die den kommerziellen Markt damals prüften und die Optionen für zu unausgereift, zu unflexibel oder zu hardwareabhängig hielten, lagen richtig. Das Problem: Viele dieser Betreiber haben ihr Urteil seitdem nicht überprüft. Was heute kommerziell verfügbar ist, unterscheidet sich deutlich von dem, was es zum Zeitpunkt der meisten Inhouse-Entscheidungen gab: ein breiterer API-Umfang, echte Hardwareunabhängigkeit und die Fähigkeit, regulatorische Änderungen auf Plattformebene umzusetzen, statt sie an das Team jedes einzelnen Betreibers weiterzureichen.
Die regulatorischen Pflichten sind deutlich gewachsen
Die AFIR-Pflichten für Zahlungsterminals traten im April 2024 in Kraft. ISO 15118-20 wurde im Januar 2026 für öffentliches Laden verpflichtend. Für halböffentliche und private Netzwerke folgt ISO 15118-20 im Januar 2027. OCPP 2.0.1 (Open Charge Point Protocol) ist in Nordeuropa bereits ein Eignungskriterium bei öffentlichen Ausschreibungen, zunehmend auch in der DACH-Region. Für ein Inhouse-Team ist jede dieser Vorgaben ein eigener Entwicklungssprint. Die kumulierte Sprintlast über 36 Monate ist für keinen Betreiber mit eigener proprietärer Plattform eine Prognose; sie ist sein aktuelles Backlog. Jede Pflicht bindet geplante Entwicklungszeit, die nicht gleichzeitig in den Markteintritt, umsatzrelevante Funktionen oder ein besseres Kernerlebnis für EV-Fahrer fließen kann.
Bei großen Betreibern ändert sich der Branchenkonsens
Das Argument für den Eigenbau bezog seine Kraft immer auch daraus, dass vergleichbare Unternehmen dieselbe Entscheidung trafen. Diese Dynamik ändert sich. Evolt, der britische Anbieter für EV-Laden mit über 10.000 Ladepunkten und fünfzehn Jahren Investition in eine proprietäre Plattform, prüfte 2025 den kommerziellen Markt und kam zu dem Schluss, dass er die Anforderungen inzwischen erfüllt. Der für die technische Due Diligence bei Evolt verantwortliche Ingenieur beschrieb den Abstand zu den Alternativen als „meilenweit“. Wenn Betreiber dieser Größe anders entscheiden, verliert die Begründung für den Inhouse-Konsens an Gewicht.
Die Wartungsfalle
Das Kernproblem von Inhouse-Plattformen ist nicht, dass sie versagen. Das Modell hindert Entwicklungsteams strukturell daran, dem Markt voraus zu entwickeln, weil der Aufwand, die Plattform aktuell zu halten, immer zuerst Kapazität bindet. Jedes Jahr bringt neue Pflichten: OCPP-Versionsupdates, OCPI-Roaming-Spezifikationen (Open Charge Point Interface), Compliance-Vorgaben, Zertifizierungen für Zahlungsterminals. Sie wachsen mit jedem neuen Markt und jedem neuen Regulierungszyklus.
Das Ergebnis ist vorhersehbar. Das Team, das die Plattform einst als Motor des Geschäfts gebaut hat, verlagert nach und nach seine Arbeitszeit. Nicht weil jemand bewusst eine strategische Entscheidung getroffen hätte, sondern weil die Wartungsliste schneller wächst, als sich das Innovations-Backlog abarbeiten lässt. Steht eine regulatorische Frist an, zieht sie die Priorität von der Funktion ab, die für Q2 geplant war. Wenn ein Firmware-Update einen Sonderfall bei der Hardware auslöst, sind die Entwickler, die den Fehler suchen, dieselben, die eigentlich das Nächste entwerfen sollten.
Was der Markt heute erwartet
Als die meisten Inhouse-CPMS-Plattformen entstanden, waren die Erwartungen an Betreiber im EV-Laden deutlich niedriger. Fahrer akzeptierten Unzulänglichkeiten; Investoren sahen die Branche als langfristige Infrastruktur ohne kurzfristigen Lieferdruck; Regulierungsbehörden arbeiteten noch an den Regeln, die später bestimmte Protokolle und Zahlungsstandards vorschreiben sollten.
Dieses Zeitfenster ist kleiner geworden. In den reifen Märkten Nord- und Westeuropas und der DACH-Region hat es sich weitgehend geschlossen.
Investoren bewerten Betreiber im EV-Laden heute nach denselben Kriterien wie jedes skalierte Dienstleistungsunternehmen: planbare Margen, niedrige Kosten pro Kunde und eine Produkt-Roadmap, die auf Differenzierung statt auf Infrastrukturpflege setzt. Ein Entwicklungsteam, dessen Kapazität von der Plattformwartung aufgezehrt wird, wird zu einem Kostenposten in der GuV, den der Vorstand aktiv rechtfertigen muss. Betreiber, die schlanke Abläufe, hohe Verfügbarkeit und eine auf ihre tatsächliche Marktposition ausgerichtete Entwicklungskapazität vorweisen können, überzeugen mehr als jene, die Compliance-Arbeit noch mit internem Personal stemmen, und dieser Unterschied zeigt sich darin, wie Investoren das Geschäft bewerten.
Auch die Erwartungen der Fahrer haben ein vergleichbares Niveau erreicht. Zuverlässige Ladevorgänge über alle Hardwaretypen hinweg, reibungslose Zahlungsabwicklung, Roaming, das wie versprochen funktioniert: Nichts davon beeindruckt Fahrer heute noch, doch wer hier versagt, erntet Beschwerden, die monatelang in den Suchergebnissen stehen.
Kaum jemand berechnet, was das Festhalten kostet
Die meisten Betreiber, die eine Migration geprüft haben, rechnen irgendwann alles durch: wie viel Entwicklungspersonal tatsächlich auf die Plattformwartung entfällt, was es gekostet hat, die Funktionen im Backlog immer wieder aufzuschieben, wie weit der Compliance-Zyklus hinter den heutigen Marktanforderungen zurückliegt und was diese Lücke 2027 kosten wird.
Wenn Reue aufkommt, betrifft sie selten den ursprünglichen Eigenbau. Sie betrifft die wachsenden Kosten einer Entscheidung, die abgeschlossen schien, es aber nicht war: den angehäuften Aufwand des Festhaltens, nicht die Logik der ursprünglichen Wahl.
Die Entscheidung, bei einer Inhouse-Plattform zu bleiben, fällt selten bewusst. Sie verfestigt sich als Standard, bis etwas die Kosten für den Vorstand sichtbar macht. Eine verpasste regulatorische Frist. Eine schwierige Phase, nachdem ein erfahrener Entwickler mit jahrelangem Plattformwissen das Unternehmen verlassen hat. Ein Wettbewerber, der Funktionen ausliefert, die seit achtzehn Monaten im eigenen Backlog liegen.
Betreiber, die eine Migration vor diesen Wendepunkten prüfen, haben den größten Spielraum. Der Zeitplan ist nicht unter Druck, das Plattformteam ist noch engagiert, und der Umfang eines Umstiegs lässt sich sauber festlegen, statt von einer Krise bestimmt zu werden. Wer wartet, findet ein erschöpftes Plattformteam vor, einen durch eine akute Krise verkürzten Zeitplan und eine interne Argumentation, die sich weit schwerer durchsetzen lässt.
Die entscheidende Frage
Die Betreiber, die selbst gebaut haben, trafen unter den damaligen Bedingungen die richtige Entscheidung. Es geht nicht darum, dass sie falsch lagen; es geht darum, dass sich die Bedingungen geändert haben und mit ihnen die rationale Entscheidung.
Die entscheidende Frage betrifft nicht die Vergangenheit, sondern das, was die Plattform heute kostet: nicht im Vergleich der Lizenzgebühren, sondern in Entwicklungskapazität, die in Standardinfrastruktur statt in Differenzierung fließt, in Regulierungssprints statt Markteintritten, im Wartungsmodus statt im Vorausentwickeln.
Um diese Rechnung für Ihren Betrieb aufzustellen (was der Aufwand für Standardinfrastruktur kostet, was er verhindert und wo die aktuelle Plattform im Vergleich zu den besten Plattformen von heute steht), bildet der Inhouse-CPMS-Benchmark das Gesamtbild in sieben Leistungsdimensionen ab.
Wenn sich diese Frage in Ihrem Unternehmen stellt, vertiefen diese Beiträge einzelne Aspekte:
Woran arbeiten Ihre Inhouse-CPMS-Entwickler eigentlich?: das Raster, mit dem Sie die Arbeitslast Ihres Teams zwischen Standardinfrastruktur und Differenzierung aufteilen, und wie das Bild auf den meisten Inhouse-Sprintboards tatsächlich aussieht.
Inhouse-CPMS: die Kosten, über die niemand spricht: die Kosten, die in keiner Budgetzeile auftauchen, und die Fragen, die Sie Ihrer Geschäftsleitung stellen sollten, bevor die Lücke weiter wächst.
