There is a kind of engineer who treats shipping as the goal and correctness as a subsequent negotiation. I have worked with them. I have, at times in my career, been one of them. I am no longer, and the reason is simple: the negotiation is always expensive, and it is always paid by someone who did not get to sit at the table.
At Semperr the standard is different. The floor is correctness. Software that misreports a figure, a date, or a fact is not a product — it is a liability we have quietly handed our clients. We do not hand our clients liabilities. That is the whole argument.
Boring technology, by default
We prefer small, well-understood tools to large, impressive ones. When we reach for Postgres over something more exciting, it is because Postgres has already survived the kind of production incidents that take newer systems several years to accumulate. When we reach for a well-worn pattern over a clever one, it is because the pattern can be explained, in a meeting, to a new engineer in ten minutes.
This is not conservatism. It is a bet about where the risk actually lives. The risk rarely lives in the core language or the core database. It lives in the seams — the edge cases, the retries, the time-zone conversions, the daylight-saving hour that happens twice a year. Boring tools give us more hours to spend on those seams. They are where the work is.
The extra afternoon
We have a rule, informally: if a thing is nearly right, it is not yet right. Nearly right means the engineer and the reviewer agree on the shape of the solution but have not yet stress-tested the corners. The reviewer goes home. The engineer stays another afternoon. The next morning, the thing is right, and nobody has to revisit it for six months.
The extra afternoon is the single highest-return investment we make. It costs a few hours once. It saves days of client-facing incidents, rework, and trust rebuilding, and it saves the engineer the considerable unpleasantness of having been wrong in public.
What we will not do
We will not use a pattern we cannot defend in a room with the people it affects. We will not reach for a dependency we have not read. We will not ship something we would not cheerfully sign. And we will not celebrate the engineer who ships at midnight — we will, politely, take them out to dinner and ask what the rush was.
The first time
"Works the first time" is a phrase that gets rolled out at product reviews and then forgotten by the end of the sprint. We take it literally. A report run for the first time on a new client's data should render without manual intervention, produce correct figures, and survive the routine edge cases. If it does not, the report is not done, regardless of what the calendar says.
This is the easiest standard to state and the hardest to keep. It is also the entire argument for the firm. The clients who stay with us have stayed because, for five years now, the thing has worked the first time. We do not intend to change that in the sixth.
— Marco