Alban Dericbourg, freelance senior software engineer

Fifteen years designing and hardening back-end services, notably in three French unicorns: Criteo, BlaBlaCar and Mirakl.

I reinforce your teams, or take a scoped piece of work end to end, while keeping the problem I’m trying to solve and the value for users front and center: that’s what drives the technical choices, not the other way around. I’m as comfortable with legacy code as with a greenfield project: exploring and modernizing large existing codebases as much as shipping new services into high-traffic distributed systems, and making the whole thing reliable and observable. Reliability is my home turf: I was among the first to roll out SLOs and an SRE approach in several teams, while still drawn to more generalist back-end work.

I have worked fully remote since 2019, at BlaBlaCar then Mirakl. Seven years during which I led multi-team projects remotely and supported engineers as they grew. My default way of working: plenty of video calls, because that is where the connection with people gets built — and always something written afterwards, so ideas and decisions don’t get lost. A progress update arrives every week without you having to ask for it, at whatever rhythm and in whatever format suits you. I come on-site regularly, typically 2 to 4 days a month, always for project kickoffs, and gladly for a team’s key moments.

Beyond the code, I enjoy moving a group forward: clarifying decisions, facilitating discussions and defusing tension. My former teammates put it better than I can: their words are here.

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: new services, modernizing legacy code, setting up observability, reliability. I also drive cross-team projects.

Time and materials, or fixed price?

Both, depending on the shape of your need.

On a time-and-materials basis, I join your team and follow your priorities. The right choice when the need is ongoing, when the scope shifts from week to week, or when strengthening the team matters as much as shipping.

On a fixed-price basis, I take a bounded piece of work and commit to the outcome: a written scope, a firm price, a date. The right choice when you can name what you want to end up with — a connector to put in production, an SLO practice to roll out, tooling to put in place, a slice of legacy code to modernize. That is the shape of what I have delivered so far; the CV has the detail.

Either way, the way of working doesn’t change: the same written progress update every week, the same design decisions written down.

If you’re unsure, tell me what you’re trying to end up with: describing the expected outcome usually points to one or the other.

How does a fixed-price engagement work?

It starts with a short scoping phase, before any price is committed. It produces a document stating what will be delivered, the criteria by which we will know it is done, what is out of scope, and the intermediate milestones. The firm price covers that scope.

After that, from your side, nothing differs from a time-and-materials engagement: the same written update every week — what shipped, what’s next, what’s blocking, decisions to be made — and regular deliveries rather than a single hand-off at the end.

If the scope moves — it happens, and it is often good news — I say so straight away, I price the difference, and we decide together: adjust the scope, or amend the contract. What doesn’t happen is discovering it at the end.

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. The detailed CV gives the context of each mission.

Remote or on-site?

Fully remote since 2019, from the countryside between Poitiers and Angoulême. I come on-site regularly, typically 2 to 4 days a month, adjusted to your needs, always for project kickoffs, and gladly for a team’s key moments.

How do I know what you’re doing, remotely?

You won’t have to ask. What I offer by default: a written update every week — what shipped, what’s next, what’s blocking, and decisions to be made. That’s what I’ve practiced so far. If your team already has its own rituals and format, I’m happy to fit into them: what matters is that nobody has to wonder where things stand. That’s typically the kind of thing we can agree on at the start of a mission.

How do decisions get made remotely?

By talking, often: video calls remain the best way to understand each other and decide quickly. But they shouldn’t stay purely spoken: I believe a written record is necessary. My habit for a design decision is to go through a written design doc, reviewed asynchronously, then in a small group with one representative per team, and finally presented at a kickoff with all involved teams. The point isn’t the document itself so much as what it leaves behind: a decision anyone can consult at any time, whether they weren’t in the room or joined the team later.

Does remote work hold up on cross-team projects?

At BlaBlaCar, I remotely led a nine-month program spanning four teams, and supported engineers as they grew. My former teammates, with whom I worked remotely for one to three years, put it better than I can.

Which languages?

French and English, written and spoken.

How to get in touch?

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