Jeremie Lebrun har jobbat på BlaBlaCar i sex år, efter ett decennium inom konsultbranschen. I dag, som Head of Engineering för Corporate Services, leder han ett team på 35 personer ansvariga för alla interna företagsverktyg: laptops, nätverk, HR-verktyg, finans, CRM, automatisering och applikationer kopplade till bussverksamheten. Kort sagt, allt som inte direkt riktar sig till slutanvändare men som gör att de 800 anställda, spridda över sex länder, kan arbeta effektivt.

Vilka tekniska och affärsmässiga kriterier styr dina val mellan att utveckla en lösning internt eller använda ett tredjepartsverktyg?

Jeremie Lebrun: Vi är förmodligen inte särskilt originella: å ena sidan är utvecklare en sällsynt resurs. Å andra sidan finns det lösningar på marknaden skapade av folk som är mer mogna än oss på många ämnen, som redan har tänkt mycket på dem.

Vår princip är enkel: allt som är differentierande jämfört med konkurrensen och hjälper oss att driva vår produktvision framåt, utvecklar vi internt. Omvänt söker vi "off the shelf" för allt som inte är differentierande. Det finns till exempel inget intresse för oss att utveckla finans- och redovisningsprogramvara. Däremot, för våra algoritmer som modererar utbyten mellan samåkningspassagerare, är vi de enda med erfarenheten och affärskontexten: det förblir intern utveckling.

Men däremellan finns det en gråzon. Avvägningar görs sedan utifrån kriterier som underhållbarhet, marknadstäckning, kostnad och organisatorisk påverkan.

Ett exempel: för BlaBlaCar Bus-tjänsten var vi tvungna att sätta upp ett kommunikationssystem med passagerare vid förseningar. Initialt köpte vi en befintlig lösning eftersom vi inte hade teamet tillgängligt och inte visste exakt vad vi ville ha ännu. Två år senare, när insatserna blev mer specifika, internaliserade vi utvecklingen.

Hur utvärderar du den verkliga kostnaden för "build" kontra kostnaden för "buy"?

Jeremie Lebrun: På build-sidan behöver du beräkna: vilket team är involverat, hur länge, med vilken infrastruktur och produktkomplexitet. Vår erfarenhet låter oss uppskatta nödvändig teamstorlek och leveranstidsram. Vi försöker alltid hålla oss till teknologier vi redan behärskar, för att undvika att lägga till onödig teknisk skuld.

På buy-sidan handlar det inte bara om licenser. Det finns alltid en kostnad för konfiguration, anslutning till interna system, administration, säkerhet och produkt. Sedan måste du ta hänsyn till underhåll över tid. En SaaS eliminerar inte problem: den tar också med sig sin del av förändringar och begränsningar.

Leverantörsberoende är en del av det initiala valet. Du kan inte ha kakan och äta den också: när du väljer en SaaS-lösning måste du acceptera ett visst beroende, äga det och hantera det därefter.

I ett sammanhang som BlaBlaCars, där plattformen måste hantera stark tillväxt och trafikstoppar, vilka build vs buy-beslut visar sig mest strukturerande?

Jeremie Lebrun: Vi har ett pragmatiskt förhållningssätt: teknisk skuld är inte ett smutsigt ord. Den kan ha värde om den tillåter att påskynda time-to-market. Det viktiga är att acceptera det kollektivt från start, som finansiell skuld: vi vet att vi måste betala tillbaka senare, men den omedelbara fördelen kan vara större än den framtida kostnaden.

Exempel: för vårt SMS-skickningssystem till passagerare köpte vi först en extern lösning. Under två år skickade vi mer än 4 miljoner SMS, vilket lät oss vinna mer än 10 NPS-poäng. När vi internaliserade visste vi exakt vad vi ville göra. Det rena kodningsarbetet återstod att göra, men 80 % av produktledningsarbetet hade redan slutförts, vilket gjorde utvecklingen snabbare och mer relevant.

Ångrar du några av dina val?

Jeremie Lebrun: Det fanns fall där vi inte hade valt rätt partner och var tvungna att byta. Men sammantaget är dessa normala justeringar i ett ingenjörsprojekts liv, och vi har haft turen att inte ångra ett val mellan make och buy.

Hur påverkar dina build vs buy-val BlaBlaCars techkultur och teamorganisation?

Jeremie Lebrun: Historiskt sett har BlaBlaCar en stark techkultur: allt utvecklades internt. Införandet av SaaS- och low-code-lösningar krävde därför verkligt pedagogiskt arbete. Vi var tvungna att avpolitisera debatten: självklart kan våra utvecklare koda allt, men deras tid är dyrbar. Att utveckla ett ärendehanterings verktyg vore meningslöst.

Detta involverar också förändringsledning: ett agilt squad som levererar varannan vecka arbetar inte i samma takt som en SaaS-leverantör som driftsätter en ny version varannan månad. Vi var tvungna att harmonisera arbetsmetoder, effektivisera kommunikation och anpassa förväntningar.

Finns det inte också ett egofråga att hantera bland utvecklare?

Jeremie Lebrun: Ja, som överallt när man jämför två förhållningssätt. Men det finns utvecklarprofiler som faktiskt gillar att orientera sig mot SaaS-ekosystemet, som Salesforce. Andra är trötta på att alltid koda samma saker och hittar ny luft i administration eller integration. Det viktigaste är att avpolitisera frågan: ja, våra devs kan göra allt, men ibland är det smartare att använda en lösning som redan är 80 % klar.

Vilket råd skulle du ge startups och scale-ups inför dessa val?

Jeremie Lebrun: Var väldigt öppen och objektiv. Många scale-ups vill bygga allt själva, men outsourcar snabbt "ops"-delen (CRM, automatisering). Det som spelar roll är att ta hänsyn till den totala kostnaden: build, underhåll, organisation, beroende. Det finns inget i grunden bra eller dåligt val, bara bra eller dåliga analyser.

Och framför allt: ta inte för givet att en given teknologi är skalbar eller icke-skalbar. På BlaBlaCar har vi skickat miljontals SMS via en low-code-lösning, framgångsrikt. Men för att detta ska fungera måste projektet stödjas av techteam (arkitektur, testning) och inte bara av affärsteam. Annars är risken att lösningen inte skalar.

Viktigaste insikterna

• BlaBlaCar utvecklar essentiella och differentierande funktioner internt, och använder tredjepartslösningar för standardprocesser.
• Kostnadsbedömningen inkluderar inte bara utveckling eller licensiering, utan också underhåll och organisatorisk påverkan.
• Teknisk skuld kan vara ett strategiskt verktyg om det åtföljs av tydlig ROI.
• Integration av SaaS och low-code kräver verkligt förändringsledning och kommunikationsarbete mellan team.