Jeremie Lebrun ist seit sechs Jahren bei BlaBlaCar, nach einem Jahrzehnt in der Beratung. Heute leitet er als Head of Engineering für Corporate Services ein Team von 35 Personen, das für alle internen Unternehmenstools verantwortlich ist: Laptops, Netzwerke, HR-Tools, Finanzen, CRM, Automatisierung und Anwendungen im Zusammenhang mit dem Busgeschäft. Kurz gesagt, alles, was nicht direkt auf Endnutzer ausgerichtet ist, aber es den 800 Mitarbeitern in sechs Ländern ermöglicht, effizient zu arbeiten.

Welche technischen und geschäftlichen Kriterien leiten Ihre Entscheidungen zwischen der internen Entwicklung einer Lösung und dem Einsatz eines Drittanbieter-Tools?

Jeremie Lebrun: Wir sind wahrscheinlich nicht sehr originell: Einerseits sind Entwickler eine seltene Ressource. Andererseits gibt es auf dem Markt Lösungen, die von Menschen entwickelt wurden, die in vielen Bereichen reifer sind als wir und bereits viel darüber nachgedacht haben.

Unser Prinzip ist einfach: Alles, was im Vergleich zur Konkurrenz differenzierend ist und uns hilft, unsere Produktvision voranzutreiben, entwickeln wir intern. Umgekehrt suchen wir für alles, was nicht differenzierend ist, nach "Off-the-shelf"-Lösungen. Es macht zum Beispiel keinen Sinn für uns, Finanz- und Buchhaltungssoftware zu entwickeln. Für unsere Algorithmen zur Moderation von Austauschen zwischen Mitfahrern hingegen sind wir die einzigen mit der Erfahrung und dem Geschäftskontext: Das bleibt interne Entwicklung.

Zwischen diesen beiden Extremen gibt es jedoch eine Grauzone. Abwägungen werden dann nach Kriterien der Wartbarkeit, Marktabdeckung, Kosten und organisatorischen Auswirkungen getroffen.

Ein Beispiel: Für den BlaBlaCar-Bus-Service mussten wir ein Kommunikationssystem mit Fahrgästen bei Verspätungen einrichten. Zunächst kauften wir eine bestehende Lösung, weil wir kein verfügbares Team hatten und noch nicht genau wussten, was wir wollten. Zwei Jahre später, als die Anforderungen konkreter wurden, internationalisierten wir die Entwicklung.

Wie bewerten Sie die tatsächlichen Kosten von "Build" versus die Kosten von "Buy"?

Jeremie Lebrun: Auf der Build-Seite müssen Sie berechnen: Welches Team ist beteiligt, wie lange, mit welcher Infrastruktur und Produktkomplexität? Unsere Erfahrung ermöglicht es uns, die notwendige Teamgröße und den Lieferzeitplan abzuschätzen. Wir versuchen immer, bei Technologien zu bleiben, die wir bereits beherrschen, um unnötige technische Schulden zu vermeiden.

Auf der Buy-Seite geht es nicht nur um Lizenzen. Es gibt immer Kosten für Konfiguration, Anbindung an interne Systeme, Administration, Sicherheit und Produkt. Dann müssen Sie die Wartung über die Zeit berücksichtigen. Ein SaaS eliminiert keine Probleme: Er bringt auch seinen Anteil an Entwicklungen und Einschränkungen mit sich.

Die Anbieterabhängigkeit ist Teil der ursprünglichen Entscheidung. Man kann nicht beides haben: Wenn man sich für eine SaaS-Lösung entscheidet, muss man eine gewisse Abhängigkeit akzeptieren, sie eingestehen und entsprechend damit umgehen.

In einem Kontext wie dem von BlaBlaCar, wo die Plattform starkes Wachstum und Verkehrsspitzen bewältigen muss, welche Build-vs.-Buy-Entscheidungen erweisen sich als am strukturierendsten?

Jeremie Lebrun: Wir haben einen pragmatischen Ansatz: Technische Schulden sind kein Schimpfwort. Sie können Wert haben, wenn sie die Time-to-Market beschleunigen. Das Wichtige ist, sie von Anfang an kollektiv zu akzeptieren, wie finanzielle Schulden: Wir wissen, dass wir sie später zurückzahlen müssen, aber der unmittelbare Nutzen kann größer sein als die zukünftigen Kosten.

Beispiel: Für unser SMS-Versandsystem an Fahrgäste kauften wir zunächst eine externe Lösung. Zwei Jahre lang versendeten wir mehr als 4 Millionen SMS, was uns mehr als 10 NPS-Punkte einbrachte. Als wir es internalisierten, wussten wir genau, was wir tun wollten. Die eigentliche Coding-Arbeit war noch zu erledigen, aber 80 % der Produktmanagement-Arbeit war bereits abgeschlossen, was die Entwicklung schneller und relevanter machte.

Bereuen Sie eine Ihrer Entscheidungen?

Jeremie Lebrun: Es gab Fälle, in denen wir nicht den richtigen Partner gewählt hatten und wechseln mussten. Aber insgesamt sind das normale Anpassungen im Leben eines Engineering-Projekts, und wir hatten das Glück, eine Entscheidung zwischen Make und Buy nicht zu bereuen.

Wie beeinflussen Ihre Build-vs.-Buy-Entscheidungen BlaBlaCars Tech-Kultur und Teamorganisation?

Jeremie Lebrun: Historisch gesehen hat BlaBlaCar eine starke Tech-Kultur: Alles wurde intern entwickelt. Die Einführung von SaaS- und Low-Code-Lösungen erforderte daher echte Bildungsarbeit. Wir mussten die Debatte depolitisieren: Natürlich können unsere Entwickler alles coden, aber ihre Zeit ist wertvoll. Ein Ticketing-Tool zu entwickeln würde keinen Sinn ergeben.

Das beinhaltet auch Change-Management: Ein agiles Squad, das alle zwei Wochen liefert, arbeitet nicht im gleichen Tempo wie ein SaaS-Anbieter, der alle zwei Monate eine neue Version deployt. Wir mussten Arbeitsmethoden harmonisieren, die Kommunikation straffen und Erwartungen angleichen.

Gibt es nicht auch ein Ego-Problem unter Entwicklern zu managen?

Jeremie Lebrun: Ja, wie überall beim Vergleich zweier Ansätze. Aber es gibt Entwicklerprofile, die sich tatsächlich gern zum SaaS-Ökosystem hin orientieren, wie Salesforce. Andere sind es müde, immer die gleichen Dinge zu coden, und finden neuen Schwung in der Administration oder Integration. Das Wichtigste ist, die Frage zu depolitisieren: Ja, unsere Devs können alles, aber manchmal ist es klüger, eine Lösung zu nutzen, die bereits zu 80 % fertig ist.

Welchen Rat würden Sie Startups und Scale-ups geben, die vor diesen Entscheidungen stehen?

Jeremie Lebrun: Bleiben Sie sehr offen und objektiv. Viele Scale-ups wollen alles selbst bauen, lagern aber schnell den "Ops"-Teil aus (CRM, Automatisierung). Wichtig ist, die vollständigen Kosten zu berücksichtigen: Build, Wartung, Organisation, Abhängigkeit. Es gibt keine von Natur aus gute oder schlechte Entscheidung, nur gute oder schlechte Analysen.

Und vor allem: Nehmen Sie die skalierbare oder nicht skalierbare Natur einer Technologie nicht als gegeben an. Bei BlaBlaCar haben wir Millionen von SMS über eine Low-Code-Lösung versendet, erfolgreich. Damit das funktioniert, muss das Projekt von Tech-Teams (Architektur, Testing) getragen werden und nicht nur von Business-Teams. Sonst besteht das Risiko, dass die Lösung nicht skaliert.

Wichtigste Erkenntnisse

• BlaBlaCar entwickelt wesentliche und differenzierende Features intern und nutzt Drittanbieterlösungen für Standardprozesse.
• Die Kostenbewertung umfasst nicht nur Entwicklung oder Lizenzen, sondern auch Wartung und organisatorische Auswirkungen.
• Technische Schulden können ein strategischer Hebel sein, wenn sie mit einem klaren ROI verbunden sind.
• Die Integration von SaaS und Low-Code erfordert echtes Change-Management und Kommunikationsarbeit zwischen Teams.