Jeremie Lebrun lleva seis años en BlaBlaCar, tras una década dedicada a la consultoría. Hoy, como Head of Engineering de Corporate Services, lidera un equipo de 35 personas responsable de todas las herramientas internas de la empresa: ordenadores portátiles, redes, herramientas de RRHH, finanzas, CRM, automatización y aplicaciones relacionadas con la actividad de autobús. En resumen, todo lo que no está directamente orientado a los usuarios finales pero permite a los 800 empleados, repartidos por seis países, trabajar de forma eficiente.

¿Qué criterios técnicos y de negocio guían sus decisiones entre desarrollar una solución internamente o usar una herramienta de terceros?

Jeremie Lebrun: Probablemente no somos muy originales: por un lado, los desarrolladores son un recurso escaso. Por otro, hay soluciones en el mercado diseñadas por personas más maduras que nosotros en muchos ámbitos, que ya han pensado mucho en ellas.

Nuestro principio es sencillo: todo lo que es diferenciador respecto a la competencia y nos ayuda a avanzar en nuestra visión de producto, lo desarrollamos internamente. Por el contrario, todo lo que no es diferenciador, buscamos una solución "lista para usar". Por ejemplo, no tiene ningún sentido para nosotros desarrollar software de finanzas y contabilidad. En cambio, para nuestros algoritmos de moderación de intercambios entre usuarios de carpooling, somos los únicos con la experiencia y el contexto de negocio: eso permanece en desarrollo interno.

Pero entre los dos existe una zona gris. Las decisiones se toman entonces con criterios de mantenibilidad, cobertura de mercado, coste e impacto organizativo.

Un ejemplo: para el servicio BlaBlaCar Bus, tuvimos que establecer un sistema de comunicación con los pasajeros en caso de retrasos. Inicialmente compramos una solución existente porque no teníamos el equipo disponible y aún no sabíamos exactamente qué queríamos. Dos años después, cuando los requisitos se volvieron más específicos, internalizamos el desarrollo.

¿Cómo evalúa el coste real del "build" frente al coste del "buy"?

Jeremie Lebrun: En el lado del build, hay que calcular: qué equipo está involucrado, durante cuánto tiempo, con qué complejidad de infraestructura y producto. Nuestra experiencia nos permite estimar el tamaño del equipo necesario y el plazo de entrega. Siempre intentamos ceñirnos a tecnologías que ya dominamos, para evitar añadir deuda técnica innecesaria.

En el lado del buy, no se trata solo de licencias. Siempre hay un coste de configuración, conexión a los sistemas internos, administración, seguridad y producto. Después hay que tener en cuenta el mantenimiento a lo largo del tiempo. Un SaaS no elimina los problemas: también trae su parte de evoluciones y restricciones.

La dependencia del proveedor forma parte de la elección inicial. No se puede pretender tenerlo todo: cuando se elige una solución SaaS, hay que aceptar cierta dependencia, asumirla y gestionarla en consecuencia.

En un contexto como el de BlaBlaCar, donde la plataforma debe gestionar un fuerte crecimiento y picos de tráfico, ¿qué decisiones de build vs buy resultan más estructurantes?

Jeremie Lebrun: Tenemos un enfoque pragmático: la deuda técnica no es una mala palabra. Puede tener valor si permite acelerar el time-to-market. Lo importante es aceptarla colectivamente desde el principio, como la deuda financiera: sabemos que tendremos que pagarla más tarde, pero el beneficio inmediato puede ser mayor que el coste futuro.

Ejemplo: para nuestro sistema de envío de SMS a los pasajeros, primero compramos una solución externa. Durante dos años, enviamos más de 4 millones de SMS, lo que nos permitió ganar más de 10 puntos de NPS. Cuando internalizamos, sabíamos exactamente qué queríamos hacer. El trabajo de codificación puro quedaba por hacer, pero el 80 % del trabajo de gestión de producto ya estaba completado, lo que hizo el desarrollo más rápido y relevante.

¿Lamenta alguna de sus decisiones?

Jeremie Lebrun: Hubo casos en los que no habíamos elegido al socio correcto y tuvimos que cambiar. Pero en general, son ajustes normales en la vida de un proyecto de ingeniería, y hemos tenido la suerte de no lamentar ninguna decisión entre make y buy.

¿Cómo influyen sus decisiones de build vs buy en la cultura tecnológica y la organización del equipo de BlaBlaCar?

Jeremie Lebrun: Históricamente, BlaBlaCar tiene una fuerte cultura tecnológica: todo se desarrollaba internamente. La introducción de soluciones SaaS y low-code requirió, por tanto, un trabajo educativo real. Tuvimos que despolitizar el debate: por supuesto, nuestros desarrolladores pueden codificar cualquier cosa, pero su tiempo es valioso. Desarrollar una herramienta de ticketing no tendría ningún sentido.

Esto también implica gestión del cambio: un equipo ágil que entrega cada dos semanas no trabaja al mismo ritmo que un proveedor de SaaS que despliega una nueva versión cada dos meses. Tuvimos que armonizar métodos de trabajo, agilizar la comunicación y alinear expectativas.

¿No hay también una cuestión de ego que gestionar entre los desarrolladores?

Jeremie Lebrun: Sí, como en todas partes cuando se comparan dos enfoques. Pero hay perfiles de desarrolladores que realmente disfrutan orientándose hacia el ecosistema SaaS, como Salesforce. Otros están cansados de codificar siempre las mismas cosas y encuentran un nuevo aliento en la administración o la integración. Lo principal es despolitizar la cuestión: sí, nuestros desarrolladores pueden hacer cualquier cosa, pero a veces es más inteligente usar una solución que ya está un 80 % lista.

¿Qué consejo daría a las startups y scale-ups que se enfrentan a estas decisiones?

Jeremie Lebrun: Manténgase muy abierto y objetivo. Muchas scale-ups quieren construir todo por sí mismas, pero rápidamente externalizan la parte "ops" (CRM, automatización). Lo importante es tener en cuenta el coste completo: build, mantenimiento, organización, dependencia. No hay ninguna elección inherentemente buena o mala, solo buenos o malos análisis.

Y sobre todo: no dé por sentada la naturaleza escalable o no escalable de ninguna tecnología. En BlaBlaCar, hemos enviado millones de SMS a través de una solución low-code, con éxito. Pero para que esto funcione, el proyecto debe estar respaldado por equipos tecnológicos (arquitectura, pruebas) y no solo por equipos de negocio. De lo contrario, el riesgo es que la solución no escale.

Conclusiones clave

• BlaBlaCar desarrolla internamente las funcionalidades esenciales y diferenciadores, y usa soluciones de terceros para los procesos estándar.
• La evaluación del coste incluye no solo el desarrollo o las licencias, sino también el mantenimiento y el impacto organizativo.
• La deuda técnica puede ser un palanca estratégica si va acompañada de un ROI claro.
• La integración de SaaS y low-code requiere un trabajo real de gestión del cambio y comunicación entre equipos.