Jeremie Lebrun lavora in BlaBlaCar da sei anni, dopo un decennio trascorso nella consulenza. Oggi, come Head of Engineering per i servizi aziendali interni, guida un team di 35 persone responsabile di tutti gli strumenti interni dell'azienda: laptop, reti, strumenti HR, finanza, CRM, automazione e applicazioni relative all'attività bus. In breve, tutto ciò che non è direttamente rivolto agli utenti finali, ma consente agli 800 dipendenti, distribuiti in sei paesi, di lavorare efficacemente.

Quali criteri tecnici e aziendali guidano le vostre scelte tra sviluppo interno e strumenti di terze parti?

Jeremie Lebrun: Probabilmente non siamo molto originali: da un lato, i developer sono una risorsa rara. Dall'altro, esistono sul mercato soluzioni progettate da persone più mature di noi su molti argomenti, che ci hanno già pensato a lungo.

Il nostro principio è semplice: tutto ciò che è differenziante rispetto alla concorrenza e ci aiuta a far avanzare la visione di prodotto, lo sviluppiamo internamente. Al contrario, tutto ciò che non è differenziante, cerchiamo "off the shelf". Ad esempio, non ha senso per noi sviluppare software di finanza e contabilità. D'altra parte, per i nostri algoritmi di moderazione degli scambi tra carpooler, siamo gli unici ad avere esperienza e contesto di business: quello rimane sviluppo interno.

Ma tra i due esiste una zona grigia. Gli arbitraggi vengono poi effettuati su criteri di manutenibilità, copertura di mercato, costo e impatto organizzativo.

Un esempio: per il servizio BlaBlaCar Bus, abbiamo dovuto implementare un sistema di comunicazione con i passeggeri in caso di ritardi. Inizialmente abbiamo acquistato una soluzione esistente perché non avevamo il team disponibile e non sapevamo ancora esattamente cosa volevamo. Due anni dopo, con le esigenze più chiare, abbiamo internalizzato lo sviluppo.

Come valutate il costo reale del "build" rispetto al costo del "buy"?

Jeremie Lebrun: Sul lato build, occorre calcolare: quale team è coinvolto, per quanto tempo, con quale complessità infrastrutturale e di prodotto. La nostra esperienza ci consente di stimare la dimensione del team necessario e la timeline di consegna. Cerchiamo sempre di attenerci a tecnologie che già padroneggiamo, per evitare di aggiungere debito tecnico non necessario.

Sul lato buy, non si tratta solo di licenze. C'è sempre un costo di configurazione, connessione ai sistemi interni, amministrazione, sicurezza e prodotto. Poi bisogna considerare la manutenzione nel tempo. Un SaaS non elimina i problemi: porta anche la sua quota di evoluzioni e vincoli.

La dipendenza dal vendor fa parte della scelta iniziale. Non ci si può aspettare di avere la botte piena e la moglie ubriaca: quando si sceglie una soluzione SaaS, bisogna accettare una certa dipendenza, assumerla e gestirla di conseguenza.

In un contesto come quello di BlaBlaCar, dove la piattaforma deve gestire una forte crescita e picchi di traffico, quali decisioni build vs buy si rivelano più strutturanti?

Jeremie Lebrun: Abbiamo un approccio pragmatico: il debito tecnico non è una parola sporca. Può avere valore se permette di accelerare il time-to-market. L'importante è accettarlo collettivamente fin dall'inizio, come il debito finanziario: sappiamo che dovremo ripagarlo in seguito, ma il beneficio immediato potrebbe essere maggiore del costo futuro.

Esempio: per il nostro sistema di invio SMS ai passeggeri, abbiamo prima acquistato una soluzione esterna. In due anni, abbiamo inviato più di 4 milioni di SMS, il che ci ha permesso di guadagnare più di 10 punti NPS. Quando abbiamo internalizzato, sapevamo esattamente cosa volevamo fare. Il lavoro di pura codifica restava da fare, ma l'80% del lavoro di product management era già stato completato, rendendo lo sviluppo più rapido e pertinente.

Avete rimpianti per alcune delle vostre scelte?

Jeremie Lebrun: Ci sono stati casi in cui non avevamo scelto il partner giusto e abbiamo dovuto cambiare. Ma nel complesso, si tratta di aggiustamenti normali nella vita di un progetto ingegneristico, e siamo stati fortunati a non rimpiangere una scelta tra make e buy.

Come influenzano le vostre scelte build vs buy la cultura tech e l'organizzazione del team di BlaBlaCar?

Jeremie Lebrun: Storicamente, BlaBlaCar ha una forte cultura tech: tutto veniva sviluppato internamente. L'introduzione di soluzioni SaaS e low-code ha quindi richiesto un vero lavoro educativo. Abbiamo dovuto depoliticizzare il dibattito: certo, i nostri developer possono scrivere tutto, ma il loro tempo è prezioso. Sviluppare uno strumento di ticketing non avrebbe senso.

Questo comporta anche una gestione del cambiamento: uno squad agile che consegna ogni due settimane non lavora allo stesso ritmo di un vendor SaaS che distribuisce una nuova versione ogni due mesi. Abbiamo dovuto armonizzare i metodi di lavoro, snellire la comunicazione e allineare le aspettative.

Non c'è anche un problema di ego da gestire tra i developer?

Jeremie Lebrun: Sì, come ovunque quando si confrontano due approcci. Ma ci sono profili di developer che in realtà amano orientarsi verso l'ecosistema SaaS, come Salesforce. Altri sono stanchi di scrivere sempre le stesse cose e trovano nuova linfa nell'amministrazione o nell'integrazione. L'importante è depoliticizzare la questione: sì, i nostri developer possono fare tutto, ma a volte è più intelligente usare una soluzione già pronta all'80%.

Che consiglio dareste alle startup e alle scale-up che affrontano queste scelte?

Jeremie Lebrun: Rimanete molto aperti e obiettivi. Molte scale-up vogliono costruire tutto da sole, ma esternalizzano rapidamente la parte "ops" (CRM, automazione). Ciò che conta è tenere conto del costo completo: build, manutenzione, organizzazione, dipendenza. Non esiste una scelta intrinsecamente buona o cattiva, solo analisi buone o cattive.

E soprattutto: non date per scontata la natura scalabile o non scalabile di una tecnologia. In BlaBlaCar, abbiamo inviato milioni di SMS tramite una soluzione low-code, con successo. Ma perché questo funzioni, il progetto deve essere supportato dai team tech (architettura, testing) e non solo dai team business. Altrimenti, il rischio è che la soluzione non scali.

Punti chiave

• BlaBlaCar sviluppa internamente le funzionalità essenziali e differenzianti, e utilizza soluzioni di terze parti per i processi standard.
• La valutazione dei costi include non solo lo sviluppo o le licenze, ma anche la manutenzione e l'impatto organizzativo.
• Il debito tecnico può essere una leva strategica se accompagnato da un chiaro ROI.
• L'integrazione di SaaS e low-code richiede un vero lavoro di gestione del cambiamento e di comunicazione tra i team.