Ditt meddelande har skickats.
Vi behandlar din begäran och återkommer till dig så snart som möjligt.
Formuläret har skickats in framgångsrikt.
Ytterligare information finns i din brevlåda.


Innowise tog kundens tidiga produkt och byggde om den till en solid, högpresterande laddningsplattform för elbilar. Den hanterar nu miljontals sessioner och hjälper företaget att leda den europeiska marknaden.*
laddningssessionens register exporteras direkt
ökning av antalet användare genom lansering av eRoaming

Vår kund är ett tyskt företag som hjälper företag att driva sina egna laddningsnätverk för elfordon. Deras plattform hanterar allt från stationshantering och fakturering till användaråtkomst och energikontroll. Den stöder privat och offentlig laddning med verktyg för realtidsövervakning, prissättning och tredjepartsanslutningar. Systemet är white-label, så att företag kan lansera under sitt eget varumärke utan att bygga tekniken från grunden.
Detaljerad information om kunden kan inte lämnas ut enligt bestämmelserna i NDA.
Kunden planerade att växa i hela EU och ge förarna en smidig, allt-i-ett-laddningsupplevelse. Men webbappen - det huvudsakliga verktyg som förarna använde - var inte redo för detta. Användarna kunde inte få tillgång till liveuppdateringar, använda sina kort på tredjepartsstationer eller kontrollera vad som hände under en laddningssession. Funktioner som eRoaming, smart energistyrning och sessionsspårning saknades, vilket var viktigt för att sticka ut på en konkurrensutsatt marknad och få nya partnerskap. Internt fungerade frontend bra, men backend och infrastruktur behövde rejält med hjälp.
Under huven var webbapplikationen redan hårt ansträngd. Den kunde inte hantera stora dataexporter, hade ingen realtidssökning och stödde inte viktiga EV-protokoll som OCPI eller OICP. eRoaming var ett måste, men det fanns inget sätt att koppla in det utan att se över arkitekturen. Kodbasen var svår att underhålla, distributionerna var manuella och prestandaproblemen var nästan omöjliga att spåra. Utan en solid backend, DevOps-pipeline eller observerbarhetsverktyg var plattformen inte redo för skalning.
Vår kund driver en fullserviceplattform för elektrisk mobilitet som kombinerar fysisk infrastruktur med intelligent digital kontroll. De agerar både som CPO och EMSP och äger hela laddningsupplevelsen från hårdvara till gränssnitt.
Förarna får tillgång till tjänsten via webb- och mobilappar där de kan hitta stationer, starta laddningssessioner och betala. Plattformen hanterar realtidskommunikation med externa CPO:er med hjälp av standardprotokoll, stöder gränsöverskridande eRoaming via Hubject och hanterar alla kommersiella relationer i bakgrunden.
Ekosystemet omfattar verktyg för smart laddning och energihantering för infrastrukturpartners, tillsammans med diagnostik, firmwarehantering och säkra API:er som möjliggör sömlös integration med anpassade användargränssnitt för företag.
Faktureringen hanteras via ett flexibelt system som stöder tredjepartsbetalningsleverantörer som Fiserv, avtalsbaserad prissättning, PDF-rendering och Excel-export. Systemet är anpassat för unika betalningsregler för olika partners.
Aviseringssystem finns på plats för både transaktionsmeddelanden och realtidsvarningar, skräddarsydda för företagskunder. Plattformen erbjuder också sessionskontroll, rapporteringsmoduler och fjärrdiagnostik.
Det här är mer än en produkt som vänder sig till konsumenter. Det är ett skalbart kontrollager som sammanför laddningsinfrastruktur, partnerhantering, fakturering och analys i ett sammanhängande ekosystem.
Vi började med att ta ett steg tillbaka och titta på hela systemet. Vad var det som höll det tillbaka? Vilka funktioner efterfrågade förare och operatörer egentligen? Var gick saker och ting sönder när användningen ökade?
I nära samarbete med kundens produkt- och affärsteam identifierade vi tre viktiga smärtpunkter som krävde omedelbar uppmärksamhet:
I stället för att försöka åtgärda allt på en gång delade vi upp arbetet i hanterbara faser. Först fokuserade vi på att göra det befintliga systemet mer stabilt och tillförlitligt. Sedan byggde vi den grund som behövdes för att skala upp: bättre API:er, renare integrationer och verktyg som driftteamet faktiskt kunde använda i vardagen.
När vi förstod kärnproblemen delade vi upp kodbasen i mindre, oberoende moduler så att nya funktioner kunde läggas till utan att förstöra befintliga. I hela systemet byggde våra experter ett cachningslager som minskade latensen och förbättrade svarstiderna.
För partnerintegrationer har vi infört standardiserade API-gränssnitt och automatiserat stora delar av arbetsflödet. Det som tidigare krävde veckor av anpassad kodning tar nu bara några dagar att installera. Vi införde också strikta validerings- och felkontroller så att data från laddstationerna var korrekta och användbara.
På infrastruktursidan konfigurerade vi om plattformen för horisontell skalning. Den absorberar nu tung trafik utan att sakta ner, vilket ger kunden ett system som växer lika snabbt som deras nätverk.
Med plattformen på plats kunde vi ta itu med den första stora utmaningen: stationshanteringen. Kundens nätverk expanderade snabbt. Vissa stationer var deras egna, andra tillhörde partners, men systemet kunde inte prata med dem alla på ett konsekvent sätt. Vi löste detta genom att implementera fullt stöd för OCPP 1.6, det branschstandardprotokoll som de flesta elbilsladdare använder.
Detta gav driftteamet fullständig fjärrkontroll över sitt nätverk. De kunde starta och stoppa laddningssessioner, se vad som hände i realtid och köra diagnostik på alla stationer från en och samma instrumentpanel. När nya hårdvarupartners kom ombord fanns det inget behov av anpassade lösningar. Det är bara att plugga in, konfigurera och så fungerar det.
Nästa utmaning var mycket större: att göra det möjligt för förarna att ladda vid stationer utanför kundens nätverk. För förarna borde laddning vara enkelt - plugga in och det bara fungerar. Men under ytan är det en trasslig väv av kontrakt, protokoll och datautbyten mellan företag. Vi löste detta genom att ansluta oss till Hubject, Europas största EV eRoaming-nätverk. Vi implementerade både OCPI och OICP för att hantera nätverksöverskridande auktorisering, stationsuppdateringar i realtid och spårning av användning. Det innebär att förarna kan använda tredjepartsstationer direkt via kundens app, utan att behöva registrera sig för ett dussin olika konton. Företaget behöver inte bygga laddinfrastruktur överallt, de ansluter bara till de nätverk som redan finns genom Hubject.
Nu när förarna har tillgång till stationer i flera olika nätverk vände vi blicken mot ett växande problem: energihantering. Efterfrågan på el fluktuerar ständigt och ingen vill överbelasta elnätet. Kunden behövde ett sätt att hjälpa stationsoperatörer att ligga steget före under perioder med hög efterfrågan.
Vi har byggt ett smart laddningssystem som ger operatörerna kontroll över hur och när energin levereras. De kan sätta användningsgränser under rusningstid, synkronisera med nätets tillgänglighet eller låta systemet automatiskt optimera leveransen baserat på realtidsförhållanden. Detta skyddar elnätet, håller driftskostnaderna nere och ger energibolagen större förtroende för den långsiktiga hållbarheten för laddning av elbilar.
Vi har också lagt till tidsbegränsad laddning för företagskunder, så att företag nu kan sätta sessionsgränser på t.ex. 30 minuter för att hålla laddningen av sin vagnpark rättvis och effektiv.
Alla dessa nya funktioner och utökade nätverksmöjligheter innebar att exponentiellt mer data flödade genom systemet. Tyvärr kunde det gamla exportsystemet inte hålla jämna steg. Det var en ständig källa till frustration - allt över 10 000 poster kraschade och lämnade teamen med ofullständiga rapporter och timmar av manuell datajakt. Vårt team byggde om exportsystemet från grunden. Nu tuggar det igenom dataset med flera miljoner poster med fullständiga detaljer - stations-ID, användarinformation, sessionstid, prissättning och så vidare. Allt kommer ut i Excel-klara format som du omedelbart kan dela med finans-, juridiska eller affärspartners. Och ja, det går snabbt, även när du hämtar data från konton med stora volymer.
Utan live-data reagerade kunden alltid på problem efter att de redan hade påverkat kunderna. Vi byggde ett livesänt analyssystem som spårar laddningssessioner när de inträffar.
Driftteamet ser nu mätvärden i realtid för energiförbrukning, sessionslängd och stationens hälsa. När en laddare går offline eller börjar förbruka ovanliga mängder ström får de omedelbara varningar och kan ingripa innan det blir ett större problem. Allt matas in i en central instrumentpanel, så att beslut kan fattas snabbt och servicen förblir tillförlitlig.
Vi visste från dag ett att det här inte skulle bli ett projekt av plug-and-play-typ. Plattformen hade så mycket potential, men det krävdes en hel del arbete under huven. Det som gjorde det speciellt var partnerskapet - kunden var öppen, engagerad och laserfokuserad på slutmålet. Och vårt team dök upp med allt de hade. Det var tufft, men det var den typ av utmaning som vi älskar. Vi är stolta över resultatet och ännu stoltare över människorna bakom det.

Vi arbetade i veckovisa sprintar med tydliga mål och snabb återkoppling. Vårt team hanterade planering, testning och driftsättning, medan kunden fokuserade på funktionsprioriteringar och affärspåverkan. Det här upplägget gav oss snabbheten att arbeta självständigt, med regelbundna avstämningar för att snabbt komma överens om avvägningar och avblockera beslut.
För att minska risken använde vi stegvisa utrullningar, funktionsflaggor och automatiserade tester för att fånga upp problem innan de når produktionen. Partnerintegrationer och protokolländringar lanserades genom kontrollerade utrullningar, med realtidsövervakning på plats om något skulle gå snett.
Ingenting i den här uppbyggnaden passade alla. eRoaming, fakturering och partnerlogik hade alla sin egen komplexitet. Kunden litade på att vi skulle leda leveransen och vi såg till att de alltid hade insyn i vad vi gjorde, varför det var viktigt och var de behövdes.
Go, gRPC, GraphQL (gqlgen, magidoc), Gorilla/Mux, HTTP REST, excelize, testify, go-mock, Keycloak IAM
TypeScript, Angular, PrimeNG, PrimeFlex, Bootstrap, Keycloak JS-adapter, Karma
PostgreSQL, CockroachDB, MongoDB, ElasticSearch, OpenSearch
Linux-baserad (härledd från driftsättningsmiljön)
Nginx
OCPP 1.6, OCPI, OICP, eRoaming och fakturering: Hubject, Fiserv, Hectronic
Docker, Docker Compose, Helm (för K8s-driftsättningar), Kubernetes (k8s), Hetzner VPS, Helm-diagram, Kibana, OpenSearch Dashboard
GitHub Actions
Docker, Kubernetes
Git, GitHub
Prometheus, Grafana, OpenTelemetry
Testify, go-mock, Karma (frontend)

Ditt meddelande har skickats.
Vi behandlar din begäran och återkommer till dig så snart som möjligt.

Genom att registrera dig godkänner du vår Integritetspolicy, inklusive användning av cookies och överföring av din personliga information.