About

I write software for a living, and I have been doing it long enough to have opinions about it. I live in Montreuil, just outside Paris.

How I got here

Someone gave me an Atari ST when I was seven or eight. I have long forgotten which model. It came with a box of floppy disks and a pile of books, and on one of those disks was GFA Basic, with a manual that was genuinely good.

I had no idea at the time, but that is where the taste for building things started. I put in an absurd number of hours making something work, then breaking it, then making it work again.

There was no internet. One manual was all I had, and I have come to think that was the point. A small amount of information you can actually hold beats the flood we have now, at least when you are trying to learn something properly. Music is the same. Constraints are what make you learn for real.

Then Linux turned up, in the first distributions aimed at the general public. “General public” is generous; you could still lose days to an install. It was a wonderful toy. Networks, compilers, editors, X servers, all of it there to be taken apart.

Some languages I used along the way, roughly in order: GFA Basic, Pascal, Delphi, C, C++, and enough shell scripting to hold the rest together. ASP and PHP once the web arrived, with CGI programs written in C++. JavaScript came with them and never left. Python 2, then Python 3, which became my default and stayed. TypeScript with the front end. Rust lately.

As a young adult, after six or seven years of “junioring” in product companies and very technical web agencies, and a spell as technical lead of a web agency people had heard of, the urge to build extended itself to building companies. I learned how, the hard way. I also learned how not to.

Ideas are worth far less than understanding the problem, executing, and iterating. Accept the mistakes, and iterate quickly. It sounds trivial written down, and yet I have watched founders, some of my own co-founders, and myself, drop everything we knew in favour of blind conviction. Learning to work around your own biases is hard. Nobody said building was easy, but it is far more rewarding than not building.

Before rebuilding what is now my company, I spent three years building startup accelerators backed by a large corporate, and helped close to fifty founding teams move forward, across very different markets, stages and stacks. We used to joke that we were just therapists for founding teams: let them talk, nod, grunt occasionally, slip in a “tell me about your mother”, and they do most of the work themselves. The usual rubber duck technique.

What I do now

I run Makersquad, a software craftsmanship agency founded in 2018. We work as small autonomous squads and take products from idea to market. Most of the work is Python and Django on the backend, React and TypeScript on the front, with Node, containers and Kubernetes underneath. Test-driven development, code review and continuous integration are not optional, they are what keeps software cheap to change.

For the last few years I have also been experimenting heavily with language model agents and APIs, Claude and Claude Code in particular. Our job and our practice are evolving quite fast, brutally, and it has never been more exciting to create products.

What I build

I build a lot of different things, and a good part of it is experiment. Most of it started as something I needed and could not find.

Bonobo, an extract-transform-load framework, came out of my second company: it took new retailer catalogs from days to hours. I no longer maintain it.Whistle, a small event dispatcher for Python with no dependencies, I still do.

HARP came from having to depend on third-party APIs that could not be depended on. I had been working around it case by case, and there was nothing on the market worth adopting, so I stopped patching and built the proxy.

Kongo is what I am building in private at the moment, closed for now. It is a communication system for teams of coding agents, running across different implementers (Claude, opencode) and different isolation layers (Multipass, Docker).

Plan de Scène does two jobs. I use it when I organise music events, and it gives Kongo a real product to build against, at low stakes.

Some of it is open source, some of it is not. Some is production ready, some is a throwaway experiment. I build every day, and these days usually more than one product at a time. Theprojects page lists them, with what each one is for and how finished it is.

Elsewhere

I write Weekly Tech Cocktail, a weekly newsletter of handpicked links about APIs, language models and where software engineering is heading. Everything I publish, here and elsewhere, ends up on thearticles page.

Away from the keyboard

I play music, mostly jazz and afro-cuban, and I tradego stones.

Work with me

If you have a problem worth solving, the contact page has the details.