Software built to outlive its makers

Most software is sold on how it looks in the first demo and paid for over the next five years of maintenance. The gap between those two facts is where enterprise budgets quietly disappear — and where the real engineering decisions live.

Anyone can stand up something that demos well. The question that decides total cost of ownership is whether your team can understand, change, and trust the system a year after the people who built it have moved on. That is a design choice made early — in the architecture, the boundaries, the tests, and the discipline of the people writing it — not a thing you can retrofit later.

This is why we are deliberate, even opinionated, about the foundation. We choose stacks that are proven, long-lived, well-staffed, and boring in the way that regulated, high-stakes software should be. For us that has often meant .NET and React, but the principle travels.

The stack is not a list of skills on a CV. It is a statement about how long we expect the system to live.

• Maintainability over cleverness. The best code is the code your team can change without fear.
• Boundaries that hold. Clear seams between concerns so the system can evolve in parts, not be rewritten whole.
• Security and compliance designed in. Not bolted on after an audit asks for it.
• Tests as the safety rail. The thing that lets the next engineer move fast without breaking what works.
• Ownership, handed over. The end state is a system your team runs, not a dependency on us.

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

— C. A. R. Hoare, Turing Award lecture, 1980

Durable software is mostly a function of who writes it. The common enterprise failure is a strong team in the pitch and a junior team on the keyboard. We do not run that pyramid: the people who scope the work are the people who build it. It is the simplest reason our systems tend to age well — and the hardest thing for a larger firm to copy.

Build it so the next person can change it without fear. Everything else is detail.

— Matthew Rogers, Preux