There are only four sensible ways to build a website

There are only four sensible ways to build a website

Your choice of CMS is not a tooling decision. It is a constraint system. It decides what kinds of problems you can solve, which ones you will struggle with, and which ones you will never even see coming. It shapes how content is created, how it flows, who can touch it, how it evolves, and what breaks when the organisation changes. It quietly defines the ceiling of your ambition and the floor of your operational risk.

And yet, teams keep choosing stacks as expressions of identity.

Engineering-led organisations reach for React and headless architectures because that feels like control, modernity, and technical seriousness. Design-led teams gravitate towards visual builders and canvas tools, where they can move quickly and shape the interface directly. Editorial teams default to WordPress and its cousins, because that’s where publishing lives, and where content feels tangible. These aren’t irrational choices, but they are rarely grounded in a clear understanding of what the organisation actually needs to operate over time.

Because most websites are not artefacts. They are systems. They accrete complexity. More stakeholders, more content types, more integrations, more expectations, more edge cases. The thing you launch is not the thing you end up running. And the stack you choose at the beginning determines whether that growth feels like compounding capability or slow, grinding failure.

If you strip away the branding, the demos, and the sales narratives, most of those choices collapse into a small number of patterns. Not dozens. Not even ten. Four.

Once you stop designing the interface and start mapping the work, the answer tends to reveal itself quickly. Not as a list of features, but as a pattern of behaviour. How the site is built, how it changes, and who is responsible for keeping it alive.

There are sites which are really applications. Stateful, interactive, deeply integrated into products and user journeys. These demand bespoke engineering, and reward teams who can design and maintain systems, not just pages.

There are sites which exist to sell. Where the hard problems are payments, inventory, fulfilment, and trust. Here, the stack should get out of the way and handle the machinery, not invite you to rebuild it.

There are sites which mostly sit still. Small, simple, rarely updated, with limited moving parts. They benefit from being fast, robust, and almost boring in their simplicity.

... continue reading