Jakob Kleihues, co‑founder of ENAPI
EV roaming, OCPI, financial clearing, uptime and AI native engineering
Transcript
Opgeschoond op basis van een automatisch transcript. Vertalingen zijn automatisch gegenereerd en kunnen fouten bevatten.
Welkom bij de Smart Charge by RiDERgy podcast. Dit is Claudio Geyken, oprichter en CEO van RiDERgy. Dit is uw show om alles te leren over energiebeheer en smart charging innovatie voor elektrische voertuigen en vloten. Maak connecties met 450 partners en u bouwt 450 handdrukken, of u bouwt er één. Dat is het idee achter Inopi, en mijn gast vandaag is medeoprichter Jacob Clayhus. In 2,5 jaar heeft zijn bedrijf meer dan 1 miljoen laadpunten verbonden, en dat deed het met een claim die bijna provocerend klinkt.
Connectiviteit tussen laadpuntbeheerders en mobility service providers zou gratis moeten zijn. Het geld, zegt hij, wordt ergens anders verdiend. We praten over waar, over wat financiële clearing werkelijk inhoudt, en over hoe een zeer klein team zijn infrastructuur 99,998% van de tijd draaiende houdt. Laten we erin duiken. Goed, Jacob, fijn dat u er vandaag bent. Hoe gaat het met u? Ja, heel erg bedankt voor de uitnodiging. Ja, ik ben een beetje gestrest, zoals u weet, ik was laat. Geen probleem, haastte me vanaf het vliegveld, maar verder gaat het prima. Heel erg bedankt.
U kwam vandaag uit Nederland, dus ik denk dat ik nog geen gast heb gehad die op dezelfde dag zo ver is gekomen. Ja, precies, vooral omdat ik thuis ben in Berlijn zoals u, dus het is vreemd. Maar goed, heel goed en heel erg bedankt voor de uitnodiging. Ja, en fijn om ook te weten dat u een echte Berlijnaar bent, hier geboren, geboren en getogen, en uw ouders ook. Het is iets wat ik niet wist, aangezien ik hier ook in Berlijn ben opgegroeid. Ja, ik groeide op in Berlijn.
Ik heb een behoorlijk aantal jaren in andere steden door heel Europa gewoond - studeerde in het zuiden van Duitsland en in Kopenhagen, werkte toen korte tijd in Londen en in Amsterdam. Dus ik ken ook wel wat andere plekken, maar ik ben al een flink aantal jaren terug in Berlijn en bouw Inopi ook vanuit Berlijn op. Ja, en misschien kunt u wat meer vertellen over uw achtergrond. Ik besloot ook om van Berlijn naar het zuiden van Duitsland te gaan, grappig genoeg, om te studeren, maar ik denk dat veel Berlijnaars ook graag in Berlijn blijven.
Wat was uw motivatie om naar het zuiden te gaan en te studeren? Ik bedoel, dit gaat terug naar toen ik 18 was, toch? Ik vraag me af of ik me überhaupt kan herinneren waarom dat was. Om eerlijk te zijn, denk ik een heel natuurlijk "laten we zo ver mogelijk weg gaan" - en misschien was mijn horizon toen een beetje Duitsland-gericht, om eerlijk te zijn. Maar ja, dus ik studeerde aan de Zeppelin Universiteit in Friedrichshafen, aan de Bodensee precies, en
ik had daar een geweldige tijd. Om eerlijk te zijn vraag ik me soms af hoeveel ik werkelijk toepas van wat ik op de universiteit of school in het algemeen heb geleerd in mijn normale leven, en het is bijna nul, maar ik heb zeker nog steeds mijn beste vrienden uit die tijd, dus ik zou het zeker weer doen. Wat studeerde u?
Het is een soort algemeen studieprogramma tussen sociologie, politiek, cultuur en economie voor het eerste jaar, en dan specialiseer je je - en ik specialiseerde me in bedrijfsmanagement en economie. Dat was in essentie mijn studie aan de Bodensee, en daarna ging ik voor een vrij standaard Master in Business Administration aan Copenhagen Business School voor mijn master.
En uiteraard tussendoor veel stages bij verschillende startups en verschillende bedrijven. Ik heb nooit gewerkt - en we spraken daar kort over vlak voordat we hier begonnen op te nemen - voor een groot bedrijf, dus ik heb in essentie geen ervaring met corporates en hoe het is om voor corporates te werken, en daarom denk ik dat ik doorlopend veel leer over hoe deze organisaties werken. Maar in het algemeen, ja, dat is in essentie wat ik studeerde. En wat deed u in uw eerdere banen?
Zoals ik al zei, deed ik veel stages bij verschillende bedrijven. Er was één bedrijf dat misschien interessant was voor deze podcast ook - dat was Climate-KIC. Ik deed een stage bij Climate-KIC.
Dat was op de EUREF Campus, waar uiteraard veel bekende Europese en Duitse bedrijven inmiddels zijn gevestigd, maar ja, toen hadden ze daar een green garage en ze huisvestten daar in essentie wat startups, wat erg spannend was en ik was
gewoon onderdeel van het team daar dat oprichters probeerde te helpen dingen gedaan te krijgen in essentie. Dat was misschien een interessante eerste stap, maar ik denk dat de eerste stap die echt relevant was voor mijn toekomstige carrière bij Project A Ventures was, waar ik in 2018 een stage deed. Het was erg intensief, en wat ik er geweldig aan vond is
je praat met mensen die enthousiast zijn over wat ze elke dag doen, omdat je met oprichters praat, en ik denk dat dat was wat ik in veel andere posities die ik eerder had gemist. Daarom besloot ik - aangezien ik bij InnoEnergy zat, dus ook de andere kick: Climate-KIC ging over bredere klimaatonderwerpen en InnoEnergy heel erg over energie - ik kon ook de energie van de oprichters die we ondersteunden voelen, dus ik kan me volledig in dat punt vinden.
Ja, precies. En toen besloot ik, oké, snelle omgeving, ik leerde veel, ik verveel me helemaal niet en de mensen om me heen vervelen zich niet, dus laten we wat meer tijd hier doorbrengen en in essentie voor durfkapitaalfondsen gaan werken. En dat deed ik 4,5 jaar lang, dus eigenlijk best wel lang. Altijd in de vroegste fases, dus in essentie startups die niets hadden, of bijna niets - in essentie de oprichters zelf en hun toewijding om iets groots op te bouwen - en proberen uit te zoeken: hebben ze kans om het werkelijk te maken, toch?
Superopwindende tijd. Wat leerde u, om dat te kunnen onderscheiden - en misschien is dat ook relevant vandaag voor uw zijn als oprichter? Ik bedoel, het is waarschijnlijk moeilijk om het zo te formuleren, maar ik denk dat één ding waarvan ik geloof dat ik het heb geleerd is dat veel startups - investeren in startups is in essentie investeren in een potentiële uitschieter, als in een bedrijf dat aanzienlijk meer geld oplevert dan welk ander bedrijf in de industrie dan ook.
Dus waar je in wilt investeren is iets dat het potentieel heeft om echt, echt groot te worden, toch? En ik denk dat je vrij snel leert dat iedereen een soort enorme stimulans heeft om dat te doen op basis van data en historische prestaties van andere bedrijven, maar veel van deze uitschieters volgen eigenlijk niet het normale pad van andere startups - want anders zouden ze niet iets anders doen en daarom geen uitschieter zijn, toch?
Misschien is dat te simpel gesteld, maar veel van de meest opwindende bedrijven worden denk ik gebouwd vanuit eerste principes, zonder te proberen een ander bedrijf na te bootsen. "Wij zijn de Airbnb voor het delen van telefoons" of zoiets, toch? Hoe waanzinnig saai, toch? Ik probeer niet te vloeken. Dus dat was een beetje wat ik voor mezelf leerde: denk tot op zekere hoogte voor jezelf, want hoogstwaarschijnlijk als je het durft om voor jezelf te denken, kan dit succesvoller zijn dan wanneer je dat niet doet, toch?
En ik denk dat dat een van de dingen was. Het andere was: het gaat zeker tot op zekere hoogte over hard werken en in staat zijn de context te begrijpen, maar veel van het starten en opschalen van een bedrijf is ook geluk en energie, toch - hoeveel energie ben ik in staat en bereid elke dag te investeren.
En ik denk dat dat ook iets is wat we hebben geleerd. Wat ik ook leerde door in durfkapitaal te werken - idee versus uitvoering, waarover ik zag dat u een punt had; ik weet niet meer of het in een blogpost was of in een social media post. Kunt u misschien toelichten hoe u dat in uw dagelijkse werk toepast? En dan komen we terug op hoe u het idee kreeg, en of u überhaupt van het oorspronkelijke concept bent gepivoteerd. Ja, ik ben altijd verbaasd hoe weinig we eigenlijk zijn gepivoteerd, eerlijk gezegd, maar we kunnen daar zeker over praten.
Maar ja, ik bedoel, u sprak over uitvoering, en ik denk dat onze visie hierop als RiDERgy-team zou zijn: wij zijn de uitdagers in een industrie, toch? Als startup kom je deze industrie binnen, je hebt in wezen geen logo, je hebt geen merk, je hebt geen team, en je hebt in het begin niet eens kapitaal. Eigenlijk is de hele wereld tegen je, toch? En het enige wat je mogelijk hebt is uitvoering, toch?
Want je zult altijd sneller zijn, je zult altijd sneller kunnen reageren, en je zult altijd meer geven om je bedrijf dan de bedrijven die tot nu toe de gevestigde partijen zijn, toch? En daarom bedoel ik, we maken veel situaties mee.
Bijvoorbeeld deze stealth-startups die uit stealth komen en zichzelf lanceren - ik heb dit nooit begrepen, toch, want vanuit ons perspectief draait het allemaal om uitvoering, en ik deel graag met iedereen in wezen wat we hier proberen te bouwen en alle geheimen die we hebben, toch. Want waar het op neerkomt is dat we beter moeten uitvoeren dan alle anderen, toch? En ik zie dat veel gebeuren in deze industrie. Bijvoorbeeld, we worden vaak gevraagd
om geheimhoudingsverklaringen te ondertekenen, wat iets is waar we open voor staan, en we hebben veel NDA's - ik moet altijd oppassen welke namen ik waar laat vallen - maar kortom, we hebben nooit een bedrijf om een NDA gevraagd, toch, om dezelfde reden: uiteindelijk zal uitvoering ertoe doen, en niet wie wat weet over geheimen die je over een idee hebt of zoiets. En wat is goede uitvoering voor u?
Als u bijvoorbeeld - de eerste dingen die bij u opkomen waarbij u zegt, ja, dit is zeker wat wij geloven dat goede uitvoering is die we elke dag in het team bevorderen. Ja, ik bedoel, misschien klinkt dat nu een beetje te makkelijk, maar wat dat is, is focus, toch. Weten wat je wilt bezitten in de waardeketen en dan 10x beter zijn dan alle anderen in het bezitten daarvan en het bouwen daarvan, toch?
En het klinkt makkelijk, maar in deze industrie - ik bedoel, we werken inmiddels, en we zullen daar waarschijnlijk later over spreken - met, hebben contracten met, of hebben in productie onboarded, zoals de overgrote meerderheid van de industrie, toch? Vooral in Europa. En iedereen heeft problemen, en we horen daar graag over, toch, want het is echt soms verrassend moeilijk om goede kwaliteitsfeedback te krijgen over wat het is dat we voor hen kunnen oplossen, toch?
En tegelijkertijd moeten we nee zeggen tegen 90, 95% van deze verzoeken en ideeën die we hebben, om ons te kunnen concentreren op wat we eigenlijk zelf willen uitvoeren, toch? En alleen als we deze focus echt kunnen realiseren kunnen we in de volgende stap daadwerkelijk uitvoeren, want dan weten we wat onze missie is, toch? En dus ja, mijn eenvoudige antwoord zou focus zijn. En misschien wat ik daaraan zou toevoegen is dat we een waanzinnig team hebben, toch? Dus dit is een team dat remote-first is voor het engineeringteam.
En in wezen hadden mijn medeoprichters en ik ongeveer 5 mensen in gedachten die we aan boord wilden halen toen we begonnen, zoals de dag nadat we onze eerste financieringsronde hadden getekend en wisten, oké, we kunnen wat mensen aannemen. We hadden in wezen 5 profielen in gedachten en 4 daarvan hebben we inmiddels onboarded. Dus voor ons is het tot op zekere hoogte het droomteam, en ik denk dat dat ook helpt om uit te voeren, toch, want iedereen duwt in dezelfde richting, en iedereen.
Pusht zichzelf, maar heeft ook een doelgerichte manier van samenwerken, toch? Dus we kunnen elkaar ook vertellen, oké, dit was niet goed, toch? En tot nu toe, ja, gewoon veel plezier hebben in het samenwerken. Ik denk dat dat het tweede punt is. Dus focus en plezier hebben in het werken met geweldige mensen. Begrijpelijk. Nee, ik kan me er volledig in vinden. En voordat we zo dadelijk diep ingaan op Inapi, hoe bent u - ik weet dat u voor Bonnet werkte - hoe bent u bij Bonnet of in de e-mobility-industrie terechtgekomen? Wat was het pad? Ja.
Ik bedoel, Bonnet - misschien kennen sommige mensen die naar dit luisteren het merk - Bonnet is een bedrijf, ik wil nu echt niet liegen, maar het is een EMSP die, denk ik rond 2020 of zo, werd gestart vanuit Imperial College London, door twee geweldige oprichters, Patrick en Elliott, die letterlijk vanuit een universitair project een EMSP begonnen omdat ze zeiden, oké, daarbuiten zijn er geen fancy EMSP's met een goed merk, toch?
En ik heb hen vrij vroeg leren kennen – ik denk ongeveer 4 tot 5 maanden na hun start – omdat ze funding aanvroegen bij het durfkapitaalfonds waar ik voor werkte, en ik een call met hen had. Uiteindelijk deden we de deal, een vrij kleine investering, en ik begon met het team te werken om het bedrijf op te bouwen, en in die tijd denk ik dat we behoorlijk wat tijd samen doorbrachten.
Ze hadden zeker moeite om de volgende financieringsronde binnen te halen enzovoort, en we hebben hard gewerkt om dat voor elkaar te krijgen. En toen ineens treedt er altijd een soort van inhaaleffect op, toch? Uiteindelijk wilde iedereen investeren omdat het bedrijf vrij snel groeide. Ze haalden geld op van Lightspeed en Google Ventures, behoorlijk bekende en gerenommeerde investeerders, en toen vroegen Patrick en Elliott me om fulltime aan boord te komen, en dat deed ik. Ik wil niet te veel ingaan op de details van wat er bij Bonnet gebeurde.
Het bedrijf werd iets later – ongeveer anderhalf jaar later – verkocht aan Over Energy, en tegenwoordig werkt het team als Overdrive, ook een geweldig team. Maar toen de overname plaatsvond, wist ik al dat ik niet voor een groot bedrijf in het Verenigd Koninkrijk wilde werken, en bovendien had ik dat connectiviteitsprobleem dat ze probeerden op te lossen met Inapi uit eerste hand ervaren, zowel vanuit commercieel oogpunt als tot op zekere hoogte vanuit technisch oogpunt. En daarom vertrok ik en begon ik Inapi.
Ja, en laat me dan misschien even wat context geven, de situatie schetsen, zodat we op dezelfde golflengte zitten. Het connectiviteitsprobleem, zoals ik het begrijp – en vul gerust aan of corrigeer me als ik iets mis – dat u identificeert is: er zijn heel veel spelers in de sector. We hebben CPO's, we hebben MSP's, dat zijn naar mijn mening de belangrijkste rollen. En onder de CPO's zitten CPMS'en, dus dat is de software die CPO's gebruiken.
En dan waren er traditioneel roaminghubs die waren opgericht om die verschillende spelers te verbinden. Ik weet niet precies hoeveel CPO's en MSP's er waren en er nu zijn, maar het is aanzienlijk. Misschien kunt u ons updaten als u de cijfers bij de hand heeft. En dus die connectiviteitslaag van traditionele hubs – dat is wat u identificeert – daar zitten nogal wat problemen in, of er zijn veel manieren waarop het beter kan, en dat is wat Inapi in wezen aan het bouwen is, toch?
En misschien kunt u nu wat gedetailleerder uitleggen. Ja, dus misschien allereerst – want ik denk dat we dat als sector niet vaak genoeg doen – laten we het vanuit het perspectief van de klant bekijken, toch, vanuit het perspectief van een EV-rijder. De EV-rijder wil accurate data over de beschikbaarheid van laadpunten, toch, en dan willen ze de laagst mogelijke prijs betalen. En zo werkt openbaar laden voor elektrische voertuigen vandaag de dag allerminst, toch? En nu kunnen we ingaan op: oké, waarom is dat zo, toch?
En ik denk dat je al vrij snel tot de conclusie komt: oké, er zijn veel verschillende bedrijven in deze sector. Zoals u al toelichtte, zijn er verschillende rollen, toch, zoals CPO, CPMS, EMSP, wat dan ook. Er zijn ook gefragmenteerde markten, dus er zijn veel verschillende CPO's en veel verschillende strategische belangen in de markt. Maar lang verhaal kort: deze bedrijven moeten op een efficiënte manier samenwerken om deze klantervaring daadwerkelijk op schaal te laten werken.
Bij Bonnet leerden we vrij snel dat dit niet op schaal werkt. We waren een heel klassieke EMSP en wilden in wezen met alle relevante CPO's in Europa verbinden. Destijds, in de zomer van 2022, waren er in wezen twee manieren om te verbinden. Wat ik legacy roaminghubs zou noemen – platforms die 14, 15 jaar geleden pioniers waren – die probeerden de communicatie tussen CPO's en EMSP's in de markt te standaardiseren.
Toen ik in deze sector begon, deden ze nog steeds ongeveer 80% van de integraties, maar al slechts 20% van de transacties, omdat de grote volume-integraties – de grote EMSP met de grote CPO – al bilateraal waren begonnen, bilaterale OCPI-integraties hadden gebouwd. En dat is in wezen de tweede optie: legacy roaminghubs en bilaterale OCPI-integraties. Bij Bonnet dachten we in het begin: oké, waarom niet met de hubs werken?
Het alternatief, zoals ik al zei, was bilaterale OCPI-integratie, dus Bonnet begon veel bilaterale OCPI-integraties te bouwen – ik denk meer dan 50. Wat ik me kan herinneren is dat gemiddeld zo'n 10 daarvan altijd down waren, en dat lag niet aan Bonnet. Ze hadden geweldige technologie. De reden was niet eens technische problemen maar meer operationele problemen.
Zoals: iets werkt niet, een of ander conflict werkt niet, sommige tokens waren niet gesynchroniseerd, een kleine interpretatie van de OCPI-protocolimplementatie werkte niet. En dan heb je de andere persoon aan de andere kant nodig om dat te debuggen.
Laten we daar even stoppen, want ik denk dat het misschien niet zo duidelijk is voor iedereen die geen diepgaande IT-integratiepersoon is. Er zijn twee kanten aan deze integratie – twee systemen die moeten integreren en twee softwarelagen die moeten integreren.
Er is een protocol – OCPI – en ik denk dat er nog een paar meer zijn, maar de hubs beheren die protocollen. Corrigeer me als ik het mis heb, maar OCPI is, laten we zeggen, het vrije onafhankelijke protocol. En daarin, zoals in veel andere protocollen – en ik denk dat OCPP met hetzelfde probleem kampt, waar de lader met het charge point management system praat, maar dat is niet echt de kernfocus van deze podcast – is er de kwestie van de interpretatie en de implementatie van het protocol.
Als één stakeholder de boel verprutst, dan gaat het mis. Druk ik het zo correct uit? Min of meer, precies. Dus laat me misschien een klein historisch overzicht geven – en ik ga zeker op sommige punten de fout in. Ik zit vijf jaar in deze sector, en ik denk dat ik het inmiddels vrij goed begrijp, maar destijds had ik geen idee wat er daarvoor gebeurde.
Maar lang verhaal kort: er zijn deze platforms die destijds probeerden de communicatie te standaardiseren, zoals ik al zei, als pioniers in deze sector. En ze begonnen
die in wezen protocollen definieerden om het te standaardiseren. Dus Hubject kwam met OICP – misschien was er iets vóór, maar dat is wat we kennen. Gireve kwam met eMIP, ik geloof dat e-Clearing met OCHP kwam, voornamelijk vanuit Nederland. En ik denk dat omdat mijn medeoprichter Dennis Lauman een van de oorspronkelijke auteurs van OCPI was, er deze bereidheid was, vooral onder laadpuntoperators, om onafhankelijk te worden en in wezen een protocol te lanceren dat onafhankelijk is van deze commerciële, niet-neutrale spelers.
Daarom werd de EV Roaming Foundation opgericht – wij maken vandaag deel uit van de EV Roaming Foundation, net als veel andere relevante spelers in deze sector. Wat de EV Roaming Foundation doet, is mensen samenbrengen om de OCPI-standaard te definiëren. De meest relevante OCPI-versies vandaag zijn OCPI 2.1.1 en 2.2.1. Er is OCPI versie 2.3.0, al gelanceerd en geïmplementeerd door zeer weinig spelers – ik bespreek dat graag in detail. Maar in essentie is OCPI het antwoord van veel
CPO's die onafhankelijk wilden worden van propriëtaire protocollen. Dus dat is het kernprotocol voor open source, en uiteraard hebben de platforms die ik zojuist noemde inmiddels OCPI overgenomen. Vanuit ons perspectief wordt het zeer zeker de standaard – niet alleen in Duitsland of Europa, maar eigenlijk over de hele wereld. Ik las onlangs een statistiek dat meer dan 95% van de openbare laadpunten buiten China daadwerkelijk OCPP-data communiceert, en de overgrote meerderheid van die laadpunten zou ook het OCPI-protocol kunnen gebruiken.
Dus dat is, denk ik, de samenvatting op hoofdlijnen van deze protocollen. En OCPI – om gewoon uw vraag te beantwoorden – werd aanvankelijk gelanceerd met het idee om bilaterale integraties te bouwen. Nu denk ik dat u in uw inleiding al zei dat de markten voor laadpuntoperators en EMSP's gefragmenteerd zijn. Er zijn honderden spelers aan beide kanten van deze markt, en als u 3 spelers aan de CPO-kant zou hebben en 3 aan de EMSP-kant, is het vrij eenvoudig: iedereen verbindt met elkaar en u heeft 9 integraties.
Nu, als u 500 spelers aan de MSP-kant heeft en 500 spelers aan de CPO-kant, dan zijn het 250.000 bilaterale integraties. En ik denk dat u daar al begint te begrijpen: oké, dit zijn allemaal integraties die een handshake nodig hebben, ze moeten worden opgezet, ze moeten worden getest, en dan moeten ze worden onderhouden. En nu hebben we het over veel verschillende versies van OCPI die uiteraard niet interoperabel zijn met elkaar. Dus het wordt heel, heel rommelig, heel, heel snel – laat ik het zo stellen.
Dus ik denk dat waar de sector mee te maken kreeg – om terug te gaan naar toen ik de sector binnenkwam – in wezen was: ik geloof dat connectiviteit een commodity zou moeten zijn, een vrij beschikbaar goed, maar in werkelijkheid is het een constante pijn, enzovoort.
En dat is de belangrijkste reden dat wij bij Bonnet moeite hadden om een echt goede klantervaring te leveren, en het grootste deel van de kosten kwam daarvandaan – zelfs indirecte kosten. Bijvoorbeeld, klantenservicekosten werden gecreëerd door precies deze connectiviteitsproblemen, en daarom zei ik: oké, er moet een betere manier zijn om dat te doen, en begon naar andere sectoren te kijken.
Ja, het was zomer '22 toen ik contact opnam met mijn twee medeoprichters en in wezen begon na te denken over hoe een model eruit zou zien dat de enorme voordelen van één enkele integratie zou samenbrengen en tegelijkertijd goede datakwaliteit zonder significante transactiekosten. Het antwoord daarop ligt in AI, maar ik denk dat we daar nu op ingaan. Ja, laten we erin duiken.
Dit is een apart segment, maar zoals u de medeoprichters noemde – één ding dat mij trof, ook omdat het mij persoonlijk gesproken veel tijd kostte om mijn medeoprichter te vinden – vind ik dat vooral het vinden van technische medeoprichters, aangezien wij beiden CEO's zijn, zeer moeilijk is. En u slaagde erin, als ik het me goed herinner, u had één persoon in gedachten.
Met wie u echt het bedrijf wilde oprichten, en het blijkt dat deze persoon ja zei, wat behoorlijk indrukwekkend is – of ongelooflijk. Hoe ging dat verhaal? Kunt u uitweiden over de matching van medeoprichters, die zo belangrijk is als fundament voor het bedrijf? Ja, dus ik bedoel, ik had het probleem ervaren. Ik had veel roamingcontracten onderhandeld. Ik had geprobeerd veel problemen met connectiviteit aan de commerciële kant tot op zekere hoogte te escaleren.
Maar ik wist wat we niet zouden willen bouwen; het was niet superobvious voor mij of we het zelfs zouden kunnen bouwen zoals ik het me had voorgesteld. Dus wat ik als allereerste stap deed, was in wezen een memo samenstellen – misschien een beetje oude investeerdersmentaliteit, maar een memo over wat dit bedrijf zou doen, ongeveer 5 pagina's of zo. Ik moet het weer opzoeken; het staat ergens op mijn computer. En ik stuurde dit in wezen naar, denk ik,
vier of 5 mensen. Om eerlijk te zijn, deed ik gewoon cold outreach. Ik zocht letterlijk op GitHub op wie het OCPI-protocol schreef, en wat u dan vindt – ik hoop dat ik deze namen hier mag noemen – is in wezen Olga Vanier, Patrick Rademakers en Dennis Lauman. Altijd onder de drie namen die de peetvaders zijn.
Dat vind ik geweldig – dat komt waarschijnlijk uit een van mijn pitchdecks – de peetvaders van OCPI, ja, precies. En ik wilde eigenlijk met alle drie spreken. Ik sprak ook met Olga, maar toen ontmoetten Dennis en ik elkaar en hadden een grappige, toevallige tweede ontmoeting in Aken bij een e-clearing-evenement.
En ik kan me gewoon herinneren dat we allebei al behoorlijk enthousiast waren over de memo, en we gebruikten die twee dagen in Aken in wezen om onszelf op te sluiten in een kamer en na te denken over hoe dit gebouwd kon worden en hoe we dat konden doen. Nu, Dennis was toen nog managing partner, denk ik dat ze hem zo noemden, bij Ihoma – ik denk een van de toonaangevende techconsultancies in de sector. Hij had al veel CPMS'en gebouwd en had daar ook een echt getalenteerd team, en daarom was het niet makkelijk voor hem om eruit te stappen.
Voor mij was het vrij duidelijk dat ik dit bedrijf wilde oprichten. In wezen werkten we zo'n 3–4 maanden behoorlijk intensief naast onze dagelijkse banen, en toen kwamen we op een punt waarop ik zei: oké, laten we dit 3–4 maanden proberen. Als we niet tegen eind Q1 '23 financiering binnen hebben, ga je terug naar je baan. En zo zijn we begonnen. Ik denk dat veel investeerders altijd zeggen dat een oprichtersteam waarbij de oprichters elkaar niet kennen van het dagelijkse werk, of waarbij ze geen vrienden zijn, in wezen risicovol is.
En we hadden zelfs die ene man die nee zei in onze eerste ronde, terwijl we veel investeerders hadden die wilden investeren maar nee zei vanwege precies die vibes - zoals dat we elkaar niet goed genoeg kenden - en we overwogen hem elk jaar een kerstkaart te sturen. We werken nu samen omdat we zo hecht zijn. Dus lang verhaal kort: Dennis is geweldig. Hij is gevestigd in Nederland, en daarom was het voor mij altijd 100% duidelijk dat we dit remote first zouden opbouwen.
We proberen het commerciële team in Berlijn aan te nemen, maar al het andere is min of meer remote first. Maar nee, het is echt zoals op de eerste dagen vertrouwen we elkaar, houden van elkaar, en ja, we hebben nu veel samen meegemaakt, dus behoorlijk enthousiast erover. Zeer cool achtergrondverhaal ook - ik denk inspirerend voor oprichters daarbuiten. En dus zei u dat u het bedrijf min of meer eind 2022 oprichtte.
Juist, ja, dus we hebben het bedrijf officieel opgericht denk ik januari '23, en we hadden de termsheet al getekend - in wezen hadden we met investeerders gesproken in december '22. Dus ja, het ging supergnel. Het was letterlijk twee weken nadat we begonnen met fondsenwerving; we hadden zo'n vijf, zes termsheets en moesten beslissen. En toen haalden we de allereerste financieringsronde letterlijk op basis van een pitch deck op, met Project A Ventures en Seedcamp uit Londen.
Ja, en dat was een ronde van 2,5 miljoen, toch? En toen was januari '25 een ronde van 7,5 miljoen. Ja, dus ik denk aangekondigd - ik denk dat dat min of meer besproken werd in november, december - sorry, nee, 2023. Ja, krijg ik dit nu goed? Nee, '24 natuurlijk - dit was januari '24, sorry. We zaten de hele tijd een jaar ernaast. Dus januari '24 lanceerden we, en in januari '24 kondigden we ook onze pre-seed ronde van 2,55 miljoen aan.
En toen kondigden we in januari '25 onze seed ronde van 7,5 miljoen aan die we hadden afgesloten in december '24. Dus in wezen 10 maanden nadat we onze eerste ronde ophaalden, haalden we een aanvullende ronde op. Ja, de tijd vliegt. En toen las ik dat u 600.000 laadpunten aangesloten had tegen eind 2025, maar nu denk ik dat het meest recente bericht al zoiets als 850 was.
Om eerlijk te zijn, geen hard feelings omdat het snel gaat, maar als dit uitkomt kan ik dat al zeggen - we kondigen nu een miljoen laadpunten aangesloten in productie aan. En eigenlijk zitten we al op 1.050.000, dus ja, we groeien gewoon supersnelt. We hebben meer dan 450 partners onboard sinds we begonnen. Dat is gemiddeld, als u dat uitrekent over 2,5 jaar, iets meer sinds we begonnen met onboarden, ruwweg 2 per week of zoiets, iets meer.
En dat is letterlijk met één teamlid die dat voornamelijk doet - natuurlijk kunnen anderen ook helpen, maar in wezen één persoon die min of meer fulltime test, onboard en duwt aan de technische kant, en de rest is grotendeels geautomatiseerd. Ik denk dat dat een van de redenen is waarom we zo snel konden groeien. De timing was perfect toen we begonnen: het was letterlijk precies het moment waarop mensen de legacy roaming hubs beu waren.
Ze liepen tegen problemen aan met het bouwen van bilaterale integraties, en ze hadden een OCPI-ready API, dus in wezen konden we ze meteen verbinden zonder enige significante wrijving. En natuurlijk, bij het bouwen van 450 handshakes kom je veel - ik wil niet oordelen, maar - misschien een beetje vreemde interpretaties en implementaties van OCPI tegen. Dat is het grote probleem met OCPI: het is in wezen op veel verschillende manieren implementeerbaar, laten we het zo zeggen.
En we hebben workarounds gebouwd, dus inmiddels zien we zelden implementatietijden van meer dan één tot twee weken. Misschien is dit een domme vraag, maar omdat ik hier niet zo diep in zit zal het interessant zijn om het beter te begrijpen. Dus fundamenteel kan de API-kwaliteit van een van de stakeholders de boel verprutsen. Door uzelf ergens tussen de stakeholders te positioneren en ervoor te zorgen dat de connectiviteit goed werkt - toch, als één stakeholder het verprutst, hoe voorkomt u die mess-ups?
Bent u in staat ze sneller te identificeren, of hoe is uw rol - zeg maar - hoe maakt u mogelijk dat de mess-ups niet voorkomen? Ik denk dat de voor de hand liggende, misschien laaghangende-vruchten waardepropositie die we hier hebben is dat u niet langer 450 handshakes doet, u doet er één - met RiDERgy - en dan kunt u van daaruit in wezen schalen zonder enige aanvullende technische overhead.
U gaat gewoon naar ons portaal, klikt op "Ik wil hen een aanbod sturen," stuurt hen een aanbod, en als ze accepteren, worden uw POI-data als CPO naar de MSP gepusht en kunt u de tokens van de EMSP pullen - superstraightforward, zeer weinig technische overhead. Maar om uw vraag te beantwoorden, ik denk dat dit belangrijk is: we spelen een enorme rol in het harmoniseren van de OCPI API's van onze partners. OCPI is opgebouwd uit verschillende modules, en niet elke afzonderlijke module is noodzakelijk om een verbinding te laten werken.
Dus toen we begonnen hadden veel van onze partners bijvoorbeeld de zogenaamde tarieven module nog niet geïmplementeerd, dus ze hadden in wezen moeite om de tarieven automatisch met elkaar te communiceren. Dit creëert wrijving, en daarom wat we iedereen altijd min of meer motiveren te doen is om eigenlijk het volledige OCPI-protocol te implementeren. Dat gezegd hebbende, denk ik dat we een grote rol spelen in het harmoniseren in die zin dat veel EMSP's ons vertellen dat ze aanzienlijk betere succespercentages hebben binnen NAP dan dat ze hebben in bilaterale OCPI-integraties.
En ik denk dat dat contra-intuïtief is, toch? Veel mensen in de sector zeggen: maar ik voeg een extra partij toe in de keten, dat zal meer wrijving veroorzaken, er is nóg een partij – maar zo werkt het in de praktijk gewoon niet. Wij hebben een zeer geavanceerd alarmeringssysteem, meer dan 90% van onze klantinteracties zijn uitgaand en niet inkomend. Wij zijn dus degenen die de data opschonen en partners helpen om hun zaken op orde te krijgen.
En als volgende stap zien wij daardoor veel zeer succesvolle transacties. Een ander probleem dat u vaak ziet bij bilaterale integraties is bijvoorbeeld dat sync-jobs falen. Een bepaalde token komt niet aan bij de CPO en daarom kan de sessie niet geautoriseerd worden wanneer de token daar probeert te laden, of een bepaalde EVSE staat om de een of andere reden niet in de mobiele applicatie van een EMSP, en u vraagt zich af waarom.
Wat wij partners helpen te doen is inzicht te krijgen in het succes van hun sync-jobs, en flexibiliteit te krijgen in hoe zij willen synchroniseren – willen zij de data pushen of pullen, wanneer willen zij dat doen, wat is de frequentie, enzovoort. Al deze dingen helpen de hele sector om de connectiviteit te stroomlijnen. En ik denk dat de reden waarom ik hier zoveel nadruk op leg is: NAP is vanaf dag één niet gebouwd om de legacy hubs te vervangen.
Wij groeien ook deels doordat mensen van hen migreren, maar onze meest directe concurrentie zijn niet deze legacy hubs. Onze meest directe concurrentie zijn bilaterale OCPI-integraties, want daar zitten de grote volumes, en onze ambitie is dat 100% van de volumes van één specifieke CPO of EMSP wordt gemigreerd. Nu weet ik natuurlijk dat dit tijd en veel vertrouwen in de sector gaat kosten. Maar hiervoor zijn wij er, en zo hebben wij NAP vanaf dag één gebouwd.
Het is dus super belangrijk voor ons dat bijvoorbeeld de succespercentages voor NAP-integraties hoger zijn dan in een bilaterale setup, en dat mensen begrijpen dat dit eigenlijk de nieuwe normaal is voor de toekomst. En wat ook super belangrijk voor ons is, is dat wij de eerste bilaterale integraties zien migreren naar NAP – het is één ding om alle logo's te onboarden, maar het is iets anders om ze alle integraties naar NAP te laten migreren, en daar komen wij nu.
En één belanghebbende of verbindingstype waar wij nog niet over gesproken hebben, die volgens mij vrij gangbaar is in de sector, zijn de platforms – waarvan ik denk dat het voornamelijk de backends zijn, de CPMS'en – die ook integraties faciliteren. Hoe kijkt u naar dat type belanghebbende, en misschien kunt u zelfs zeggen welk aandeel van de integraties via platforms gebeurt en welk aandeel via bilaterale roaming hubs en nu in NAP? Dat is een goede vraag. Nee, als het moeilijk is, ik weet dat ik soms gewoon te ver vooruit loop.
Wat in mij opkomt als ik daaraan denk is onze pitch deck voor de pre-seed ronde in januari '24. Dat was in feite waar wij een beetje een klantsegmentatie deden, en wij zeiden in wezen dat de charge point operator-kant – de aanbodzijde, als u wilt, in ons model – kan worden opgesplitst in drie verschillende groepen bedrijven.
De eerste is strategische multinationale spelers: olie- en gasbedrijven, nutsbedrijven, autofabrikanten, OEM's – in wezen bedrijven die een strategisch belang hebben in deze markt, die zeer diepe zakken hebben en de neiging hebben om wat traag te bewegen, hoewel wij van allemaal houden waarmee wij samenwerken. De tweede categorie is in wezen waarschijnlijk de meest capabele spelers in de sector vandaag, en dat zijn de door infrastructuurfondsen ondersteunde joint ventures en startups in deze sector.
Zij zijn echt goed in het benutten van hun data, zij zijn echt geïnteresseerd in het optimaliseren van hun processen. Goede voorbeelden daarvan zijn de Charging League, Fastned, Atlante, Ionity, Electra, Power Dot – dat soort spelers komen in mij op.
Deze spelers hebben vaak niet de grootste netwerken, maar zij hebben veel transacties omdat zij echt hoogwaardige netwerken zijn, en omdat zij echt snel schalen. En dan is de laatste categorie volgens mij de lange staart die wordt geaggregeerd via charge point management systems. Dus precies – en hoe dat eruitziet is.
Deze charge point management systems treden op als de contractuele partner met EMSP's, dus voor ons zijn zij de CPO, als u het zo wilt bekijken, omdat zij de roaming-contracten met de EMSP hebben en zij in wezen ook de MSP's factureren en daarna het geld verdelen tussen de CPO's. Voor ons is de belanghebbende of de speler waarmee wij geïntegreerd zijn het charge point management system. Zij hebben ook het account bij NAP als zij de contractuele partner voor de MSP zijn.
Waar wij dus altijd naar kijken is: het maakt ons echt niet uit wie u in wezen bent. Bent u de partij in het roaming-contract? En als u dat bent, bent u onze klant. Wij werken met veel CPMS'en – wij hebben inmiddels partnerschappen aangekondigd met min of meer allemaal, wij staan zeer dicht bij hen. Ik wil niet liegen, maar ik denk dat er geen CPMS is waarmee wij geen enkele integratie hebben in Europa. Uiteraard kunt u de CPMS'en opnieuw segmenteren in wat oudere, wat langzamer bewegende startups enzovoort.
Ik wil dat nu niet doen omdat, zoals ik al zei, wij met allemaal samenwerken, maar er is veel geweldige technologie en veel geweldige bedrijven en mensen waarmee wij daar samenwerken. En in wezen, als ik het goed begrijp, wanneer u spreekt over het integreren tussen CPO's en MSP's, integreert u de CPMS-implementatie van OCPI, toch? Precies. Ik bedoel, de CPO's hebben hun eigen complexiteit. Er zijn CPO's die hun eigen CPMS bouwen – er was een beetje een trend misschien twee of drie jaar geleden.
Dan zijn er CPMS'en die slechts charge point management systems zijn, dus in wezen software-as-a-service bedrijven, en zij bezitten nooit de roaming contracten. Vanuit ons perspectief, vaak in het belang van de CPO, zijn er dan sommige CPMS'en die in wezen een lange geschiedenis hebben in het uitvoeren van de volledige financiële clearing en het hele zware werk voor hun CPO-klanten. En ze hebben allemaal bestaansrecht.
Het is dus echt complex, maar u heeft gelijk - uiteindelijk hebben wij technische integraties en daarom verbinden we met charge point management systems. Maar zoals ik al zei, er zijn heel grote charge point operators die hun eigen charge point management system hebben, en er zijn heel kleine charge point operators die ook hun eigen charge point management system hebben, dus deze markt heeft allerlei verschillende smaken. En over het businessmodel gesproken, ik denk dat u er al op zinspeelde: connectiviteit zou gratis moeten zijn.
Dus ik begrijp dat dit ook een fundamenteel verschil is tussen EAI of andere belanghebbenden die hetzelfde proberen te doen als EAI, waar connectiviteit niet gratis is. En ik begrijp dat uw businessmodel volledig gebaseerd is op de financiële clearing. Misschien kunt u dit clearing-aspect uitwerken en hoe u het beter doet dan andere belanghebbenden die zich op de clearing-aspecten richten.
Ik denk dat ik daar kort op zinspeelde: vanaf dag één - en daar ben ik altijd verbaasd over dat we onze identiteit en missie sinds dag één niet echt hebben veranderd - vanaf dag één was onze ambitie om bilaterale directe integraties, directe OCPI-integraties, te vervangen, omdat ze voor ons bij Bonnet niet op schaal werkten. Sommige mensen vertellen ons dat ze werken, sommige mensen zeggen dat ze helemaal niet werken.
Maar om het kort te houden, als u kijkt naar succespercentages en alles wat erbij komt kijken, zou connectiviteit een commodity moeten zijn. En het is vandaag geen commodity, omdat iedereen een tech-team heeft zitten die data controleert, iedereen bouwt zijn eigen enigszins gebrekkige validaties in-house, ze moeten naar charge detail records kijken en in wezen relevante transactiedata bouwen om te analyseren - en dit alles werkt niet.
En wij zeiden altijd dat we product willen bouwen voor 100% van de volumes van een CPO of EMSP, niet voor de long tail. En als u dat zegt, moet u kijken naar waarom ze 80% van hun transacties via bilaterale integraties brokeren. Voor ons is de reden vrij duidelijk: aanzienlijke transactiekosten. Als u transactiekosten in rekening brengt voor connectiviteit, dan hebben mensen een stimulans om bilateraal te gaan. Want zelfs als u maar 5 cent per sessie in rekening brengt -
- bij 1 miljoen laadtransacties per maand, is er een vrij duidelijke significante stimulans om bilateraal te gaan. En daarom zal er vanuit ons perspectief in een massale markt in de toekomst geen connectiviteitskosten zijn. Niemand die connectiviteit in rekening brengt zal in de toekomst kunnen winnen. Ik denk dat dit een beetje verrassend was voor de markt 2,5 of 3 jaar geleden toen we begonnen, maar inmiddels is de overgrote meerderheid van de markt het daarmee eens.
En dan is de voor de hand liggende vraag: hoe doen wij connectiviteit, want, zoals al gezegd, bilaterale integraties schalen niet? Dus hoe doen we connectiviteit, en wat is het op één na grootste probleem? Ik denk dat ons antwoord daarop is: laat ons connectiviteit commoditiseren, maak het een vrij beschikbaar goed, zorg ervoor dat iedereen die zelfs maar één engineering-uur investeert in interne connectiviteit die ze niet zouden hoeven te investeren, in wezen tijd en geld verspilt - omdat ze zouden moeten investeren in iets waar ze onderscheidend vermogen kunnen opbouwen.
Het is een commodity, het is gratis, toch? En laten we dan kijken naar het op één na grootste probleem, en vanuit ons perspectief is het op één na grootste probleem financiële clearing. CPO's hebben het erg moeilijk om in wezen betaald te krijgen, en EMSP's hebben het erg moeilijk om charge detail records te valideren, relevante transactiedata te openen, vervolgens facturen goed te keuren en ze op schaalbare wijze te betalen, toch? De grootste EMSP's daarbuiten, zij ontvangen ongeveer 450 facturen per maand, toch?
En eigenlijk niet elke maand, maar om de 2, 4, 6, 8, 12 weken, soms met CDR's, zonder CDR's, verschillende valuta's, verschillende BTW-tarieven. Het is rommelig, en dit is wat wij hier aanpakken. Waarom hebben we nu een unfair advantage om dat op te lossen? We hebben alleen een unfair advantage om dat op te lossen als we daadwerkelijk de transactie brokeren, toch? Want wat we kunnen doen is dat we de transactie op een ander niveau kunnen valideren dan horizontale spelers die dit in veel verschillende sectoren doen, toch? Omdat we naar de charge detail records kunnen kijken die gefactureerd worden en kunnen zeggen:
hé, er staan enkele CDR's op waar we de sessie niet hebben geautoriseerd, dit is niet gebeurd - of we kunnen zeggen, hé, er ontbreken enkele CDR's, of er zijn enkele dubbele CDR's met verschillende CDR-ID's, maar we weten dat omdat we de sessie hebben geautoriseerd, toch? En er zijn miljoenen details die we kunnen valideren, maar om het kort te houden, alleen omdat we de transactie brokeren kunnen we daadwerkelijk het beste financiële clearing-product daar maken. Onze sterke overtuiging is dat de overgrote meerderheid van de markt
hun financiële clearing in de toekomst niet zelf zal doen. Op dit moment zijn het gebrekkige, in-house processen gebaseerd op CSV-bestanden enzovoort waar we met ons financiële clearing-product tegen concurreren. Maar in de toekomst gaat dit complexer worden omdat we variabele prijzen zullen hebben, we zullen kortingen hebben - er zijn veel dingen die complexiteit toevoegen.
En het heeft geen zin dat 450 bedrijven in Europa hun eigen oplossing in-house bouwen, toch, en dit is waar wij binnenkomen. Dus de clearing wordt meestal in-house gedaan, of er zijn derde partijen die het doen met, laten we zeggen, legacy tech - dat zou de
Ik wil niet zo oordelend zijn over legacy-technologie, maar wat ik wel kan zeggen is, zoals altijd – en ik denk dat dat een rode draad is in ons gesprek tot nu toe – dat er natuurlijk van alles is in deze sector: mensen die het zelf doen, mensen die het doen met willekeurige bedrijven van buitenaf, mensen die het gewoon helemaal niet doen en in wezen facturen betalen zoals ze binnenkomen en niets valideren, toch?
Er is dus echt van alles – we zijn alles tegengekomen. Maar het is zeker een duidelijk probleem waar iedereen mee te maken heeft, en u kunt met elke CPO en EMSP daarbuiten praten, ze zullen het ermee eens zijn dat de validatie van factureringsrelevante transactiegegevens, vervolgens de goedkeuring van betalingen en dan de betalingen zelf superhandmatige processen zijn.
Ja, dat kan ik ook bevestigen uit gesprekken die ik heb gevoerd. En u noemde een indrukwekkende KPI: 99,998% uptime en onder de 20 milliseconden latency in 2025, wat behoorlijk indrukwekkend is. Hoe kunt u zulke geweldige KPI's bereiken? Ik begrijp dat dat is waarmee u concurreert tegen legacy-technologie – sterke argumenten om uw technologie te adopteren. Ja, dus ik denk dat wat zeer waar is en een gemakkelijk argument is, een ongelooflijk getalenteerd team is, toch?
We zijn nog steeds een heel klein team, en daar zijn we ons zeer van bewust, toch? We geloven dat als we een tussenpersoon zijn en geen connectiviteitskosten willen rekenen, we dit kunnen bouwen met een heel lichtgewicht team. Tegelijkertijd hebben we ongelooflijk talent in het team. Het andere eerlijke antwoord is, in tegenstelling tot de legacy hubs waarover ik net sprak,
zijn we niet 14 jaar geleden begonnen – we zijn in 2024 begonnen. Onze cloud-infrastructuur is waarschijnlijk het hart van ons product; het is state-of-the-art technologie, en zo kunnen we dat bereiken. Ook, één ding dat ik wil delen is dat, in tegenstelling tot de meeste spelers daarbuiten, we eigenlijk onze uptime te allen tijde publiceren, dus iedereen kan naar status.api.com gaan en de uptime van onze infrastructuur zowel in de VS als in Europa zien.
We houden onszelf verantwoordelijk door dit openbaar te maken, en tot nu toe werkt dit echt goed. Superhappy met het team, en ik denk dat daar veel redenen voor zijn – er komt eerlijk gezegd veel werk bij kijken. En ook veel AI. Aangezien het de naam van het spel is, houdt het me elke dag bezig. Hoe kijkt u naar AI als, waarschijnlijk, een AI-native bedrijf?
Dus, ten eerste, ja, toch. Ik denk – ik zou het nog een keer moeten opzoeken – maar ik geloof dat sinds ongeveer 15 of 16 januari 2026, toen een nieuw model van Claude werd gelanceerd – Sonnet, was het? Ja, zoiets. Hoe dan ook, ik denk dat meer dan 94% van onze productiecode door AI is geschreven. Het heeft ons natuurlijk enorm versneld, en dit helpt zeker, toch?
Wat ik ook zal zeggen is: we zijn niet uw volgende AI-raketbedrijf dat gewoon alles wat op hun pad komt in een pull request gooit en laat gaan, toch? En daar is een heel goede reden voor. Als u in wezen vertrouwen wilt opbouwen bij grote bedrijven als een bedrijf, als een startup, is het enige waar ze naar zullen zoeken: werkt dit product, toch?
En u kunt het u gewoon niet veroorloven, als u infrastructuur-relevant bent voor CPO's en EMSP's en dat is direct ROI-relevant, om 20 minuten of een uur down te zijn zoals de legacy hubs soms zijn. Dit is gewoon iets wat we ons als startup niet kunnen veroorloven. En daarom zijn er delen van ons product – en onze engineers zijn zich daar zeer van bewust – die we alleen met de grootste zorg aanraken, en waar AI nuttig is maar duidelijk niet een soort vervanging is voor de echt belangrijke tweede, derde en vierde blik van mensen, toch?
Dus dat is de ene opmerking, maar ja, AI is zeker een enorm onderwerp voor ons, dat ons duidelijk in staat stelt. En dan, misschien last but not least, aan de commerciële kant – het is gek, toch? Ik bedoel, vandaag besteedt een van mijn medeoprichters veel tijd aan product, maar hij is ook vrij betrokken bij klanten. Maar daarbuiten ben ik het en onze nieuw aangenomen Director of Growth, Dennis Daniel Brown, voorheen van ChargePoint.
Hij handelt onze commerciële scaling af. Dus inmiddels werken we met de grote meerderheid van de sector, maar we hebben geen gekke outbound-campagnes gedraaid om hen te bereiken, omdat het gewoon niet werkt. Ik was min of meer alleen aan de commerciële kant, en AI helpt veel. Dus dat is een andere dimensie. Maar daarmee – wie in het verleden nog nooit met mij heeft gesproken, neem alstublieft contact op, vooral CPO's en EMSP's.
We zijn soms verrast door sommige spelers, vooral in de Spaanse regio, Frankrijk, maar ook in de Nordics, die nog nooit van ons hebben gehoord en een beetje zijn van "ah, oké, dit klinkt interessant" – en wij zijn dan van, ja, prima, laten we praten. Dus ja, ik zou graag willen praten. En u zei in het verleden dat er een probleem is met samenwerking in de sector, dat u vindt dat we meer zouden moeten samenwerken. Wat bedoelde u daarmee?
Om eerlijk te zijn weet ik niet in welke context ik dat zei. Ik ben soms verrast door hoe open mensen staan voor samenwerking, maar ik denk dat er heel weinig alternatieven voor ons zijn. De meeste bedrijven zijn niet zoals Tesla, dat in wezen een full-stack oplossing heeft van hardware tot charge point operator tot CPMS tot EMSP tot in wezen een auto, stekker en lader, enzovoort. Er is alleen Tesla, in wezen. En verder moeten mensen samenwerken en coöpereren, dus ik denk niet dat het echt een optie is om dat niet te doen.
Dus ja, niet zeker wanneer ik dat zei, maar ik ben het ermee eens – zoveel mogelijk samenwerking is nuttig voor de sector, denk ik. En toen was er een post die u maakte, en misschien kunt u in uw eigen woorden weer uitleggen: het is "grootte van de taart boven deel van de taart," als u zich uw blogpost herinnert. Ja, dus vanuit ons perspectief – en om eerlijk te zijn, ik kan dit voelen in de grote meerderheid van de gesprekken die ik voer – als de sector wint, wint iedereen. En dat is onze mindset. We proberen geen concurrent te verslaan. Diesel is de vijand.
Ja, precies. Diesel is de vijand. De Tankerkarte is de vijand in Duitsland. Uiteindelijk willen we een rol spelen in het mogelijk maken van de groene mobiliteitsrevolutie, en we zijn er gewoon nog niet. Ik bedoel, 17% groei klinkt goed voor een ouderwetse industrie, maar verdorie – we moeten deze transformatie laten slagen.
En als de hele industrie daarop gericht is, zullen we het veel sneller voor elkaar krijgen en zal iedereen daarvan profiteren. Dat is wat ik daarmee bedoel. We optimaliseren niet om, weet ik veel, een ander bedrijf te vernietigen of een specifiek percentage te veroveren – we willen er gewoon voor zorgen dat we daadwerkelijk de connectiviteit voor de industrie oplossen om hem te helpen opschalen.
En ik denk dat deze mindset ons tot nu toe behoorlijk heeft geholpen om de juiste dingen te doen. Dat is vaak logisch. En laten we het dan over prijsstelling hebben, wat ook een onderwerp is waarin ik bijzonder geïnteresseerd ben in de smart charging- en flexibiliteitsruimte, wat als laatste stukje aan bod zal komen. U schreef er ook over – dat er verschillende hefbomen zijn waar laadpuntexploitanten mee kunnen spelen: volume-incentives, vlootkortingen en andere soorten toeslagen op verkeersroutes naar aggregators.
Misschien kunt u uitleggen wat uw visie is op de toekomst van prijsstelling, die op dit moment – dat weet waarschijnlijk iedereen – nog vrij statisch is. Het is meestal afhankelijk van laadsnelheid; als het een DC-lader is, is het meestal hoger, maar niet te veel dynamische tarieven. Waar ziet u de industrie naartoe gaan? En misschien ook, als overgang naar flexibiliteit, hoe zou de ideale prijsstelling eruitzien, als u daar gedachten over heeft?
Ik hoorde onlangs een statistiek – en een toespraak, of het Museum sprak over het ministerie van Transport, of hoe het ook heet – over flexibiliteit. Dat zou spannend zijn, veronderstel ik, toch? En ik had een beetje die Angela Merkel "internet"-herinnering. Ik weet niet of u begrijpt wat ik bedoel, maar in wezen is het voor ons vrij duidelijk, toch? Ik las een statistiek – ik moet dit nog eens opzoeken – maar zoiets als 75% van de batterijcapaciteit tot 2030 is elektrische auto's die rondrijden, toch?
Hoe kunnen we dit potentieel daadwerkelijk benutten, toch? Deze schat lichten. En ik denk dat veel zeer slimme mensen, u inbegrepen, in wezen veel tijd besteden aan deze vraag, toch? We beginnen, en ik denk dat ik een beetje terugkom op dit focuspunt, toch? We zouden nu kunnen nadenken over hoe we dat implementeren, hoe we dat kunnen orkestreren, wat dan ook, toch. Daar besteed ik mijn tijd momenteel niet aan. Waar we onze tijd aan besteden is: hoe kunnen we
bedrijven waarmee we werken helpen om het bedrijfsmodel te draaien dat ze willen draaien, want anders zullen ze opnieuw een incentive hebben om bilateraal te gaan als ze niet kunnen doen wat ze willen doen, toch? En velen van hen willen veel dingen uitproberen. Ik denk dat dit begint met variabele prijzen, toch? Ik bedoel, een heel eenvoudig begin zou twee verschillende prijzen per dag zijn, nachttarief, en zo verder – dit kan gecommuniceerd worden via de tariefmodule, zoals ik al zei, de eerste uitdaging, toch, waarbij we moeten helpen
Maar dan zien we natuurlijk ook, bijvoorbeeld bij zwaar transport, behoorlijk veel kortingen, omdat het vrij aantrekkelijk is voor laadpuntexploitanten, toch? Dus hoe implementeer je deze kortingen? Want het wordt echt rommelig – wat we in de industrie vaak zien is dat laadpuntexploitanten gewoon 10% korting toepassen op de factuur. Maar zodra de CDR ter discussie wordt gesteld, breekt plotseling het hele ding af, natuurlijk, toch?
Dus je wilt dit naar het OCPI-niveau krijgen, en naar het charge detail record-niveau, om echt controle te kunnen hebben, toch? En dat is wat we mogelijk maken voor veel bedrijven. Dus wat we vandaag hebben is wat we kortingen noemen – ik kan theoretisch ook een toeslag toevoegen – maar in wezen doen we daar het volgende: we stellen laadpuntexploitanten in staat om een korting te definiëren voor een bepaalde partner, toch?
Ons systeem hertariefeert dan de tariefmodule, voegt een routing header toe aan de tariefmodule voor de specifieke partner waaraan ze korting willen geven, en hertariefeert ook de CDR's, zodat de EMSP de correct getariefde CDR's van hen ontvangt. Dit is een product dat we vandaag native ondersteunen, en het is potentieel een behoorlijk spannend product. Maar ik denk dat, om over te gaan naar uw volgende vraag, dit iets meer fancy denken is.
Ik bedoel, ik vind altijd dat wat goed klinkt in wezen is: hoe implementeren we een incentiveschema via een prijsmechanisme van de energieleverancier, door de hele keten naar de EV-chauffeur, toch? Met natuurlijk als doel dat de EV-chauffeur reageert op het prijssignaal.
En ik denk dat dit toekomstmuziek is waar we graag een rol in spelen, maar op dit moment is onze duidelijke focus op het ondersteunen van onze partners. Men zou kunnen zeggen dat u het mogelijk maakt door betere implementatie van connectiviteit van laadpuntexploitanten en implementatie van bepaalde modules zoals de prijsmodule op een betere manier – dit is ook de basis, uiteindelijk, voor fancier dingen als u wilt. 100% eens, toch? Het is een beetje alsof je naar de VS gaat, bijvoorbeeld – het is een superspannende markt, er zijn veel superinteressante mensen met wie we daar op dit moment werken, toch?
Als iedereen het heeft over autonoom rijden – en we zijn het natuurlijk eens, toch – maar onze focus-mindset is altijd: oké, maar hoe zit het met het laten werken van de laadtransactie vandaag, toch? En ik denk dat we door zo te denken dat daadwerkelijk mogelijk maken, dus ik zou het niet meer eens kunnen zijn. Ja, trouwens, ik zag uw reis naar de VS, die ook vrij recent was, en u noemde ook dat autonoom rijden een groot onderdeel was van de reis.
Dus u bent al actief in de VS als oplossing op dit moment. Is er – u zei ook dat er behoorlijk veel verschillen zijn – maar voor u als product, zou u zeggen dat er een groot verschil is om nu in de VS te opereren vergeleken met Europa? Ja, ons product is theoretisch schaalbaar
over de hele wereld vandaag, toch. OCPP is een standaard, en dan is OCPI tot op zekere hoogte ook een standaard, en we hebben een Noord-Amerikaanse infrastructuur gelanceerd en we zijn nu actief bezig met het onboarden van partners. Het is nog vroeg, maar we hebben al – ik wil er niet over liegen – volgens mij zo'n 13 contracten getekend en ongeveer 8 partners of zo geonboard.
We hebben iemand aan boord gehaald met wie ik altijd al wilde werken, Daniel Brown, voormalig wereldwijd hoofd roaming bij ChargePoint, en hij leidt onze inspanningen in de VS en ook in het VK. Hij was daar onlangs. Ik was daar behoorlijk vaak omdat we ook onze seed-ronde hebben opgehaald bij een Amerikaans venture capital-fonds – Voyager Ventures precies, waarschijnlijk het toonaangevende
Ze willen niet dat ik transatlantisch zeg, maar het toonaangevende klimaat-VC – ik denk dat ze het nu niet meer klimaat willen noemen, nu is het veerkracht of zoiets – maar hoe dan ook, ik denk dat ik deel uitmaak van de gemeenschap. Het zijn geweldige mensen die elektriciteit en elektronen beter begrijpen dan wie dan ook die ik heb ontmoet, en die net zoals de andere twee VC's die in ons geïnvesteerd hebben, geïnteresseerd zijn in financieel rendement.
Wat ik daarover wil zeggen is dat we geen strategische investeerders hebben, toch. Er is dus niemand die tegen me zal zeggen: "Hé Jacob, kun je dit en dat alsjeblieft bouwen omdat dat grote bedrijf dat zou willen." En dat is zo belangrijk voor ons om neutraal te zijn en ons uitsluitend te richten op financieel rendement. Ze zijn geweldig, en daarom besteed ik veel tijd in de VS. We vinden het daar erg leuk. Het is anders, maar ik denk dat ons product eigenlijk direct schaalbaar is.
Ik denk dat het belangrijkste verschil – en dit is een interessante – is dat we niemand willen dwingen, ook niet in Europa. Het hele idee van een AP is dat u uw eigen contracten en commerciële voorwaarden bezit en daarom controle heeft. In de VS is dat argument nog belangrijker omdat niemand gedwongen wil worden tot roaming of iets dergelijks.
We geloven dat het een goed idee is om met andere partners te werken om uw bezettingsgraad en uw unit economics te optimaliseren – maar we geven u de infrastructuur als u die wilt, en u behoudt de controle. Dat is heel belangrijk in de VS, en dat is iets wat we hebben geleerd. En ik denk dat het heel goed gaat. Dus u staat overal ter wereld open voor zaken op dit moment? U pakt me op een goed moment, want ik praat veel over focus en het eerlijke antwoord is waarschijnlijk ja.
Er is een wereld waarin we nee zeggen tegen sommige zaken die momenteel echt buiten onze scope vallen. Maar misschien om een stap terug te doen en na te denken over onze groeipatronen: veel startups hebben een stad-tot-stad, land-tot-land, regio-tot-regio, valuta-tot-valuta groeipatroon. Zo groeien wij niet. Wij groeien netwerk tot netwerk, en als Ionity, met laadpunten in 24 landen, tegen me zegt: "Hé Jacob, kun je alsjeblieft deze vijf EMSP's onboarden in het nieuwe land waar ik binnenkom?"
Dan doe ik dat natuurlijk. Dus dat is de aard ervan, en dat heeft ons er ook toe gebracht om partners te onboarden in de VS, maar ook om partners te onboarden in Australië, Nieuw-Zeeland en andere regio's.
Het is dus een voorzichtig – het is een ja – en laten we de focus behouden. Gisteren was ik op een conferentie waar een van de belangrijkste onderwerpen elektrische vrachtwagens waren, bij de nationale Leitstelle – de elektrische mobiliteitsvereniging die verbonden is met de overheid – dus elektrische vrachtwagens zijn op dit moment behoorlijk een hot topic.
Heeft het op een of andere manier invloed op uw bedrijf, zoals booking of MCS? Ja, we hebben bijvoorbeeld een functie die we OCPI-versie-interoperabiliteit noemen, waarbij we verschillende partners in staat stellen om via OCPI 2.2.1 met ons verbonden te zijn en vervolgens te roamen met partners die op 2.1.1 zitten. Dat is behoorlijk nuttig voor sommige partners die nog vastzaten aan 2.1.1. Nu is er een nieuwe versie van OCPI, en ik ben niet de OCPI-expert – van onze ongeveer 20 teamleden weten er waarschijnlijk
11 het beter dan ik, misschien wel 15. Maar wat ik kan zeggen is dat OCPI 2.3.0 in wezen twee hoofdkenmerken heeft die adoptie stimuleren volgens onze ervaring tot nu toe. Enerzijds heeft u in de locatiesmodule meer mogelijkheden om geavanceerdere gegevens te communiceren – bijvoorbeeld hoe groot het laadterrein is en dat soort dingen. En ten tweede, de bookingmodule. De bookingmodule is in wezen een add-on waarmee u een tijdslot in de toekomst kunt boeken.
Wij geloven dat dit zeer relevant is voor logistieke bedrijven en vooral relevant voor behind-the-fence laadomgevingen. Maar bij publiek laden vertellen in ieder geval veel mensen met wie ik erover heb gesproken me dat ze er niet echt in geloven op schaal, omdat er potentiële operationele problemen ontstaan – bijvoorbeeld staat er nu een andere auto geparkeerd, dus wat doen we dan?
Dat soort dingen maken het behoorlijk complex om soms een echt goede klantervaring rond booking te leveren. We maken deel uit van de EVRoaming Foundation, we zijn fans van het nieuwe protocol – begrijp me niet verkeerd – maar wat ik zeg is dat we niet veel tijd besteden aan booking, en voor publiek laden, waar vandaag onze focus ligt, hebben we niet het gevoel dat het nu top of mind is. Zwaar vrachtverkeer daarentegen is absoluut top of mind, en we hebben de kernspelers in het veld geonboard.
Ik wil nu geen namen noemen, maar zowel aan de EMSP- als aan de CPO-kant denk ik dat we alle spelers aangesloten hebben, en we zijn blij dat ze via ons kunnen roamen. Waarom is het interessant? Vanwege gekke volumes, en omdat vrachtwagens altijd rijden en dus ook veel moeten opladen.
Dus misschien een laatste opmerking daarover: toen ik 5 jaar geleden de industrie binnenging, waren er nog steeds veel spelers in deze sector die rondliepen en zeiden: "Ja, waterstof – voor personenauto's is misschien elektrisch nu de nieuwe norm, maar waterstof voor vrachtwagens daar ben ik vrij zeker van." En Beieren financierde een soort waterstofideeën rond mobiliteit met 200 miljoen of wat dan ook, toch?
En het is gewoon best grappig om soms een stapje terug te doen en hier opnieuw naar te kijken en te zien hoe deze industrie nu zo overduidelijk ook voor elektrificatie gaat. En misschien, ik bedoel, voor ons is dat de reden waarom het soms frustrerend is om dingen te bespreken zoals - ik weet het niet - we hebben deze modewoorden in de Duitse politiek zoals "Technologieoffenheit," openheid voor technologie, en dan denk je gewoon...
Ja, oké, we kunnen dit open houden en nog meer terrein verliezen dan we al hebben, omdat het uit eerste principes zo duidelijk is dat elektrische mobiliteit gaat winnen. En nogmaals, dat is een van de grote boodschappen die ik naar buiten wil brengen: de grootte van de taart in plaats van een plak van de taart. Laten we er alsjeblieft allemaal begrijpen dat er geen alternatief is en dat het ook niet gaat veranderen. Laten we gaan. En er zijn veel mensen in Duitsland en Europa die dit niet begrepen hebben.
Ja, en gewoon kijkend naar de toekomst - de laatste vraag voordat we afsluiten met een persoonlijke noot - bidirectioneel laden: ziet u dat bij publiek laden of alleen bij privé laden? En nu u zich duidelijk richt op publiek laden, ziet u ook een grote rol voor Enapi bij privé laden?
Ja, focus, inderdaad. Ik denk er niet te veel over na - nou ja, dat doe ik natuurlijk wel. Ik kan u gewoon vertellen wat ik hoor uit onze gesprekken met C-levels bij min of meer alle relevante CPO's daarbuiten, en ik denk dat zij er behoorlijk actief over nadenken, ook voor publieke laadpunten. En dat is interessant voor mij om te horen, omdat hun identiteit natuurlijk het verkopen van elektronen is, toch?
En nu gaan ze plotseling richting: "Oké, we optimaliseren niet de benutting, we handelen eigenlijk in flexibiliteit" - en dan denk je: oké, daar zijn enkele open vragen, toch? Hoe dit geïmplementeerd gaat worden, weten we niet, maar we geloven wel dat het in ieder geval iets is waar publieke CPO's tijd aan besteden. En wat betreft uw vraag...
Ik denk dat wij voor veel van deze connectiviteitsonderwerpen hun voorkeurspartner zijn om mee te praten, en we praten heel graag met hen over hoe bepaalde ideeën te implementeren. En wat betreft privé laden - ja, natuurlijk. We hebben al veel privé laadpunten verbonden. We weten dat roaming natuurlijk ook een onderwerp is voor privé, en we geloven dat wij vrij duidelijk de beste oplossing daarbuiten zijn voor connectiviteit vandaag de dag, en dat geldt zowel voor publiek als privé, toch?
Waarom praat ik er niet veel over, en waarom neem ik nu geen contact op met CPMS'en die zich richten op privé laadpunten en laadpunten achter de poort? Focus, inderdaad. Ik kan niet alles doen, en ik denk dat we netwerkeffecten willen benutten. We zien deze netwerkeffecten heel duidelijk in publiek EV-laden op dit moment, en daar willen we op inspelen. Oké.
En ik weet niet of u daadwerkelijk een elektrische auto rijdt, maar als u een grappig, of ook een slecht, publiek laadverhaal zou moeten delen - en misschien een heel prettig verhaal? Oké, dat is een goede vraag. Allereerst heb ik momenteel geen auto, maar eigenlijk heb ik twee elektrische auto's in Berlijn tot mijn beschikking. Mijn vader rijdt een Honda, mijn broer rijdt een Tesla, en ik heb deze beide auto's natuurlijk veel gebruikt voor laadtransacties. Ik denk dat de meest prettige om het samen te vatten is...
Ja, hoe heet het - in wezen een trip die we deden tijdens een van onze on-sites in Berlijn, waar de meeste van onze teamleden naar Berlijn kwamen. Ons nieuwe teamlid Daniel Brown deed in feite een rondleiding met ons door Berlijn van laadpunt naar laadpunt, en natuurlijk namen onze engineers hun computers mee en volgden alles een beetje, en dat was leuk. Dat was heel fijn - twee auto's, acht mensen, gewoon genieten. En dan, heb ik een slecht verhaal? Om eerlijk te zijn, ik hoor natuurlijk overal slechte verhalen, toch?
Ik bedoel, ik vertel mijn familie, of vrienden van mijn familie, of mijn ouders, of investeerders - ik vertel hen dat connectiviteit niet echt werkt, en min of meer, ik zou zeggen 90% van de mensen die ik dit vertel zeggen: "Ja, dat klopt. Ik was een keer met vakantie ergens, ik had een elektrische auto, en het was echt verschrikkelijk." En ik hoorde de afgelopen twee weken opnieuw ongeveer 20 van dit soort verhalen. Dus ja, ik kijk ernaar uit om het op te lossen, maar ik wil niet meer verhalen toevoegen.
Nou dan, daarmee eindigen we op een goede positieve noot - u doet uw best om het heel snel op te lossen, dat weet ik zeker. Heel erg bedankt, Jago, voor uw harde werk en dat u hier vandaag bent geweest. Heel erg bedankt. Bedankt voor de uitnodiging. Drie dingen blijven bij mij hangen uit dit gesprek. Ten eerste, de prijs van connectiviteit. Zelfs een tarief van 5 cent per sessie telt op bij 1 miljoen sessies per maand, en dat geeft partners alle reden om hun eigen directe verbindingen op te bouwen. Jacobs conclusie: niemand die geld rekent voor connectiviteit zal op de lange termijn winnen. Ten tweede, clearing.
Omdat Enapi de transactie zelf bemiddelt, kan het gefactureerde charge detail records vergelijken met de sessies die het daadwerkelijk geautoriseerd heeft en duplicaten of ontbrekende records vinden. Ten derde, AI. Meer dan 94% van Enapi's productiecode wordt nu geschreven met AI, maar de delen die niet uit kunnen vallen worden slechts met uiterste zorg aangeraakt, en de uptime is openbaar voor iedereen om te controleren. Jacobs woord voor dit alles is focus. Bedankt voor het luisteren naar Smart Charge by RiDERgy. Als deze aflevering nuttig was, deel hem dan met iemand die werkt aan laadinfrastructuur, of geef ons een 5-sterren review. Tot de volgende keer.
Welcome to the Smart Charge by RiDERgy podcast. This is Claudio Geyken, founder and CEO of RiDERgy. This is your show to learn about all things energy management and smart charging innovation for electric vehicles and fleets. Connect to 450 partners and you build 450 handshakes, or you build one. That is the idea behind Inopi, and my guest today is its co-founder, Jacob Clayhus. In 2.5 years, his company has connected more than 1 million charge points, and it did so with a claim that sounds almost provocative.
Connectivity between charge point operators and mobility service providers should be free. The money, he says, is made somewhere else. We talk about where, about what financial clearing really involves, and about how a very small team keeps its infrastructure running at 99.998% of the time. Let's get into it. Right, Jacob, nice that you are here today. How are you? Yeah, thank you so much for the invite. Yeah, I'm a little bit stressed, as you know, I was late. No worries, rushing from the airport, but other than that I'm fine. Thank you so much.
You made it in from the Netherlands today, so I think I didn't have a guest that made it so far in the same day. Yeah, exactly, especially because I'm home in Berlin as you are, so it's strange. But anyways, very good and thank you so much for the invite. Yeah, and great to also know that you are a true Berliner, born here, born and raised, and your parents as well. It's something I didn't know, as I also was raised here in Berlin. Yeah, I grew up in Berlin.
I lived for quite a lot of years in other cities all across Europe - studied in the south of Germany and in Copenhagen, then worked in London for a short time and in Amsterdam. So I kind of know some other places as well, but I'm back in Berlin for quite a lot of years already now and building Inopi from Berlin as well. Yeah, and maybe you can share a little bit more about your background. I also decided to go from Berlin to the south of Germany, funny enough, to study, but I think a lot of Berliners like to stay in Berlin as well.
What was your motivation to go to the south and to study? I mean, this is going back to when I was 18, right? I wonder if I can even recollect why that was. To be honest, I think a very natural "let's go as far away as possible" - and maybe my horizon back then was a little bit Germany-focused, to be honest. But yeah, so I studied at Zeppelin University in Friedrichshafen, on the Lake of Constance exactly, and
I had a great time there. To be honest, I sometimes wonder how much I'm actually applying from what I learned at university or school in general in my normal life, and it's close to zero, but I definitely have my closest friends from that time still, so I very much would do it again. What did you study?
It's like a general studies program between sociology, politics, culture and economics for the first year, and then you focus - and I focused on corporate management and economics. That was essentially my study at the Lake of Constance, and then I went for a pretty standard Master in Business Administration at Copenhagen Business School for my master's.
And obviously in between, a lot of internships at different startups and different companies. I never worked - and we briefly spoke about that just before we started taping here - for a big company, so I essentially don't have any experience with corporates and how it is working for corporates, and that's why I think I'm on an ongoing basis learning a lot about how these organizations work. But in general, yeah, that is essentially what I studied. And what did you do in your past jobs?
As I said, I did a lot of internships in different companies. There was one company that was maybe interesting for this podcast as well - there was a Climate-KIC. I did an internship at Climate-KIC.
That was at the EUREF Campus, where obviously a lot of well-known European and German companies are headquartered by now, but yeah, back then they had a green garage there and they essentially incorporated some startups there, which was very exciting and I was
just part of the team there trying to help founders get things done essentially. That was maybe an interesting first step, but I think the first step that was really relevant for my future career was at Project A Ventures, where I did an internship in 2018. It was very intense, and what I loved about it is
you're talking to people who are excited about what they're doing every day, because you're talking to founders, and I think that was what I had missed in a lot of other positions I held before. That's why I decided - as I was at InnoEnergy, so also the other kick: Climate-KIC was on broader climate topics and InnoEnergy very much on energy - I could also feel the energy of the founders we were supporting, so I can totally relate to the point.
Yeah, exactly. And then I decided, OK, fast-paced environment, I learned a lot, I'm not bored at all and the people around me are not bored, so let's spend some more time here and essentially start working for venture capital funds. And I did that for 4.5 years, so actually quite some time. Always in the earliest stages, so essentially startups that had nothing, or close to nothing - essentially the founders themselves and their commitment to build something big - and trying to figure out: do they have chances to actually make it, right?
Super exciting time. What did you learn, to be able to distinguish that - and maybe that is also relevant today for your being a founder? I mean, it's hard to break it down like that probably, but I think one thing I believe I learned is that a lot of startups - investing into startups is essentially investing into a potential outlier, as in a company that returns significantly more money than any other company in the industry.
So what you want to invest into is something that has the potential to become really, really big, right? And I think what you learn quite quickly is that everyone has a kind of huge incentive to do that based on data and historic performances of other companies, but a lot of these outliers are actually not following the normal path of other startups - because otherwise they wouldn't do something different and therefore wouldn't be an outlier, right?
Maybe that's oversimplifying, but a lot of the most exciting companies I think are built from first principles, without trying to mimic another company. "We are the Airbnb for phone sharing" or something like that, right? How crazy boring, right? I'm trying not to swear. So that was a little bit of what I learned for myself: think for yourself to a certain extent, because most likely if you dare to think for yourself, this can be more successful than if you don't, right?
And I think that was one of the things. The other thing was: it's definitely to some extent about working hard and being able to understand the context, but a lot of starting and scaling a company is also luck and energy, right - how much energy am I able and willing to invest every single day.
And I think that's something we also learned. What I also learned working in venture capital - idea versus execution, which I saw you had a point on; I don't remember if it was in a blog post or in a social media post. Maybe can you elaborate on how you apply it in your day-to-day as well? And then we will come back to how you got the idea, and whether you pivoted from the initial concept at all. Yeah, I'm always surprised how little we actually pivoted, to be honest, but we can totally speak about that.
But yeah, I mean, you spoke about execution, and I think what our view on this as a RiDERgy team would be is: we are the challengers in an industry, right? As a startup you get into this industry, you essentially have no logo, you have no brand, you have no team, and you don't even have capital in the beginning. Essentially the entire world is against you, right? And the one thing that you potentially have is execution, right?
Because you will always be faster, you will always be able to react quicker, and you will always care more than the companies that are so far the incumbents, right? And therefore I mean we face a lot of situations.
For example, these stealth startups that come out of stealth and launch themselves - I never understood this, right, because from our perspective it's all about execution, and I'm happy to share with anyone essentially what we are trying to build here and all of the secrets that we have, right. Because what it comes down to is we need to execute better than everyone else, right? And I see that happening a lot in this industry. For example, we are asked a lot
to sign non-disclosure agreements, which is something we are open to do, and we do have a lot of NDAs - I always need to be careful what names I drop anywhere - but long story short, we never asked any company for an NDA, right, for the same reason: at the end of the day, execution is going to matter, and not who knows what about secrets that you have an idea about or something like that. And what is good execution for you?
Like, if you had to - the first things that come to mind where you say, yeah, this is definitely what we believe is good execution that we foster every day in the team. Yeah, I mean, maybe that sounds a little bit too easy now, but what that is, is focus, right. Knowing what you want to own in the value chain and then being 10x better than everyone else in owning that and building that, right?
And it sounds easy, but in this industry - I mean, we are by now, and we'll probably speak about that later - working with, have contracts with, slash have onboarded in production, like the vast majority of the industry, right? Especially in Europe. And everyone has problems, and we love to hear about them, right, because it's really sometimes surprisingly hard to get good quality feedback on what it is that we could solve for them, right?
And at the same time, we need to say no to 90, 95% of these requests and ideas that we have, to be able to focus on what we actually want to execute on our own, right? And only if we can actually get this focus in can we actually execute in the next step, because then we know what our mission is, right? And so yeah, my easy answer would be focus. And maybe what I would add to that is we have an insane team, right? So this is a team that is remote-first for the engineering team.
And essentially my co-founders and I had like 5 people in mind who we wanted to bring on board when we started, like the day after we signed our first funding round and knew, OK, we can hire some people. We essentially had 5 profiles in mind and 4 of them we onboarded in the meantime. So for us it's like the dream team to a certain extent, and I think that also helps to execute, right, because everyone is pushing in the same direction, and everyone.
Pushes themselves, but also has a goal-oriented way of working together, right? So we can also tell each other, OK, this was not good, right? And so far, yeah, just have a lot of fun working together. I think that's the second thing. So focus and having fun working with great people. Makes sense. No, I can totally relate. And before we deep-dive into Inapi in a sec, how did - I know you worked for Bonnet - how did you get into Bonnet or into the e-mobility industry? What was the path? Yeah.
I mean, Bonnet - maybe for some people who are listening to this they know the brand - Bonnet is a company, I really don't want to lie now, but it's an EMSP that was started, I would think around 2020 or something like that, out of Imperial College London, by two amazing founders, Patrick and Elliott, who literally out of a university project started an EMSP because they said, OK, out there there's no fancy MSPs with a good brand, right?
And I got to know them quite early - I think maybe 4–5 months into their journey - because they applied for funding from the venture capital fund I used to work for, and I hopped on a call with them. Essentially we did the deal, like quite a small investment, and I started working with the team to build the company, right, and in this time I think we spent quite some time together.
They definitely struggled to raise the next round and so on, and we worked a lot to kind of get that done. And then suddenly it's always like a little bit of a catch-up effect, right? Essentially everyone wanted to invest because the company grew quite quickly. They raised money from Lightspeed and Google Ventures, quite well-known and renowned investors, and then Patrick and Elliott asked me to come on board full-time, and that's what I did. I mean, I don't want to get into the details of what happened at Bonnet.
The company was, a little bit later - like 1.5 years later - sold to Over Energy, and today the team works as Overdrive, amazing team as well. But when the acquisition happened, I already knew I wouldn't want to work for a big corporation in the UK, and also I had experienced this connectivity pain they were trying to solve with Inapi firsthand, both from a commercial but also to a certain extent from a technical point of view. And that's why I left and started Inapi.
Yeah, and then maybe let me just set some context, set the scene, so that we're on the same ground. So the connectivity problem, as far as I understand - and please elaborate or correct me if I'm missing something - that you identify is: there are plenty of players around in the industry. We have CPOs, we have MSPs, those are the most important roles I would say. And underneath the CPOs there are CPMSs, so that's the software that CPOs use.
And then there were traditionally roaming hubs that were created to connect those different players. I don't know the exact number of CPOs and MSPs there was and that there is right now, but it's significant. Maybe you can update us if you have them on top of your mind. And so this connectivity layer from traditional hubs - that's what you identify - there are quite a lot of issues with it, or a lot of ways that it can be done better, and that's what Inapi is essentially building, right?
And maybe you can elaborate now with a bit more detail. Yeah, so maybe first of all - because I think as an industry we're not doing this often enough - maybe look at it from a customer point of view, right, like an EV driver point of view. The EV driver wants accurate data about the availability of charge points, right, and then they want to pay the lowest possible price. And that's very much not how public EV charging works today, right? And now we can get into, OK, why is that, right?
And I think you quite quickly arrive at: OK, there's a lot of different companies in this industry. As you already elaborated, there's different roles, right, like CPO, CPMS, EMSP, whatever. There's also fragmented markets, so there's a lot of different CPOs and a lot of different strategic interests in the market. But long story short, these companies need to work together in an efficient way to make this customer experience actually work at scale.
At Bonnet, what we learned quite quickly is this is not working at scale. So we were a very classic EMSP and essentially wanted to connect to all relevant CPOs in Europe. Back then, it was summer 2022, and there were essentially two ways to connect. What I would call legacy roaming hubs - platforms that were pioneers 14, 15 years ago - essentially trying to standardize the communication between CPOs and EMSPs in the market.
When I started in this industry, they still did something like 80% of the integrations, but already only 20% of the transactions, because the big volume integrations - the big EMSP with the big CPO - had already started to go bilateral, build bilateral OCPI integrations. And that's essentially the second option: legacy roaming hubs and bilateral OCPI integrations. At Bonnet, in the beginning, we thought, OK, why not work with the hubs?
The alternative, as I said, was bilateral OCPI integration, so Bonnet started building a lot of bilateral OCPI integrations - I think over 50. What I can recall is that on average around 10 of those were always down, and that was not because of Bonnet. They had amazing tech. The reason was not even technical issues but more operational issues.
Like, something doesn't work, some conflict doesn't work, some tokens weren't synced, some small interpretation of the OCPI protocol implementation didn't work. And then you need the other person on the other side to debug that.
Let's stop there for a second, because I think it might not be so obvious for everyone who isn't a deep IT integrations person. There are two sides to this integration - two systems that need to integrate and two software layers that need to integrate.
There's a protocol - OCPI - and I think there are a couple more, but the hubs are managing those protocols. Correct me if I'm wrong, but OCPI is, let's say, the free independent one. And in it, like in many other protocols - and I think OCPP faces the same issue, where the charger talks to the charge point management system, but that's not really the core focus of this podcast - there is the question of the interpretation and the implementation of the protocol.
If one stakeholder messes things up, that's when things go sideways. Am I correct in putting it this way? Kind of, exactly. So let me give maybe a little bit of a historic breakdown - and I'm definitely going to be wrong in some ways. I've been in this industry for five years, and I think I understand it quite well by now, but back then I had no idea what happened before that.
But long story short, there are these platforms that back then tried to standardize communication, as I said, as pioneers in this industry. And they started
essentially defining protocols to standardize it. So Hubject came up with OICP - maybe there was something before it, but that's what we know. Gireve came up with eMIP, I think e-Clearing came up with OCHP, mainly out of the Netherlands. And I think because my co-founder Dennis Lauman was one of the original authors of OCPI, there was this willingness, especially among charge point operators, to become independent and essentially launch a protocol that is independent of these commercial, non-neutral players.
That's why the EV Roaming Foundation was launched - we are part of the EV Roaming Foundation today, as are a lot of other relevant players in this industry. What the EV Roaming Foundation does is bring people together to define the OCPI standard. The most relevant OCPI versions today are OCPI 2.1.1 and 2.2.1. There is OCPI version 2.3.0, already launched and implemented by very few players - happy to speak about that in detail. But essentially OCPI is the answer of a lot of
CPOs wanting to become independent of proprietary protocols. So that's the core open-source protocol, and obviously the platforms I just mentioned have adopted OCPI by now. From our perspective it very much becomes the standard - not only in Germany or Europe but actually across the world. I read a stat recently that more than 95% of public charge points outside of China actually communicate OCPP data, and the vast majority of those charge points could also use the OCPI protocol.
So that is, I think, the high-level summary of these protocols. And OCPI - to just answer your question - was launched initially with the idea of building bilateral integrations. Now, I think in your initial introduction you already said the markets for charge point operators and EMSPs are fragmented. There are hundreds of players on both of these market sides, and if you would have 3 players on the CPO side and 3 on the EMSP side, it's quite easy: everyone connects with each other and you have 9 integrations.
Now, if you have 500 players on the MSP side and 500 players on the CPO side, then it's 250,000 bilateral integrations. And I think there you already start understanding: OK, these are all integrations that need a handshake, they need to be set up, they need to be tested, and then they need to be maintained. And now we are talking about a lot of different versions of OCPI that are obviously not interoperable with each other. So it gets very, very messy, very, very quickly - let me put it like that.
So I think what the industry faced - to go back to when I entered the industry - was essentially: I believe connectivity should be a commodity, should be a freely available good, but actually it's a constant pain, and so on.
And that's the main reason for us at Bonnet where we had a hard time delivering a really good customer experience, and most of the costs came from that - even indirect costs. For example, customer success costs were created because of exactly these connectivity issues, and that's why I said, OK, there needs to be a better way to do that, and started looking into other industries.
Yeah, it was summer '22 when I reached out to my two co-founders and essentially started thinking about what a model would look like that would bring together the huge advantages of one single integration and, at the same time, good data quality without significant transaction costs. The answer to that is in AI, but I guess we'll get there now. Yeah, let's get into it.
This is a separate segment, but as you mentioned the co-founders - one thing that struck me, also because personally speaking it took me quite some time to find my co-founder - I find that especially finding technical co-founders, as we are both CEOs, is very difficult. And you managed, if I remember correctly, you had like one person in mind.
That you really wanted to co-found the company with, and it turns out that this person said yes, which is quite impressive - or incredible. How did that story go? Can you elaborate on the co-founder matching, which is so important as a foundation for the company? Yeah, so I mean I had experienced the problem. I had negotiated a lot of roaming contracts. I had tried to escalate a lot of problems with connectivity on the commercial side to a certain extent.
But I knew what we wouldn't want to build; it wasn't super obvious to me whether we could even build it the way I had envisioned. So what I did as a very first step was essentially put together a memo - maybe a little old investor mindset, but a memo on what this company would do, like 5 pages or something. I need to search for it again; it's somewhere on my computer. And I essentially sent this to, I think,
four or 5 people. To be honest, I just did cold outreach. I literally looked up on GitHub who wrote the OCPI protocol, and what you find then - I hope I can say these names here - is essentially Olga Vanier, Patrick Rademakers, and Dennis Lauman. Always among the three names that are the godfathers.
I love that - that's probably from one of my pitch decks - the godfathers of OCPI, yeah, exactly. And I actually wanted to speak to all three of them. I spoke to Olga as well, but then Dennis and I met and had a funny, coincidental second meetup in Aachen at an e-clearing event.
And I can just remember we were already both quite excited about the memo, and we essentially used those two days in Aachen to lock ourselves in a room and think about how this could be built and how we could do that. Now, Dennis back then was still a managing partner, I think they called him, at Ihoma - I think one of the leading tech consultancies in the industry. He had built a lot of CPMSs before and had a really talented team there as well, and therefore it wasn't easy for him to drop out.
For me it was quite obvious that I wanted to start this company. So essentially I think we worked for 3–4 months quite intensively next to our day jobs, and then we came to a point where I said, OK, let's try this for 3–4 months. If we haven't raised until end of Q1 '23, then you go back to your job. And that's how we started. I think what a lot of investors always say is that a founding team where the founders don't know each other from daily work, or where they're not friends, is essentially risky.
And we even had this one guy who said no in our first round, where we had a lot of investors who wanted to invest but said no because of exactly those vibes - like that we didn't know each other well enough - and we were considering sending him a Christmas card every year. We work together now because we are so close. So long story short, Dennis is amazing. He's based out of the Netherlands, and that's why I was always 100% clear that we would build this remote first.
We are trying to hire the commercial team in Berlin, but everything else is kind of remote first. But no, it's really like on the first days we trust each other, love each other, and yeah, we've experienced a lot together now, so quite excited about it. Very cool background story as well - I think inspiring for founders out there. And so you said you created the company more or less at the end of 2022.
Right, yeah, so we officially incorporated the company I think January 23, and we had already signed the term sheet - essentially had talked to investors in December 22. So yeah, it was super quick. It was literally two weeks after we started fundraising; we had like five, six term sheets and had to decide. And then raised the very first funding round literally based on a pitch deck, with Project A Ventures and Seedcamp from London.
Yeah, and that was a 2.5 million round, right? And then January 25 was a 7.5 million round. Yes, so I think announced - I think that was more or less discussed in November, December - sorry, no, 2023. Yeah, am I getting this right now? No, 24, of course - this was January 24, sorry. We were one year off the entire time. So January 24 we launched, and in January 24 we also announced our 2.55 million pre-seed round.
And then announced in January 25 our seed round of 7.5 million that we had closed in December 24. So essentially 10 months after we raised our first round, we raised an additional round. Yeah, time flies. And then I read that you had 600,000 charge points connected by the end of 2025, but now I think the most recent post was like 850 already, something like that.
To be honest, no hard feelings because it's moving fast, but when this is coming out I can say that already - we're now announcing a million charge points connected in production. And actually we are already at 1,050,000, so yeah, we're just growing super fast. We've onboarded more than 450 partners since we started. That's, on average if you calculate that across 2.5 years, a little bit more since we started onboarding, roughly 2 per week or something like that, a little bit more.
And that is literally with one team member who's mainly doing that - of course others can help as well, but essentially one person who's more or less full time testing, onboarding and pushing on the technical side, and the rest is widely automated. I think that's one of the reasons why we were able to grow so fast. The timing was perfect when we started: it was literally exactly the time where people were fed up with the legacy roaming hubs.
They ran into issues with building bilateral integrations, and they had an OCPI-ready API, so essentially we could connect them right away without any significant friction. And of course, building 450 handshakes, you come across a lot of - I don't want to judge, but - maybe a little bit weird interpretations and implementations of OCPI. That's the big problem with OCPI: it's essentially implementable in many different ways, let's say like that.
And we've built workarounds, so by now we rarely see implementation times of more than one to two weeks. Maybe that's a stupid question, but as I'm not so deep into that it will be interesting to understand better. So fundamentally the API quality of one of the stakeholders can mess things up. By positioning yourself somehow in between the stakeholders and ensuring that connectivity works well - still, if one stakeholder messes it up, how do you prevent those mess-ups?
Are you able to identify them quicker, or how is your role - so to say - how are you enabling that the mess-ups don't occur? I think the obvious, maybe low-hanging-fruit value proposition we have here is you're not doing 450 handshakes anymore, you're doing one - with RiDERgy - and then you can scale from there essentially without any additional technical overhead.
You just go into our portal, click "I want to send them an offer," send them an offer, and if they accept, your POI data as a CPO gets pushed to the MSP and you can pull the tokens from the EMSP - super straightforward, very little technical overhead. But to answer your question, I think that's important: we play a huge role in harmonizing the OCPI APIs of our partners. OCPI is set up in different modules, and not every single one of those modules is necessary to make a connection work.
So when we started, a lot of our partners, for example, had not implemented the so-called tariffs module yet, so they essentially had a hard time automatically communicating the tariffs with each other. This creates friction, and therefore what we always kind of motivate everyone to do is to actually implement the entire OCPI protocol. Having said that, I think we play a huge role in harmonizing in that sense that a lot of EMSPs tell us that they have significantly better success rates within NAP than they have in bilateral OCPI integrations.
And I think that's counterintuitive, right? A lot of people in the industry are like, ah, but I'm adding an additional stakeholder in the chain, like it's going to create more friction, there's another party - but this is just not how it works in reality. We have a very sophisticated alerting system, more than 90% of our customer success interactions are outbound and not inbound. So we actually are the ones cleaning up the data and helping partners to get on top of their shit.
And as a next step, we therefore see a lot of very successful transactions. Another issue that you see a lot in bilateral integrations is, for example, sync jobs failing. Some token doesn't arrive at the CPO and therefore it cannot authorize the session when the token tries to charge there, or some EVSE somehow isn't in the mobile application of an EMSP, and you wonder why.
What we help partners to do is to get visibility into the success of their sync jobs, and to get flexibility into how they want to sync - do they want to push or pull the data, when do they want to do this, what is the cadence, and so on. All of these things help the entire industry to streamline connectivity. And I think why I'm putting so much emphasis on this is: NAP from day one wasn't built to replace the legacy hubs.
We are growing also in part because people are migrating from them, but our most direct competition is not these legacy hubs. Our most direct competition is bilateral OCPI integrations, because that's where the big volumes are, and our ambition is that 100% of the volumes of one specific CPO or EMSP are migrated over. Now obviously I know this is going to take time and a lot of trust in the industry. But this is what we're here for, and that's how we have built NAP from day one.
So it's super important for us that, for example, success rates for NAP integrations are higher than in a bilateral setup, and that people understand that this is actually the new normal going forward. And what is also super important for us is that we see the first bilateral integrations being migrated to NAP - it's one thing to onboard all of the logos, but it's another thing to make them migrate all of the integrations to NAP, and we're getting there right now. So yeah.
And one stakeholder or connection type that we haven't talked about, that I think is quite common in the industry, is the platforms - which I think are mostly the backends, the CPMSs - that are also facilitating integrations. So how do you look at that stakeholder type, and maybe you're even able to say which share of the integrations is done via platforms and which one is done via bilateral roaming hubs and now in NAP? That's a good question. No, if it's difficult, I know sometimes I'm just getting ahead of myself.
What comes into my head when thinking about that is our pitch deck for the pre-seed round in January '24. That was essentially where we did a little bit of a customer segmentation, and we essentially said the charge point operator side - the supply side, if you want, in our model - can be separated into three different groups of companies.
The first one is strategic multinational players: oil and gas companies, utilities, car manufacturers, OEMs - essentially companies that have a strategic interest in this market, that have very deep pockets and tend to be slightly slow-moving, although we love all of them who are working with us. The second bucket is essentially the most capable players probably in the industry today, and that is the infrastructure fund-backed joint ventures and startups in this industry.
They are really good at leveraging their data, they are really interested in optimizing their processes. Good examples of that are the Charging League, Fastned, Atlante, Ionity, Electra, Power Dot - those kind of players come to mind.
These players tend to not have the biggest networks, but they have a lot of transactions because they are really high-quality networks, and because they are scaling really fast. And then the last bucket I think is the long tail being aggregated through charge point management systems. So exactly - and how that looks like is.
These charge point management systems act as the contractual partner with EMSPs, so for us they are the CPO, if you want to think of it like that, because they have the roaming contracts with the EMSP and they essentially invoice the MSPs as well and distribute the money between the CPOs afterwards. So for us, the stakeholder or the player we are integrated with is the charge point management system. They also have the account with NRP if they are the contractual partner for the MSP.
So what we always look for is: we really don't care who you are essentially. Are you the party in the roaming contract? And if you are, you are our customer. We work with a lot of CPMSs - we have partnerships announced with more or less all of them by now, we're very close with them. I don't want to lie, but I think there's no CPMS that we don't have any integration with in Europe. Obviously, the CPMSs you can again segment into a little bit older, a little bit slower-moving startups and so on.
I don't want to do that now because, as I said, we work with all of them, but there's a lot of amazing technology and a lot of amazing companies and people that we're working with there. And essentially, if I understand correctly, when you talk about integrating between CPOs and MSPs, you're integrating the CPMS implementation of OCPI, right? Exactly. I mean, the CPOs have their end in complexity. There are CPOs who build their own CPMS - there was a little bit of a trend maybe two or three years ago.
Then there are CPMSs who are just charge point management systems, so essentially software-as-a-service companies, and they don't own the roaming contracts, never. From our perspective, oftentimes in the interests of the CPO, then there are some CPMSs who essentially have a long history in doing the entire financial clearing and the entire heavy lifting for their CPO customers. And all of them have a right to exist.
So it's really complex, but you're right - after all, we have technical integrations and therefore we connect to charge point management systems. But as I said, there are very big charge point operators who have their own charge point management system, and there are very small charge point operators who also have their own charge point management system, so this market has all different flavors. And talking about the business model, I think you already hinted at it: connectivity should be free.
So I understand this is also a fundamental difference between EAI or other stakeholders trying to do the same thing that EAI does, where connectivity is not free. And I understand your business model is entirely based on the financial clearing. Maybe you can elaborate on this clearing aspect and how you do it better than other stakeholders that are focusing on the clearing aspects.
I think I hinted briefly towards this: from day one - and that's also where I'm always surprised that we haven't really changed our identity and mission since day one - from day one, our ambition was to replace bilateral direct integrations, direct OCPI integrations, because they didn't work at scale for us at Bonnet. Some people tell us they work, some people say they don't work at all.
But long story short, if you look at success rates and everything involved, connectivity should be a commodity. And it's not a commodity today, because everyone has a tech team sitting there controlling data, everyone builds their own slightly scrappy validations in-house, they need to look at charge detail records and essentially build relevant transaction data to analyse - and all of this doesn't work.
And we always said we want to build product for 100% of the volumes of a CPO or EMSP, not for the long tail. And if you say that, you need to look at why they broker 80% of their transactions through bilateral integrations. For us, the reason is quite obvious: significant transaction costs. If you charge transaction costs for connectivity, then people have an incentive to go bilateral. Because even if you only charge 5 cents a session -
- at 1 million charging transactions a month, there's quite an obvious significant incentive to go bilateral. And therefore, from our perspective, in a mass market in the future, there won't be any connectivity costs. No one who charges for connectivity will be able to win in the future. I think this was a little bit surprising to the market 2.5 or 3 years ago when we started, but by now the vast majority of the market agrees with us on that.
And then the obvious question is: how do we do connectivity, because, as already stated, bilateral integrations don't scale? So how do we do connectivity, and what is the next biggest problem? I think our answer to that is: let us commoditize connectivity, make it a freely available good, make sure that everyone who invests even one engineering hour into internal connectivity that they wouldn't need to invest is essentially wasting time and money - because they should be investing into something where they can build differentiation.
It's a commodity, it's free of charge, right? And then let's look at the next biggest problem, and from our perspective, the next biggest problem is financial clearing. CPOs have a very hard time essentially getting paid, and EMSPs have a very hard time validating charge detail records, opening relevant transaction data, then approving invoices and paying them in a scalable way, right? The biggest EMSPs out there, they receive like 450 invoices every month, right?
And actually not every month, but every 2, 4, 6, 8, 12 weeks, sometimes with CDRs, without CDRs, different currencies, different VAT rates. It's messy, and this is what we are tackling here. Now, why do we have an unfair advantage to solve that? We only have an unfair advantage to solve that if we actually broker the transaction, right? Because what we can do is we can validate the transaction at a different level than horizontal players who are doing this in many different industries could, right? Because we can look at the charge detail records that are invoiced and can say:
hey, there are some CDRs on there where we didn't authorize the session, this didn't happen - or we can say, hey, there are some missing CDRs, or there are some duplicate CDRs with different CDR IDs, but we know that because we authorized the session, right? And there are millions of details we can validate, but long story short, only because we broker the transaction can we actually build the best financial clearing product out there. Our strong belief is that the vast majority of the market
won't be doing their financial clearing themselves in the future. Right now it's scrappy, in-house processes based on CSV files and so on that we are competing against with our financial clearing product. But in the future this is going to get more complex because we'll have variable pricing, we'll have discounts - there are a lot of things that add complexity to this.
And it doesn't make sense that 450 companies in Europe build their own solution in-house, right, and this is where we come in. So the clearing is mostly done in-house, or there are third parties doing it with, let's say, legacy tech - that would be the
- I don't want to be so judgy about legacy tech, but what I can say is, as always, and I think that's a steady theme throughout our talk so far, obviously there's everything in this industry: people who do it themselves, people who do it with some random companies from outside, people who just don't do it at all and essentially pay invoices however they come and don't validate anything, right?
So there's really everything - we've come across everything. But it's definitely an obvious problem that everyone faces, and you can talk to every CPO and EMSP out there, they'll agree that the validation of billing-relevant transaction data, then the approval of payments, and then the payments themselves are super manual processes.
Yeah, I can confirm as well from conversations I've had. And you mentioned an impressive KPI: 99.998% uptime and under 20 milliseconds latency in 2025, which is quite impressive. How are you able to achieve such great KPIs? I understand that's what you are competing against legacy tech with - strong arguments to be made to adopt your technology. Yeah, so I think what is very much true and an easy argument is an insanely talented team, right?
We are still a very small team, and we are very conscious about that, right? We believe that if we're an intermediary and we don't want to charge connectivity costs, we can build this with a very lightweight team. At the same time, we have incredible talent on the team. The other honest answer is, in contrast to the legacy hubs I just spoke about, right,
we didn't start 14 years ago - we started in 2024. Our cloud infrastructure is probably the heart of our product; it's state-of-the-art technology, and that's how we can achieve that. Also, one thing I want to share is that, in contrast to most of the players out there, we actually publish our uptime at all times, so everyone can go to status.api.com and see the uptime of our infrastructure both in the US and in Europe.
We hold ourselves accountable by making this public, and so far this has been working really well. Super happy with the team, and I think there are many reasons for that - there is a lot of work involved, to be honest. And also a lot of AI. As it's the name of the game, it's on my mind every day. How are you looking at AI as, probably, an AI-native company?
So, first of all, yes, right. I think - I wouldn't need to look it up again - but I believe since around January 15th or 16th, 2026, when a new model of Claude was launched - Sonnet, was it? Yeah, something like that. Anyway, I think more than 94% of our production code was AI-written. Obviously it sped us up like crazy, and definitely this helps, right?
What I will also say though is: we are not your next kind of AI rocket ship company that just throws whatever comes their way into a pull request and lets go, right? And there's a very good reason for that. If you essentially want to build trust with big corporations as a company, as a startup, the one thing that they will look for is: is this product working, right?
And you just cannot afford, if you are infrastructure-relevant for CPOs and ESPs and that is direct ROI-relevant, to be down for 20 minutes or an hour like the legacy hubs sometimes are. This is just something we cannot afford as a startup. And therefore there are parts of our product - and our engineers are very aware of that - that we only touch with utmost care, and where AI is helpful but obviously not kind of replacing the really important second, third and fourth look from humans, right?
So that's the one comment, but yeah, AI is definitely a huge topic for us, obviously enabling us. And then, maybe last but not least, on the commercial side - it's crazy, right? I mean, today one of my co-founders spends a lot of time in product, but he's also quite involved with customers. But other than that, it's me and our newly hired Director of Growth, Dennis Daniel Brown, from former ChargePoint.
He is handling our commercial scaling. So by now we work with the vast majority of the industry, but we haven't run crazy outbound campaigns to reach them, because it just doesn't work. I was more or less alone on the commercial side, and AI helps a lot. So that's another dimension. But with that - whoever has never talked to me in the past, please reach out, especially CPOs and MSPs.
We are sometimes surprised by some of the players, especially in the Spanish region, France, but also in the Nordics, who have never heard of us and are a little like, "ah, OK, this sounds interesting" - and we're like, yeah, alright, let's talk. So yeah, I'd love to talk. And you said in the past that there's a problem with collaboration in the industry, that you feel like we should collaborate more. What did you mean by that?
To be honest, I don't know in what context I said that. I'm sometimes surprised by how open people are for collaboration, but I think there are very few alternatives for us. Most companies are not like Tesla, which essentially has a full-stack solution from hardware to charge point operator to CPMS to EMSP to essentially a car, plug and charger, and so on. There's only Tesla, essentially. And other than that, people have to collaborate and cooperate, so I don't think it's really an option not to.
So yeah, not sure when I said that, but I agree - as much collaboration as possible is helpful for the industry, I think. And then there was a post you made, and maybe you can elaborate in your own words again: it's "size of the pie over slice of the pie," if you remember your blog post. Yeah, so from our perspective - and to be honest, I can feel this in the vast majority of the conversations I have - if the industry wins, everyone wins. And that is our mindset. We're not trying to kill a competitor. Diesel is the enemy.
Yeah, exactly. Diesel is the enemy. The Tankerkarte is the enemy in Germany. At the end of the day we want to play a role in enabling the green mobility revolution, and we're just not there yet. I mean, 17% growth sounds good for an old-school industry, but what the hell - we need to make this transformation work.
And if the entire industry is focused on that, we'll make it work much quicker and everyone will benefit from that. That is what I mean by that. We are not optimizing to, I don't know, kill another company or capture some specific percentage - we just want to make sure that we actually solve connectivity for the industry to help it scale.
And I think so far this mindset has helped us quite a lot to do the right things. That often makes sense. And then let's talk pricing, which is a topic I'm also particularly interested in in the smart charging and flexibility space, which will come as a last bit. You also wrote about it - that there are different levers that CPOs could play: volume incentives, fleet rates, and other types of surcharges on traffic routes to aggregators.
Maybe you can elaborate what your view is on the future of pricing, which right now - everybody probably knows - is still quite static. It's mostly dependent on charging speed; if it's a DC charger it's usually higher, but not too many dynamic rates. Where do you see the industry going? And maybe also, as a segue to flexibility, what would the ideal pricing look like, if you have any thoughts on that?
I recently heard a static - and a talk, or the Museum talk about the transportation ministry, or whatever it's called - talk about flexibility. This would be exciting, I imagine, right? And I had a little bit of this kind of Angela Merkel "internet" kind of remembrance. I don't know if you know what I mean, but essentially, for us it's quite obvious, right? I read a stat - I need to look this up again - but something like 75% of the battery capacity until 2030 is electric cars driving around, right?
How can we actually lift this potential, right? Lift this treasure. And I think a lot of very smart people, you included, essentially spend a lot of time on this question, right? We are starting, and I think I'm coming back a little bit to this focus point, right? We could now be thinking a lot about how do we implement that, how can we orchestrate that, whatever, right. This is not where I'm spending my time right now. Where we are spending our time is: how can we help
companies that we are working with to run the business model that they want to run, because otherwise they again will have an incentive to go bilateral if they cannot do what they want to do, right? And a lot of them want to test out a lot of things. I think this starts with variable prices, right? I mean, a very easy start would be two different prices a day, nighttime pricing, da da da - this can be communicated through the tariff module, as I said, the first challenge, right, that we need to help
But then, obviously, what we also see is, for example, for heavy-duty vehicles, quite a lot of discounts, because it's quite attractive for CPOs, right? So how do you implement these discounts? Because it gets really messy - what we see in the industry a lot is charging operators just applying a 10% discount to the invoice. But then once the CDR is kind of challenged, suddenly the whole thing kind of breaks, obviously, right?
So you want to get this to the OCPI level, and to the charge detail record level, to be able to really have control, right? And that's what we're enabling for a lot of companies. So what we have in place today is what we call discounts - I can also theoretically add a surplus - but essentially what we do there is we enable CPOs to define a discount for a given partner, right?
Our system then re-rates the tariff module, adds a routing header to the tariff module for the specific partner that they want to give a discount to, and then also re-rates the CDRs, so that the EMSP receives the correctly rated CDRs from them. This is a product we natively support today, and it's quite an exciting product potentially. But I think, to go over to your next question, this is a little bit more fancy thinking.
I mean, I always feel like what sounds good is essentially: how do we implement an incentive scheme via a price mechanism from the energy provider, throughout the chain to the EV driver, right? With obviously the goal that the EV driver reacts to the price signal.
And I think this is future music where we are happy to play a role, but right now our clear focus is on enabling our partners. One could say you enable it through better implementation of connectivity of CPOs and implementation of certain modules like the pricing module in a better way - this also is the foundation, at the end of the day, for fancier stuff if you want. 100% agreed, right? It's a little bit like if you go to the US, for example - it's a super exciting market, there are a lot of super interesting people who we are working with there right now, right?
Like, when everyone is talking about autonomous driving - and we agree, obviously, right - but our focus mindset is always: OK, but what about making the charging transaction today work, right? And I think by thinking like that we actually get to enable that, so I couldn't agree more. Yeah, by the way, I saw your trip to the US, which was quite recent as well, and you also mentioned autonomous driving being a big part of the trip as well.
So you are active already in the US as a solution right now. Is there - you also said that there are quite a lot of differences - but for you as a product, would you say there is a big difference now to operate in the US compared to Europe? Yeah, our product is theoretically scalable
across the world today, right. OCPP is a standard, and then OCPI is to a certain extent a standard as well, and we have launched a North American infrastructure and we are actively onboarding partners right now. It's still early, but we already have signed - I don't want to lie about it - I think it's something like 13 contracts now and onboarded like 8 partners or something like that.
We have brought on board a person I always wanted to work with, Daniel Brown, former global head of roaming at ChargePoint, and he's leading our US efforts as well as the UK efforts. He was recently there. I was there quite a lot because we also raised our seed round from a US venture capital fund - Voyager Ventures exactly, probably the leading
They always don't want me to say transatlantic, but the leading climate VC - I think now they don't want to call it climate anymore, now it's resilience or something like that - but anyway, I think I'm part of the community. They're amazing people who understand electricity and electrons better than anyone else I've met, and who are exactly as the other two VCs that are invested in us interested in financial return.
What I want to say about that is we don't have any strategic investors, right? So there's no one who will tell me, "Hey Jacob, can you please build this and that because this big company would want that." And that's so important for us to be neutral and to be solely focused on financial return. They're amazing, and that's why I spend a lot of time in the US. We like it a lot in the US. It's different, but I think our product is kind of scalable right away.
I think the main difference - and this is an interesting one - is we don't want to force anyone, also not in Europe. The very idea of an AP is you own your own contracts and commercials and therefore you have control. In the US that argument is even more important because no one wants to be forced into roaming or anything like that.
We believe that to optimize your utilization and your unit economics, it's a good idea to work with other partners - but we give you the infrastructure if you want it, and you keep control. That's very important in the US, and that's something we learned. And I think it's going really well. So you're open for business everywhere in the world right now? You're taking me at a good one, because I speak a lot about focus and the honest answer is probably yes.
There's a world where we say no to some things that are really out of our scope right now. But maybe to take a step back and think about our growth patterns: a lot of startups have a city-to-city, country-to-country, region-to-region, currency-to-currency growth pattern. That's not how we grow. We grow network to network, and if Ionity, with charge points in 24 countries, tells me, "Hey Jacob, can you please onboard these five EMSPs in the new country that I'm entering?"
Obviously I'm doing it. So that's the nature of it, and that's also what brought us to onboarding partners in the US, but also to onboarding partners in Australia, New Zealand, and other regions.
So it's a careful - it's a yes - and let's keep the focus. Yesterday I was at a conference where one leading topic was electric trucks, at the national Leitstelle - the electric mobility association linked to the government - so electric trucks are quite a hot topic right now.
Does it affect your business in some way, like booking or MCS? Yeah, so we have a feature for example that we call OCPI version interoperability, where we enable different partners to be connected to us via OCPI 2.2.1 and then roam with partners who are on 2.1.1. That is quite helpful for some partners who are still stuck with 2.1.1. Now there's a new version of OCPI, and I'm not the OCPI expert - out of our roughly 20 team members, probably
11 know it better than me, maybe even 15. But what I can say is OCPI 2.3.0 essentially has two main features driving adoption from our experience so far. On the one hand, in the locations module you have more ability to communicate more sophisticated data - for example, how big is the charging lot and things like that. And secondly, the booking module. The booking module is essentially an add-on that lets you book a slot in the future.
We believe that is highly relevant for logistics companies and especially relevant for behind-the-fence charging situations. But in public charging, at least a lot of the people I've discussed it with tell me they don't really believe in it at scale, because there are potential operational issues that arise - for example, there's another car parked there right now, so what do we do?
Those kinds of things make it quite complex to deliver a really good customer experience around booking sometimes. We're part of the EVRoaming Foundation, we're fans of the new protocol - don't get me wrong - but what I'm saying is we don't spend a lot of time on booking, and for public charging, where today our focus is, we don't feel like it's top of mind right now. Heavy duty vehicles, though, are totally top of mind, and we have onboarded the core players in the field.
I don't want to name names now, but both on the EMSP and CPO sides I think we have all of the players connected, and we're happy for them to roam through us. Why is it interesting? Because of crazy volumes, and because trucks are always driving and therefore also need to charge a lot.
So maybe last comment on that: when I entered the industry 5 years ago, there was still a lot of players in this industry running around saying, "Yeah, hydrogen - for passenger cars maybe electric is now going to be the new normal, but hydrogen for trucks I'm pretty sure." And Bavaria was kind of funding some hydrogen ideas around mobility with 200 million or whatever, right?
And it's just quite funny sometimes to take a step back and look at this again and see how this industry is now so obviously going for electrification as well. And maybe, I mean, for us that is the reason why it's sometimes frustrating to discuss things like - I don't know - we have these buzzwords in German politics like "Technologieoffenheit," openness for technology, and you're just like...
Yeah, alright, we can keep this open and kind of lose even more ground than we already have, because it's so obvious from first principles that electric mobility is going to win. And again, that's one of the big messages I want to put out there: size of the pie rather than slice of the pie. Please, let's all understand there's no alternative and it's also not going to change. Let's go. And there are a lot of people in Germany and Europe who haven't understood this.
Yeah, and just looking at the future - the last question before we end on a personal note - bidirectional charging: do you see it in public charging or only in private charging? And now that you focus clearly on public charging, do you see a big role for iapi also in private charging?
Yes, focus, right. I don't think about it too much - well, I do obviously. I can just tell you what I hear from our talks with C-levels at more or less all relevant CPOs out there, and I think they're thinking about it quite actively, also for public charge points. And that's interesting for me to hear, because obviously their identity is selling electrons, right?
And now suddenly they're going into, "OK, we're not optimizing utilization, we're actually kind of trading flexibility" - and it's like, OK, there are some open questions there, right? How this is going to be implemented, we don't know, but we do believe it's at least something that public CPOs spend time with. And for your question...
I think for a lot of these connectivity topics, we are their preferred partner to talk to, and we are very happy to discuss with them how to implement certain ideas. And for private charging - yeah, of course. We already have a lot of private charge points connected. We know that roaming is obviously a topic for private as well, and we believe that we are quite obviously the best solution out there for connectivity today, and that's both for public and private, right?
Why am I not talking about it a lot, and why am I not reaching out to CPMSs who are focused on private charge points and behind-the-fence charge points right now? Focus, right. I can't do everything, and I think we want to leverage network effects. We very clearly see these network effects in public EV charging right now, and we want to leverage on that. Alright.
And I don't know if you actually drive an electric vehicle, but if you had to share a funny, or also a bad, public charging story - and maybe one very pleasant one? OK, that's a good question. So first of all, I currently don't have a car, but actually I have two electric cars in Berlin available to me. My dad drives a Honda, my brother drives a Tesla, and I've obviously used both of these cars a lot for charging transactions. I think the most delightful one to break it down is...
Yeah, what is it called - essentially a trip that we did at one of our on-sites in Berlin, where most of our team members came to Berlin. Our new team member Daniel Brown essentially did a tour with us through Berlin from ChargePoint to ChargePoint, and obviously our engineers took their computers with them and tracked everything a little bit, and that was fun. That was very nice - two cars, eight people, just enjoying themselves. And then, do I have a bad story? To be honest, I obviously hear about bad stories everywhere, right?
I mean, I tell my family, or friends of my family, or my parents, or investors - I tell them connectivity doesn't really work, and more or less, I would say 90% of the people I tell this to say, "Yeah, that's true. I was on holiday once somewhere, I had an electric car, and it was really awful." And I heard like 20 of these stories more or less in the last two weeks again. So yeah, I'm looking forward to fixing it, but I don't want to add more stories.
Well then, with that, we end on a good positive note - you're doing your best to fix it very quickly, I'm sure. Thanks a lot, Jago, for your hard work and for being here today. Thank you so much. Thanks for the invite. Three things stay with me from this conversation. First, the price of connectivity. Even a fee of 5 cents per session adds up at 1 million sessions a month, and that gives partners every reason to build their own direct connections instead. Jacob's conclusion: no one who charges for connectivity will win in the long run. Second, clearing.
Because Enapi brokers the transaction itself, it can compare invoiced charge detail records with the sessions it actually authorized and find duplicates or missing records. Third, AI. More than 94% of Enapi's production code is now written with AI, yet the parts that cannot go down are touched only with utmost care, and the uptime is public for anyone to check. Jacob's word for all of it is focus. Thank you for listening to Smart Charge by RiDERgy. If this episode was useful, share it with someone who works on charging infrastructure, or give us a 5-star review. See you next time.
Notities bij de aflevering
With 500 players on each side of the market, connecting everyone to everyone takes 250,000 bilateral integrations, and every one of them needs a handshake, testing and maintenance. Jakob Kleihues, co-founder of ENAPI, argues that connectivity between charge point operators and mobility service providers should be a free commodity, and that the real money is in financial clearing. Jakob explains why connecting to hundreds of partners one by one does not scale: with 500 players on each side of the market, that is 250,000 bilateral integrations, and every one of them needs a handshake, testing and maintenance. ENAPI replaces them with a single connection. Since it started onboarding, it has connected more than 450 partners and over one million charge points, with implementation times that rarely exceed one or two weeks. He also shows why even a fee of five cents per session pushes volume towards direct connections, and how brokering the transaction lets ENAPI check invoiced charge detail records against the sessions it authorized. The conversation also covers the practical side of pricing, from discounts applied at charge detail record level instead of a flat reduction on the invoice to the new booking module in OCPI 2.3, and what it takes to keep a published 99.998 percent uptime with a very small team where more than 94 percent of production code is written by AI. Jakob explains why the US, Australia and New Zealand followed network by network rather than country by country, and why he wants the industry to think about the size of the pie rather than the slice. An episode about turning connectivity into a commodity, and about what it takes to make public charging simply work. Topics covered: - OCPI and why bilateral integrations do not scale - Free connectivity and the business case for financial clearing - Validating charge detail records - Discounts, variable prices and the booking module - Uptime and AI native engineering - Growing network by network into the US