III. Shift Left
The cheapest bug is the one you kill before you write it.
There's a well-worn truth in software: the later you catch a problem, the more it costs. A mistake caught while thinking is free. The same mistake caught in code review costs an hour. In QA, a day. In production, it can cost weeks and a customer's trust.
"Shift left" means dragging the moment of discovery as early as possible, to the left of the timeline, before the expensive part starts.
It's the same core principle as our quality pace-maker, aimed upstream: deeply specify and test your feature before you implement it, and again before you ship it.
Understand before you change
On our incremental-improvements work, nobody starts by typing. Before touching a line, you make sure you genuinely understand how the feature works today, why it works that way, and what exactly you're going to change.
That's real, non-code work: reading, tracing, asking. And it's not optional. The biggest, ugliest bugs almost always come from someone changing a system they didn't fully understand. Skipping this step doesn't save time. It just moves the cost downstream and multiplies it.
(It also doesn't have to be a rigid phase. The understanding keeps evolving as an open conversation during development, but it leads.)
A hierarchy of failures
Shifting left isn't only about meetings and specs. It lives in the code itself. Every failure lands somewhere on a ladder, and your job is to push it as far up as you can:
- A compile-time error. The best kind. The type system catches it before the code ever runs, on your machine, in seconds. Free.
- A failing unit test. Caught in development and CI, close to the cause, with a fast feedback loop.
- A failing integration test. Still caught before production, just later and slower to pin down.
- A loud crash in production. Not great, but at least the system tells you immediately and unambiguously that something is wrong.
- A silent error in production. The nightmare. Wrong data, wrong money, wrong documents, and nobody knows until a customer does. This is the galaxy-sized bug waiting to happen.
Two forces are at work. Catch failures as early as possible (rung 1 beats rung 4), and when one does slip through, make it as loud as possible (rung 4 beats rung 5). A program that crashes cleanly is safer than one that quietly lies.
This is why we lean so hard on the type system and on clean error handling: every design choice that turns a rung-5 failure into a rung-1 failure is shift-left in its purest form. Make the compiler do the worrying.
For projects: warm up before you run
Bigger projects get a deliberate warmup before any code is written, ideally capped at about a week:
- A kick-off meeting hands the project from Product to Tech, so the scope is genuinely shared and understood, not assumed.
- A scope presentation closes the warmup: the tech team presents how it's going to build the thing. It's backed by a written document, reviewed in advance, that covers development, testing, release, and monitoring. The grey areas have to be cleared up before this meeting, not discovered during the build.
The point isn't ceremony. The point is that the most catastrophic misunderstandings are cheap to fix in a meeting and ruinous to fix in production. So we pay the cost early, on purpose.
Why we work this way
Shifting left feels slower. You're "not coding." Someone always notices.
But it's a trade we make with open eyes: a little less raw speed at the start, in exchange for a massive drop in post-release support, the kind of support that, ungoverned, quietly eats a whole team alive. Front-loading the thinking is how we keep the back end of the process calm.
Think slow so you can ship fast.
If you like to think before you type, you'll fit right in. We're hiring in Paris. See our open positions.