Building your own tools

Our site uses no Google Analytics, no WordPress, no Mailchimp. The visit counter, the article editor you're reading this in, the sign-up form: we wrote them ourselves. Not out of stubborn-craftsman principle, but as a deliberate choice.

For a small studio, the obvious move is supposed to be the opposite: don't reinvent anything, plug in a service, pay the subscription, move on. But a SaaS's sticker price is never its real cost. Once you add up the lock-in, the data you hand over, the features you put up with, and the time spent holding it all together, building the small pieces that matter yourself often comes out cheaper - and simply leaves us freer.

What a subscription really costs

The monthly fee is the visible part. The rest you pay another way.

You hand over your data, and sometimes your visitors' too: that's the model behind most free analytics tools. You inherit a product designed for the largest possible audience, and so bloated with features you don't need and that get in the way of the ones you do use. You tie yourself to a vendor that changes its prices, its terms, or disappears - and holds the key to the exit. And every service adds its own integration layer to maintain.

That cost shows up on no invoice. You discover it later.

What we build, and why

We don't build everything. We build the pieces that are at once small, central, and that renting would mean paying too much for - in money or in compromise.

Take our audience measurement: no cookies, no third-party scripts, a fingerprint hashed with a salt that changes every day. No free service would have let us respect our visitors that much, because their model, precisely, is the data. A few hundred lines later, we count our visits without tracking anyone.

Same logic for the multilingual article editor this text runs through, or for the sign-up form: simple, specific needs a generic product would have covered badly for more money.

What we don't build

The other half of the calculation matters just as much. We don't rewrite the language, the framework, the database, the server. Those foundations are enormous, battle-tested, maintained by thousands of people: redoing them would be absurd.

So the rule isn't to build everything. It's: borrow the foundations, own what's ours. Build what's small and sets us apart; reuse what's large and common to everyone.

Owning what you run

There's a benefit people always underestimate: when you've written something, you understand it. When it breaks, you know where to look. When a need changes, you adapt it the same day, instead of waiting for a vendor to put it on its roadmap someday.

A homegrown tool, modest but ours, often beats a powerful but rented one: it does exactly what we need, no more, no less, and it won't leave us overnight.

The honest part

Building has a cost too, and pretending otherwise would be dishonest. Code written is code to maintain. Badly chosen, the homemade becomes its own debt.

That's why we only build when the piece is small, stable, and too central to hand off to a third party. Otherwise, we buy without a second thought.

Keeping control

Building your own tools isn't an eccentricity. It's a way of keeping a hand on what matters: not handing a third party control of our work, nor the data of those who trust us. The rest, we gladly borrow.