Alban Dericbourg, freelance senior software engineer

I have spent fifteen years designing and hardening back-end services, notably in three French unicorns: Criteo, BlaBlaCar and Mirakl.

I can reinforce an existing team or take a scoped piece of work end to end. In both cases, I start from the problem to solve and what it brings to users, and I make the technical choices accordingly. I have worked on large existing codebases, which I explored and modernized, as well as on new services deployed in high-traffic distributed systems. Reliability is the area that interests me most: I was among the first to set up SLOs and an SRE approach in several teams. I am still interested in more generalist back-end work.

I have worked fully remote since 2019, first at BlaBlaCar and then at Mirakl. Over these seven years, I led multi-team projects remotely and helped colleagues grow their skills. I rely a lot on spoken communication (over video calls) to build and maintain relationships with each person. After discussions that lead to a decision, I make sure the decision is written down so that it doesn’t get lost. Although I favor remote work, I think it is important to come on-site regularly.

Beyond the code, I like helping a team move forward: clarifying decisions, facilitating discussions, easing tensions. You can read testimonials from people I have worked with on a dedicated page.

Looking for a software engineer? I’d be glad to talk. If not, maybe you could point me to two people worth reaching out to. :)

Frequently asked questions

What kind of work do I take on?

Back-end development in high-traffic distributed systems: building new services, modernizing existing code, observability and reliability. I also drive cross-team projects.

What do I mean by product-minded?

Before asking myself how to do something, I try to understand who it is for and why. In practice, I start from the problem and the users, I take part in scoping rather than waiting for a finished specification, and I don’t hesitate to say when a simpler solution is enough, or when the request won’t solve the problem at hand.

At BlaBlaCar, I led product projects from discovery through to rollout. I also set up Feature SLOs there: reliability indicators that measure what the passenger actually experiences rather than server health alone. It is a point my former colleagues mention, on the product side as well as the technical one.

Time and materials, or fixed price?

I work both ways, depending on your need.

On a time-and-materials basis, I join your team and work on your priorities. This fits when the need is ongoing, when the scope changes from week to week, or when strengthening the team matters as much as delivering.

On a fixed-price basis, I take on a scoped piece of work and commit to the result, with a written scope, a firm price and a delivery date. This fits when you can describe what you want to obtain: a connector to put in production, an SLO practice to roll out, tooling to set up, part of an existing codebase to modernize. I have already delivered this kind of work, and my CV gives the details.

In both cases, I work the same way, with a written progress update every week and documented design decisions.

If you are unsure, describe the result you expect. That is usually what helps choose between the two.

How does a fixed-price engagement work?

It starts with a short scoping phase, before any commitment on price. This phase produces a document stating what will be delivered, the criteria that will tell us it is done, what is not included, and the intermediate milestones. The firm price covers that scope.

The rest works as it does on time and materials: a written update every week (what was delivered, next steps, blockers, decisions to make) and regular deliveries rather than a single hand-off at the end.

If the scope changes along the way, I tell you as soon as I notice, I estimate the difference, and we decide together whether to adjust the scope or amend the contract. The goal is that nobody discovers the gap at the end of the engagement.

Which technologies?

Mainly Java and Spring Boot, with MariaDB, PostgreSQL, Kafka, Docker and Kubernetes. For observability: Datadog, Prometheus and Grafana. I also use AI-assisted development tools daily, Claude Code in particular. My detailed CV gives the context of each mission.

Remote or on-site?

I have worked fully remote since 2019, from the countryside between Poitiers and Angoulême. I usually come on-site about 2 to 4 days a month depending on your needs, always for project kickoffs, and gladly for important moments in the team’s life.

How can you follow progress remotely?

By default, I send you a written update every week covering what was delivered, next steps, blockers and decisions to make. That is what I have practiced so far. If your team already has its own rituals, I am happy to adapt to them. We can agree on this at the start of the engagement.

How do decisions get made remotely?

Often by talking, over video, because it is the quickest way to understand each other and decide. I then make sure the decision is written down. For a design decision, I usually write a design doc, first reviewed asynchronously, then discussed in a small group with one representative per team, and finally presented at a kickoff to all the teams involved. The decision then remains available to people who weren’t there or who join the team later. I make sure the reasons behind the decision are recorded, so that its relevance can always be reassessed.

Does remote work suit cross-team projects?

At BlaBlaCar, I remotely led a nine-month program involving four teams. My former colleagues, with whom I worked remotely for one to three years, can attest to it.

Which languages?

French and English, written and spoken.

How to get in touch?

By email, LinkedIn or Malt. If your need doesn’t match my profile, an introduction is always welcome.