Jeremie Lebrun werkt al zes jaar bij BlaBlaCar, na een decennium in de consultancy. Vandaag leidt hij als Head of Engineering – Corporate Services een team van 35 mensen dat verantwoordelijk is voor alle interne bedrijfstools: laptops, netwerken, HR-tools, financiën, CRM, automatisering en applicaties gerelateerd aan de busactiviteit. Kortom, alles wat niet direct gericht is op eindgebruikers maar de 800 medewerkers, verspreid over zes landen, in staat stelt efficiënt te werken.

Welke technische en zakelijke criteria sturen je keuzes tussen intern ontwikkelen of een externe tool gebruiken?

Jeremie Lebrun: We zijn waarschijnlijk niet erg origineel: enerzijds zijn ontwikkelaars een schaarse resource. Anderzijds zijn er oplossingen op de markt die zijn ontworpen door mensen die op veel gebieden volwassener zijn dan wij en er al veel over hebben nagedacht.

Ons principe is simpel: alles wat onderscheidend is ten opzichte van de concurrentie en ons helpt onze productvisie te realiseren, ontwikkelen we intern. Omgekeerd zoeken we voor alles wat niet onderscheidend is naar kant-en-klare oplossingen. Zo heeft het voor ons geen zin om financiële en boekhoudkundige software te ontwikkelen. Maar voor onze algoritmen die uitwisselingen tussen carpoolers modereren, zijn wij de enigen met de ervaring en bedrijfscontext: dat blijft interne ontwikkeling.

Maar er is een grijs gebied. Arbitrages worden dan gemaakt op criteria van onderhoudbaarheid, marktdekking, kosten en organisatorische impact.

Een voorbeeld: voor de BlaBlaCar Bus-service moesten we een communicatiesysteem opzetten met passagiers bij vertragingen. In eerste instantie kochten we een bestaande oplossing omdat we het team niet beschikbaar hadden en nog niet precies wisten wat we wilden. Twee jaar later, toen de inzetten specifieker werden, internaliseerden we de ontwikkeling.

Hoe evalueer je de werkelijke kosten van "build" versus de kosten van "buy"?

Jeremie Lebrun: Aan de build-kant moet je berekenen: welk team is betrokken, hoe lang, met welke infrastructuur- en productcomplexiteit. Onze ervaring stelt ons in staat de benodigde teamomvang en leveringstijdlijn te schatten. We proberen altijd te werken met technologieën die we al beheersen, om onnodige technische schuld te vermijden.

Aan de buy-kant gaat het niet alleen om licenties. Er zijn altijd kosten voor configuratie, aansluiting op interne systemen, beheer, beveiliging en product. Daarna moet je rekening houden met onderhoud in de loop der tijd. Een SaaS elimineert problemen niet: het brengt ook zijn eigen deel aan evoluties en beperkingen mee.

Leveranciersafhankelijkheid maakt deel uit van de initiële keuze. Je kunt niet verwachten alles te hebben: wanneer je een SaaS-oplossing kiest, moet je een zekere afhankelijkheid accepteren, dit erkennen en er overeenkomstig mee omgaan.

In een context zoals die van BlaBlaCar, waar het platform sterke groei en verkeerspieken moet aankunnen, welke build- versus buy-beslissingen zijn dan het meest structurerend?

Jeremie Lebrun: We hanteren een pragmatische aanpak: technische schuld is geen vies woord. Het kan waarde hebben als het de time-to-market versnelt. Het belangrijkste is om het collectief vanaf het begin te accepteren, zoals financiële schuld: we weten dat we het later moeten terugbetalen, maar het onmiddellijke voordeel kan groter zijn dan de toekomstige kosten.

Voorbeeld: voor ons SMS-verzendingssysteem naar passagiers kochten we eerst een externe oplossing. Twee jaar lang verstuurden we meer dan 4 miljoen sms-berichten, waardoor we meer dan 10 NPS-punten wonnen. Toen we internaliseerden, wisten we precies wat we wilden doen. Het pure coderingswerk stond nog te doen, maar 80% van het productmanagementwerk was al voltooid, wat de ontwikkeling sneller en relevanter maakte.

Heb je spijt van een van je keuzes?

Jeremie Lebrun: Er waren gevallen waarbij we niet de juiste partner hadden gekozen en moesten wisselen. Maar over het algemeen zijn dit normale aanpassingen in het leven van een engineeringproject, en we zijn gelukkig geweest geen spijt te hebben van een keuze tussen make en buy.

Hoe beïnvloeden je build- versus buy-keuzes de techcultuur en teamorganisatie van BlaBlaCar?

Jeremie Lebrun: Historisch heeft BlaBlaCar een sterke techcultuur: alles werd intern ontwikkeld. De introductie van SaaS- en low-code-oplossingen vereiste dan ook echt educatief werk. We moesten het debat depolitiseren: natuurlijk kunnen onze ontwikkelaars alles coderen, maar hun tijd is kostbaar. Een ticketingtool ontwikkelen zou nergens op slaan.

Dit omvat ook verandermanagement: een agile squad die elke twee weken iets oplevert, werkt niet in hetzelfde tempo als een SaaS-leverancier die elke twee maanden een nieuwe versie uitrolt. We moesten werkmethoden harmoniseren, communicatie stroomlijnen en verwachtingen op één lijn brengen.

Is er ook een ego-kwestie te managen bij ontwikkelaars?

Jeremie Lebrun: Ja, zoals overal wanneer twee benaderingen worden vergeleken. Maar er zijn ontwikkelaarprofielen die zich graag oriënteren op het SaaS-ecosysteem, zoals Salesforce. Anderen zijn moe van altijd dezelfde dingen te coderen en vinden nieuwe adem in beheer of integratie. Het belangrijkste is het debat te depolitiseren: ja, onze devs kunnen alles, maar soms is het slimmer om een oplossing te gebruiken die al voor 80% klaar is.

Welk advies zou je geven aan startups en scale-ups die voor deze keuzes staan?

Jeremie Lebrun: Blijf heel open en objectief. Veel scale-ups willen alles zelf bouwen, maar externaliseren snel het "ops"-gedeelte (CRM, automatisering). Wat telt, is rekening houden met de totale kosten: build, onderhoud, organisatie, afhankelijkheid. Er is geen inherent goede of slechte keuze, alleen goede of slechte analyses.

En bovenal: neem de schaalbaarheid of niet-schaalbaarheid van een bepaalde technologie niet voor lief. Bij BlaBlaCar hebben we miljoenen sms-berichten verzonden via een low-code-oplossing, met succes. Maar daarvoor moet het project worden ondersteund door techteams (architectuur, testen) en niet alleen door zakelijke teams. Anders is het risico dat de oplossing niet schaalt.

Belangrijkste inzichten

• BlaBlaCar ontwikkelt essentiële en onderscheidende functies intern en gebruikt externe oplossingen voor standaardprocessen.
• Kostenevaluatie omvat niet alleen ontwikkeling of licenties, maar ook onderhoud en organisatorische impact.
• Technische schuld kan een strategische hefboom zijn als deze gepaard gaat met duidelijke ROI.
• Integratie van SaaS en low-code vereist echt verandermanagement en communicatiewerk tussen teams.