At some point in most website projects somebody asks whether the site should be "headless". The question deserves a real answer, because the architecture you choose shapes the cost of everything that follows: how fast the site is, how editors work, how many systems need maintaining, and what a redesign costs in three years. This article lays out the three options in plain language, what each is good at, and why for most business websites we recommend the one in the middle.
Classic: Drupal renders every page
In the classic model, Drupal stores the content and also produces the HTML for every page, using its theme layer. This is how the platform worked for its first two decades, and it remains a perfectly good way to build a website. Everything lives in one system. Editors preview exactly what visitors will see. Caching is straightforward, search engines get complete pages, and there is one deployment, one set of logs and one thing to upgrade.
Its limits appear when the interface needs to feel like an application. Filtering a catalog without a reload, a multi-step form that validates as you type, a dashboard that updates live: these are possible in the classic model, but each one tends to become a small custom project bolted onto templates that were not designed for it. The result is often a site where the simple pages are clean and the interactive ones are fragile.
Headless: Drupal as a content API
In the headless model, Drupal stores and manages content but renders nothing. A separate frontend application, usually built with a JavaScript framework and deployed on its own infrastructure, fetches content over an API and produces the pages. The appeal is real: the frontend team works in tools they know, the interface can be as dynamic as any application, and the same content can feed a website, a mobile app and a kiosk from one source.
The costs are also real, and they are the ones that tend to be discovered late. There are now two applications to build, host, secure, monitor and upgrade, on two release calendars. Editors lose the preview, because the system that holds the content is not the one that displays it, and rebuilding that preview is a project in itself. Every feature Drupal provides for free on a rendered page, such as caching, access control on rendered output, form handling, translations and menu structures, has to be rebuilt or worked around in the frontend. And the two systems must be kept in step forever, which is a coordination cost that never goes away.
Headless is the right answer for some organizations: those with several channels that genuinely need the same content, or with a frontend team that will own a separate application as its main job. For a business whose primary channel is its website, it usually means paying for two systems to get one.
Hybrid: modern components inside Drupal
The third option keeps Drupal as the single system that renders pages, but replaces the traditional theme layer with a library of components written in React. Drupal renders each component on the server, so the page arrives complete, fast and indexable. The browser then activates the same components where interaction is needed, so a filterable catalog, a live form or a dashboard behaves like an application without a second backend.
This is how we build, through our component-driven frontend. The practical effects are the ones people want from headless without its overheads. Editors keep their preview, because Drupal still produces the page. Permissions, translations, caching and forms still come from the platform. There is one deployment and one upgrade calendar. And the interface can be as rich as it needs to be, because every piece of it is a real component with its own state, tests and accessibility contract. Sites built this way feel like software while costing what a website costs to run.
How to choose
A few questions settle most cases.
- How many channels? One website, perhaps with a customer area: hybrid. A website plus a native app plus in-store screens, all showing the same content: headless deserves serious consideration, though hybrid with Drupal's API layer serving the other channels often covers it.
- Who maintains the frontend? A dedicated frontend team that will own a separate application: headless is viable. An agency or a small team maintaining the whole site: hybrid keeps everything in one place.
- How interactive is the interface? Mostly pages with some forms: classic is enough, hybrid is more comfortable. Application-like screens throughout: hybrid or headless, and hybrid is cheaper.
- How important is editorial preview? If editors need to see exactly what they are publishing, classic and hybrid provide it; headless has to rebuild it.
- What is the maintenance budget? Two applications cost roughly twice as much to keep current. That figure alone decides many projects.
The middle path is not a compromise
It is tempting to see hybrid as a halfway house between the two "pure" options. In practice it is the option that takes the best of each: the single-system simplicity of classic and the modern interface of headless, without the fragility of the first or the duplication of the second. It also leaves the door open. A hybrid site already has a component library and an API layer, so if a second channel genuinely appears later, adding a headless consumer for that channel is a modest step rather than a rebuild.
If you are weighing these options for a new project or a redesign, we would be glad to talk them through with your specific site in mind. The right answer depends on your channels, your team and your budget, and an hour's conversation usually makes it clear.