On Building Systems That Last

Most software fails not because the code is bad, but because the thinking behind it was shallow.

I have seen this pattern across every business I have run. A system gets built to solve an immediate problem. It works. Then the business grows, the context changes, and the system starts to crack - not because it was poorly coded, but because it was never designed to last.

The failure mode is almost always the same: the builder was optimising for now, not for later. They were solving the problem in front of them, not the class of problems that would follow.

What durability actually means

A durable system is not one that never changes. It is one that can absorb change without breaking.

This is a subtle but important distinction. The goal is not rigidity - it is resilience. A system that is so tightly coupled that any modification requires a complete rebuild is not durable. It is fragile, just in a different way.

Durability comes from a few things:

Clear boundaries. When a system knows what it is responsible for and what it is not, changes can be made in one place without cascading failures elsewhere. This is harder than it sounds. Boundaries require discipline, and discipline requires someone who cares enough to enforce them.

Honest data models. The data model is the foundation. If it is wrong, everything built on top of it will eventually need to be rebuilt. Getting the data model right requires thinking carefully about what the business actually does - not what it does today, but what it will need to do as it grows.

Minimal surface area. Every interface is a contract. Every contract is a liability. The fewer interfaces a system has, the fewer places it can break. This is not an argument for monoliths - it is an argument for thinking carefully about what actually needs to be exposed.

The operator's perspective

As someone who runs businesses, I think about systems differently than a pure engineer might. I am not just thinking about whether the system works. I am thinking about whether I can trust it at 2am when something goes wrong. Whether a new hire can understand it without six months of context. Whether it will still be serving us in three years.

These are operational questions, not technical ones. But they have technical answers.

The most durable systems I have built or worked with share a common quality: they were designed by people who understood the business deeply, not just the technology. They were built with an awareness of how the business would grow, what would change, and what would stay the same.

A practical test

When I am evaluating a system - whether I am building it or inheriting it - I ask a simple question: if the person who built this left tomorrow, how long would it take someone else to understand it well enough to change it safely?

If the answer is months, the system is fragile. If the answer is days, it might be durable.

This is not a perfect test. But it forces you to think about the system from the outside - which is usually where the problems are.

Building systems that last is not glamorous work. It requires restraint, patience, and a willingness to invest in foundations that will never be visible. But it is the work that compounds. And compounding is the only strategy that matters over time.