Jeremie Lebrun has been at BlaBlaCar for six years, after a decade spent in consulting. Today, as Head of Engineering – Corporate Services, he leads a team of 35 people responsible for all internal company tools: laptops, networks, HR tools, finance, CRM, automation, and applications related to the bus activity. In short, everything that isn't directly aimed at end users but allows the 800 employees, spread across six countries, to work efficiently.

What technical and business criteria guide your choices between developing a solution internally or using a third-party tool?

Jeremie Lebrun: We're probably not very original: on one hand, developers are a rare resource. On the other hand, there are solutions on the market designed by people more mature than us on many subjects, who have already thought a lot about them.

Our principle is simple: everything that's differentiating compared to the competition and helps us advance our product vision, we develop internally. Conversely, everything that's not differentiating, we look for "off the shelf." For example, there's no interest for us in developing finance and accounting software. On the other hand, for our algorithms moderating exchanges between carpoolers, we're the only ones with the experience and business context: that remains in-house development.

But between the two, there's a gray area. Arbitrations are then made on criteria of maintainability, market coverage, cost, and organizational impact.

An example: for the BlaBlaCar Bus service, we had to set up a communication system with passengers in case of delays. Initially, we bought an existing solution because we didn't have the team available and didn't know exactly what we wanted yet. Two years later, as the stakes became more specific, we internalized the development.

How do you evaluate the real cost of "build" versus the cost of "buy"?

Jeremie Lebrun: On the build side, you need to calculate: which team is involved, for how long, with what infrastructure and product complexity. Our experience allows us to estimate the necessary team size and delivery timeline. We always try to stick to technologies we already master, to avoid adding unnecessary technical debt.

On the buy side, it's not just about licenses. There's always a cost of configuration, connection to internal systems, administration, security, and product. Then you have to account for maintenance over time. A SaaS doesn't eliminate problems: it also brings its share of evolutions and constraints.

Vendor dependency is part of the initial choice. You can't expect to have your cake and eat it too: when you choose a SaaS solution, you have to accept some dependency, assume it, and manage it accordingly.

In a context like BlaBlaCar's, where the platform must handle strong growth and traffic peaks, which build vs buy decisions prove most structuring?

Jeremie Lebrun: We have a pragmatic approach: technical debt isn't a dirty word. It can have value if it allows accelerating time-to-market. The important thing is to accept it collectively from the start, like financial debt: we know we'll have to pay it back later, but the immediate benefit may be greater than the future cost.

Example: for our SMS sending system to passengers, we first bought an external solution. For two years, we sent more than 4 million SMS, which allowed us to gain more than 10 NPS points. When we internalized, we knew exactly what we wanted to do. The pure coding work remained to be done, but 80% of the product management work had already been completed, which made development faster and more relevant.

Do you regret any of your choices?

Jeremie Lebrun: There were cases where we hadn't chosen the right partner and had to change. But overall, these are normal adjustments in the life of an engineering project, and we've been fortunate not to regret a choice between make and buy.

How do your build vs buy choices influence BlaBlaCar's tech culture and team organization?

Jeremie Lebrun: Historically, BlaBlaCar has a strong tech culture: everything was developed internally. The introduction of SaaS and low-code solutions therefore required real educational work. We had to depoliticize the debate: of course, our developers can code everything, but their time is precious. Developing a ticketing tool would make no sense.

This also involves change management: an agile squad that delivers every two weeks doesn't work at the same pace as a SaaS vendor that deploys a new version every two months. We had to harmonize working methods, streamline communication, and align expectations.

Isn't there also an ego issue to manage among developers?

Jeremie Lebrun: Yes, like everywhere when comparing two approaches. But there are developer profiles who actually like to orient themselves toward the SaaS ecosystem, like Salesforce. Others are tired of always coding the same things and find new breath in administration or integration. The main thing is to depoliticize the question: yes, our devs can do everything, but sometimes it's smarter to use a solution that's already 80% ready.

What advice would you give to startups and scale-ups facing these choices?

Jeremie Lebrun: Stay very open and objective. Many scale-ups want to build everything themselves, but quickly outsource the "ops" part (CRM, automation). What matters is taking into account the complete cost: build, maintenance, organization, dependency. There's no inherently good or bad choice, only good or bad analyses.

And above all: don't take for granted the scalable or non-scalable nature of any given technology. At BlaBlaCar, we've sent millions of SMS via a low-code solution, successfully. But for this to work, the project must be supported by tech teams (architecture, testing) and not just by business teams. Otherwise, the risk is that the solution won't scale.

Key Takeaways

• BlaBlaCar develops essential and differentiating features internally, and uses third-party solutions for standard processes.
• Cost evaluation includes not only development or licensing, but also maintenance and organizational impact.
• Technical debt can be a strategic lever if accompanied by clear ROI.
• Integration of SaaS and low-code requires real change management and communication work between teams