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.

There are sites which publish. Not just pages, but structured content, relationships, workflows, and systems of reuse. These are operational beasts, even when they look like marketing.

Each of these shapes has an obvious technical answer. Not a perfect one, but one which aligns with how the organisation behaves, and how the system will grow. The mistake is trying to force one shape into another, usually because the tooling feels more appealing than the reality it needs to support.

It’s worth starting here, because this is the option teams reach for most often, and the one they get wrong most frequently.

Give a group of engineers a blank canvas, and they will tend towards React, headless CMSs, and composable architectures. It feels like the right kind of decision. Modern, flexible, unopinionated. There is an entire ecosystem reinforcing that instinct, from tooling vendors to hiring markets to conference talks. Build it yourself, stitch it together, own the stack.

And it doesn’t take much to justify it. A login. Some personalisation. A few dynamic components. Suddenly, the site is being described as an “application”, and the decision feels inevitable. Most of the time, it isn’t. The cost of that mistake — and it is a common one — is worth understanding in full.

Some websites are applications which happen to run in a browser. They carry meaningful state. They orchestrate complex interactions. They are deeply embedded in products, workflows, and user journeys. The interface is just one surface of a larger system.

That is where React and headless approaches earn their keep. Not because they are fashionable, but because they give you the raw materials to design and operate software at that level of complexity.

In practice, that rarely means “just React”. Most teams are working in meta-frameworks like Next, Remix, or similar, which add routing, rendering strategies, and deployment conventions on top. That doesn’t change the core trade-off. You’re still building and operating a system, just with a bit more scaffolding.

)But a bit of interactivity does not make a website an application. A login does not require a bespoke architecture. Personalisation, in most cases, is shallow and can be handled without turning the entire system inside out. These are details, not defining characteristics, and in many cases, modern CSS and browser capabilities make large parts of the SPA model unnecessary (see why it’s time for modern CSS to kill the SPA).

The cost of getting this wrong is rarely obvious at the start. You take on responsibility for everything. Content modelling, editorial interfaces, preview environments, caching strategies, deployment pipelines, performance, accessibility, governance. None of this is solved for you. It is all yours to design, maintain, and evolve.

For teams with strong engineering leadership, that trade-off can be entirely rational. You get precision. You get control. You can shape the system around your product, rather than bending your product around the constraints of a platform.

But most organisations are not operating at that level. They adopt a headless approach because it signals modernity, or because it promises flexibility, and end up rebuilding a CMS from scratch, badly. Editorial workflows become awkward. Simple changes require developers. Content becomes harder to reason about, not easier.

Used poorly, it produces expensive, brittle ecosystems where everything is possible and nothing is easy, often reintroducing complexity the platform solved years ago (see how JavaScript broke the web and called it progress).

This is not the default. It is the right answer when the website genuinely behaves like a product, and when the organisation is equipped to treat it as one.

Some websites exist for one primary reason. To sell things, reliably, repeatedly, and at scale.

That sounds obvious, but it changes everything. The hard problems are no longer how to structure content or how to compose interfaces. They are payments, inventory, fulfilment, tax, fraud, compliance, refunds, shipping, and trust. The mechanics of commerce are messy, regulated, and full of edge cases. Getting them wrong is expensive.

This is where Shopify makes sense. Not because it is flexible, but because it isn’t. It comes with strong opinions about how commerce should work, and it takes responsibility for a large chunk of the machinery. Checkout flows, payment processing, security, platform stability, a vast ecosystem of integrations. You are buying a system which has already solved the problems you are about to encounter.

That constraint is the value. It narrows the surface area of what you need to think about, and lets teams focus on merchandising, pricing, positioning, and operations rather than infrastructure.

Where teams get into trouble is when they start fighting those constraints.

They want deeper editorial control, richer content modelling, unusual product structures, bespoke experiences which cut across the grain of the platform. At that point, the logic often drifts towards workarounds, heavy customisation, or stitching in additional systems to compensate. The simplicity which made the platform attractive begins to erode.

There is a familiar pattern here. Organisations outgrow the edges of the platform, but instead of recognising that shift, they try to bend the platform into something it was never designed to be.

That does not mean Shopify is only for small businesses. It is used successfully at enormous scale. But those successes tend to come from teams who understand the trade-off they are making. They are choosing to optimise for operational reliability and speed, and are willing to shape their experience around that.

If selling is the core of the system, then handing off the heavy lifting is often the smartest move available. If selling is only part of the story, then you need to be clear about whether Shopify is the foundation or just one component in a larger system.

Used well, it gets out of your way. Used poorly, it becomes something you are constantly working around.

A surprising number of websites don’t change very often.

They launch, they get updated occasionally, and then they sit there doing their job. A company site. A blog. Documentation. A campaign microsite that quietly becomes permanent. They don’t have complex workflows, they don’t integrate deeply with other systems, and they don’t require a constant stream of editorial activity to stay relevant.

And yet, they are often built on stacks designed for continuous change.

This is where static approaches make far more sense than they’re usually given credit for.

That spectrum is broader than it’s often presented. At one end, you have hand-crafted HTML, no CMS at all, just files and a deploy. At the other end, you have frameworks like Astro, or even React-based stacks, generating static output ahead of time. In between sit a range of lightweight CMS-like tools and workflows. The implementation varies, but the model is the same. Build once, serve many, and avoid runtime complexity.

If the content is relatively stable, the structure is simple, and the number of people touching it is small, then most of the machinery of a dynamic CMS is unnecessary overhead. You are paying a complexity cost for capabilities you don’t need. Databases, admin interfaces, runtime rendering, plugin ecosystems, all sitting there largely unused.

A static approach strips that back. The site becomes a set of files, generated ahead of time, deployed as-is. It is fast by default, resilient by design, and difficult to break in interesting ways. There is very little to go wrong because there is very little happening.

That simplicity is often framed as a limitation. No friendly admin UI, more reliance on developers, less immediacy when making changes. Sometimes that’s true, and sometimes it matters. But in many cases, the editing burden is light enough that those trade-offs are entirely reasonable.

Where this approach fails is when the site isn’t actually simple. When content needs workflows, when multiple stakeholders are involved, when updates are frequent, when structure becomes important. At that point, the lack of a proper content system starts to show, and teams find themselves bolting on layers to compensate.

But for the right kind of site, that never happens. It just sits there, quietly fast, quietly reliable, doing exactly what it needs to do without dragging an entire application behind it.

The mistake is assuming that every website needs to be dynamic, interactive, and constantly evolving. Many don’t. And forcing them into that shape creates more problems than it solves.

…And only when the site doesn’t need a system at all, use AI

Because there’s a growing class of sites which don’t really have a stack at all.

A founder, a marketer, or a designer opens a tool like v0, Lovable, Bolt, or Cursor, describes what they want, and deploys something usable in an afternoon. No CMS. No architecture. No meaningful distinction between build and runtime. Just a prompt.

These sites don’t behave like systems. They don’t evolve through careful iteration. They’re disposable. If something changes, you don’t maintain them, you regenerate them, or you replace them entirely.

Most of them look like they belong in the “static” category. And structurally, they often do. But that framing misses what’s actually changed.

The barrier to creation has collapsed.

For a large class of sites, landing pages, campaigns, early-stage products, and personal brands, the question is no longer which system to choose. It’s whether you need one at all.

That doesn’t invalidate the four patterns. It shifts the threshold at which they become necessary.

Once a site needs structure, governance, integration, or continuity, the same constraints reappear, and the same decisions still apply. But a growing number of sites never reach that point.

They are built quickly, serve their purpose, and are abandoned just as quickly. And that’s fine.

Some websites don’t just contain content. They run on it.

Not as pages, but as structured, interrelated, constantly evolving entities. Articles reference topics. Topics connect to products. Products inherit attributes, appear in multiple contexts, and change over time. Content is created, reviewed, approved, translated, updated, and deprecated. Changes cascade. Templates matter. Governance matters. Ownership matters.

This is where a proper CMS earns its keep. WordPress, Drupal, TYPO3 and their peers are often dismissed as old, messy, or inelegant. And they can be, especially when implemented poorly. But that misses the point. These systems are designed to handle the operational complexity of publishing at scale. Not just editing content, but managing it as a system.

That distinction is where most teams go wrong.

They think they need flexibility, so they reach for headless. They think they need control, so they build custom. What they actually need is structure. Relationships. Workflows. A way to model content so that it can be reused, maintained, and evolved without everything collapsing under its own weight, grounded in the kind of semantic thinking the web was built on (see why semantic HTML still matters).

A mature CMS gives you that. Not perfectly, and not without trade-offs, but with a set of conventions which have been shaped by decades of real-world publishing problems. Roles and permissions. Revision histories. Taxonomies. Templating. Integration points. The unglamorous machinery which keeps content systems coherent.

Where these platforms struggle is when they are treated as page builders, or when they are stretched into product-like experiences they were never designed to support. Performance suffers. Models become tangled. Plugins pile up. The system degrades.

But used for what they are good at, they solve a class of problems which most modern stacks quietly reintroduce, then fail to handle well.

If publishing is continuous, collaborative, and complex, then you do not need a blank canvas. You need a system which understands content as more than pages.

Most organisations that think they have a frontend problem are really dealing with a content problem. And that is not something you fix with a framework.

There’s a class of tools which promise to sit neatly between all of this.

Visual builders. Low-code platforms. Systems where designers can move fast, teams can ship without developers, and the interface feels like the product. Framer, Webflow, Wix, Squarespace. Each with its own flavour, but all orbiting the same idea. You don’t need to choose between flexibility and simplicity. You can have both.

That’s an appealing story – especially for teams who don’t see themselves in any of the four patterns, or who want to borrow a bit from each.

In practice, these tools optimise for the moment of creation, not the reality of operation.

They are excellent at producing a site quickly. You can design in the browser, iterate visually, and get something live without much ceremony. For small projects, short-lived campaigns, or low-stakes sites, that can be entirely sufficient.

The problems tend to surface later.

Structure is shallow. Content often lives inside layouts rather than as reusable entities. Relationships are hard to model cleanly. Workflows are limited. As more people get involved, governance becomes awkward. As the site grows, consistency starts to slip.

Integrations exist, but rarely feel first-class. You can connect systems, but stitching them into something coherent takes effort, and often ends in compromise. Performance becomes something you work around rather than something you control. Portability is limited. Ownership is ambiguous.

None of this is obvious at the start. The tools are designed to feel empowering. But they assume a level of simplicity which many organisations outgrow surprisingly quickly.

That leaves teams in an awkward position. The platform is too limiting to support what they now need, but too entrenched to replace easily. So they layer on workarounds, duplicate content, or accept constraints which shape the site in ways they didn’t intend.

These tools are not wrong. They are just optimised for a different kind of problem. One where speed of creation matters more than long-term coherence, and where the system is unlikely to be pushed very far. I wrote more about these kinds of trade-offs in the long-term cost of short-term platforms.

The trouble is that many teams don’t realise which problem they have until much later.

Most “hybrid” websites aren’t really hybrids. They’re one dominant system with a secondary concern bolted on.

A publisher adds commerce. A retailer adds content. A product adds marketing pages. In each case, one of those concerns drives the system, and the other adapts around it. Problems usually start when teams treat both as equal – and try to optimise the core architecture for everything at once.

That’s how you end up in the uncomfortable middle.

Headless is often presented as the escape hatch here. Stitch together best-of-breed systems. Use WordPress for publishing, Shopify for commerce, and a frontend framework to unify it all. In theory, this gives you the best of each world. Proper content modelling, robust commerce, and complete control over the experience.

In practice, this is one of the hardest things you can build well.

You are now responsible for defining the boundaries between systems, synchronising data, handling failure states, designing editorial workflows which span multiple tools, and ensuring that everything remains coherent as it evolves. Content and commerce stop being separate concerns and start bleeding into each other in awkward ways. Preview becomes non-trivial. Caching becomes strategic. Debugging becomes a cross-system exercise.

Done well, this kind of architecture is extremely powerful. It allows you to treat each concern properly, without forcing one system to pretend to be another. But “done well” requires more than just competent engineering. It requires teams who understand the failure modes, who know where not to be clever, and who can resist the temptation to over-compose.

Most organisations underestimate that cost.

So they build something which looks elegant on a diagram, but becomes fragile in operation. Small changes ripple across systems. Ownership becomes unclear. The surface area of the system expands faster than the team’s ability to manage it.

This is the pattern behind many of the struggles people attribute to specific tools. It’s rarely the platform. It’s the mismatch between the shape of the system and the way it’s being used.

Trying to make one stack do everything usually fails. Trying to make several stacks behave like one often fails more subtly, but just as completely.

The safer move is usually simpler. Decide what the system primarily is. Optimise for that. Let everything else be secondary, even if that means accepting some constraints.

Because every stack has trade-offs. The only real choice is which ones you’re prepared to live with.

Most teams don’t pick the wrong stack because they misunderstand the technology. They pick it because they misunderstand themselves.

They overestimate their need for flexibility, and underestimate the cost of owning it. They assume complexity will arrive later, and that they’ll deal with it when it does. They optimise for the moment of creation, not the years of operation which follow.

The result is predictable. Systems which look right at launch, and feel wrong to live with.

The uncomfortable truth is that most organisations are not building something unique. They are running one of a small number of familiar systems. Publishing. Commerce. A product surface. Something simple which mostly sits still.

Each of those has an answer. Not a perfect one, but one which aligns with how the system behaves and how it will grow.

React and headless architectures, for organisations with strong engineering teams building genuinely product-like experiences

Shopify, for businesses focused on selling, where the hard problems are operational, not technical

Static approaches like Astro, for sites which are simple, stable, and rarely change

WordPress, Drupal, TYPO3, for teams running complex, continuous publishing systems

Everything else is compromise.

There is no prize for choosing the most flexible stack, or the most modern one, or the one which looks best in the hands of a talented team. There is only the system you can operate, day after day, as the organisation changes around it.

That’s the decision.

And it has very little to do with the interface.