The architecture decisions that don’t need to be made twice

Most technology decisions are reversible. Pick the wrong tool, change it. Choose the wrong supplier, switch. But a handful of decisions are different: they sit at the foundation, everything is built on them, and undoing them later means rebuilding much of what came after. These are the architecture decisions that do not need to be made twice — getting them right once protects you from expensive rebuilds for years. Knowing which decisions these are tells you where to spend your judgment.

Why some decisions compound and others don’t

The difference is dependency. A decision is cheap to reverse when little depends on it. It becomes expensive to reverse when everything else is built on top of it, because changing it means changing all of that too. Foundational architecture decisions are the ones the rest of the system assumes — so by the time you discover one was wrong, undoing it is no longer a single change but a cascade. That is why these decisions deserve disproportionate care up front: the cost of getting them right is the same whenever you make them, but the cost of getting them wrong grows every day the system is built on the mistake.

The data model

The most consequential is how your data is structured. It defines what the business can represent, report, integrate and prove, and every application sits on top of it. A poor data model is the single most expensive thing to change later, because the data is real, in use, and everything depends on it — the point made in full in the database decision that comes back to haunt every growing business. Get this one right, deliberately, with the future in view, and almost everything else becomes easier.

How systems are coupled

The second is how tightly your systems are wired together. Loosely coupled systems can be changed and replaced independently; tightly coupled ones cannot, because changing one breaks the others. The integration choices that determine this are made one at a time, often without anyone seeing the cumulative effect, the subject of the API decision your business is making without realising it. Decide coupling deliberately and you keep the freedom to change parts later; let it happen by accident and you build a system that resists every future change.

Where the truth lives, and how it scales

Two more belong on the list. Deciding where each important fact authoritatively lives — the single source of truth — because retrofitting that across a sprawl of systems is painful and is the root of so many data conflicts. And the scaling assumptions baked into the architecture: not building for imaginary scale, but making sure the foundation can be extended to carry realistic growth without a rebuild. Get this wrong and the business faces the worst version of re-platforming, exactly when growth is highest — the trap behind leaving your next platform for the same reasons you left the last one.

How to make them once

The common thread is that these decisions are made early, often by whoever is closest to the work, under pressure to ship — and are extremely expensive to revisit. The way to make them once is to recognise them as the foundational decisions they are and give them senior judgment before they set, rather than discovering their weight years later. They are not where to move fast and break things; they are where a little deliberate thought saves a great deal of expensive rework.

Getting these right once protects you from expensive rebuilds. We will make sure your foundational decisions are made deliberately, for where you are going.

Start a Conversation