There are only four sensible ways to build a website

9th April, 2026Your 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.Table of contentsFour patterns, four stacksWhen the website is the product, use ReactWhen the job is selling, use ShopifyWhen the site mostly sits still, use staticWhen publishing is the system, use WordPress (or Drupal, or TYPO3)The seductive middle groundWhen you try to be more than one thingChoose the system you can runFour patterns, four stacksOnce 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.

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.When the job is selling, use ShopifySome 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.When the site mostly sits still, use staticA 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 AIBecause 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.