The most expensive thing a founder can buy is a correctly built wrong thing.
Most of the cost of a piece of software is not set at the keyboard. It is set earlier — in the moment someone decides what to build, for whom, on what timeline, with what constraints, and inside which architecture. By the time the code is being written, the decisions that will determine whether the system is good or bad, cheap or expensive to maintain, two years from now have almost all been made. The developer writing the code is, by then, simply giving those decisions a body.
This is what we mean when we say judgment before code.
It is not a slogan. It is an observation, made repeatedly over engagements where a team was asked to rescue a working system that had been built beautifully against the wrong brief. The code was clean. The engineers were good. The original decision had been slightly wrong, and the system — which had done exactly what it was told to do — had faithfully turned a small early error into a large, expensive problem two years downstream.
The ordinary way to avoid this is to pause, before the first commit, and ask a senior person who has seen this particular shape of mistake before whether the plan on the table is the right plan. Ordinary — and remarkably uncommon. Most founders at the moment of a large architectural decision do not have a senior technical voice in the room other than their own. The decisions that will shape the next three years of the company are made, reasonably and in good faith, by people who have not yet had the privilege of being wrong about them before.
Our own practice, the way we have come to prefer to work, begins before the question what should we build? is answered, and ends before we are asked to be the ones to build it. Sometimes the same studio then builds it, in the Atelier. Sometimes, when the client has an internal team, we hand the decision back with the reasoning written down, and wish them well. In both cases the expensive work — the judgment — has already been done by the time the first file is created.
We are aware that this is an old-fashioned view. It is nevertheless true.
Three habits follow from it, and we will close on them.
First, we write things down. Every meaningful decision — the option chosen, the options declined, the reason for the choice, the conditions under which we would re-open it — is committed to a document the operator can read, keep, and hand to the next senior engineer who joins the team. We are not paid to hold the reasoning in our heads. We are paid to transfer it.
Second, we do not take engagements where we have been told, in effect, not to think. If the scope is build this thing, do not ask why — politely, firmly — we are the wrong studio. Not because we dislike execution, but because a studio whose judgment is not engaged is a studio whose judgment, by definition, is not adding anything. Either the judgment is part of the engagement, or the engagement is already wrong.
Third, we take fewer engagements than we are offered, and charge for them accordingly. Judgment is not separable from attention. A studio working on twenty parallel engagements is not bringing judgment to any of them; it is, at best, bringing pattern-matching. We prefer the smaller number and the deeper room.
None of this is a marketing position. It is the only way we have found to make work we would still be willing to put our name to, three years after it was delivered, in a room full of people who had to live with it.