Decoupling Drupal is the right decision more often than it used to be and less often than it is sold. It pays when one editorial back end has to feed several front ends, when the interface is genuinely an application rather than pages, or when a front-end team already exists and works in React or Vue. It costs when it is chosen for a single website, because you then maintain two applications, two deployment pipelines and two sets of dependencies to render pages Drupal could have rendered on its own. We will tell you which case you are in before quoting for either.
- Who this is for
- Organisations feeding a website, a mobile app and a partner integration from one content source, product teams with an existing JavaScript front end, and anyone who has been told to go headless and wants the trade-off spelled out first.
When decoupling earns its cost
Four situations where it is clearly right:
- More than one front end. A website, a mobile app and a partner feed served from one editorial workflow. This is the case decoupling was invented for, and it is the one where the second application pays for itself.
- The interface is an application. Heavy client-side state, real-time updates, complex interaction. At that point you are writing an application anyway, and Drupal is better used as the content, identity and permission layer beneath it.
- The front-end team already exists. If you employ React or Vue engineers and no Drupal front-enders, decoupling matches the architecture to the people who have to maintain it, which is a legitimate engineering reason.
- Drupal is being added behind something that already works. A front end you are happy with, needing a content back end with real editorial workflow, roles and translation behind it.
And the case against, stated plainly: for a single content-driven website with a normal editorial team, decoupling adds a second codebase, a second pipeline, a second set of dependencies, and it costs you Drupal preview, layout and caching behaviour you then rebuild by hand. If that is your situation, the honest recommendation is a well-built Drupal front end, which is web development.
How we build it
Drupal supplies JSON:API in core and GraphQL through a contributed module. Which one is the right interface depends on who is consuming it: JSON:API is standard, predictable and needs no schema work; GraphQL suits a front end that wants to shape its own queries and avoid over-fetching.
What actually decides whether a decoupled build succeeds is rarely the protocol. It is the parts that get left until last:
- Authentication and authorisation. Drupal roles and permissions have to reach the API rather than being reimplemented in the front end, which is where decoupled projects most often develop security holes.
- Caching and invalidation. Drupal cache tags carried through the API layer, so that an editor changing a page invalidates exactly what changed.
- Editorial preview. Editors expect to see unpublished work before it goes live. This is the single most common thing missed in a decoupled scope, and retrofitting it is expensive.
- Media, images and responsive variants. Image styles and derivatives delivered through the API rather than rebuilt on the front end.
- Translation and language negotiation where the site is multilingual.
We scope all five explicitly, because a decoupled quote that does not mention preview is a quote that is going to be revised.
Progressive decoupling as the middle option
The choice is not binary. Progressive decoupling keeps Drupal rendering the pages and mounts a JavaScript application into the parts of the interface that need it: a booking widget, a dashboard, a configurator.
You keep Drupal caching, preview, layout and URL handling, and you pay the cost of a JavaScript application only where it buys something. For most organisations that arrive asking for headless, this is the arrangement that actually fits, and it is how several of the platforms in our own platforms are built.
Hosting, delivery and what it costs
A decoupled system is two deployables and needs two pipelines, two environments and monitoring on both. We build on standard containers so neither half is tied to a single vendor, and we document the deployment path for a team that was not in the room when it was built. That work is described at DevOps and hosting.
Pricing follows the same model as every other engagement: paid discovery, then a fixed price once the architecture is agreed, milestone payments, full source code ownership, and a warranty of one year as standard extendable up to three. The bands are at pricing.
Questions we get asked
Should we go headless?
Only if you have more than one front end to feed, an interface that is genuinely an application, or a front-end team that already works in JavaScript. For a single content website with a normal editorial team, a well-built Drupal front end costs less to build and much less to keep running.
JSON:API or GraphQL?
JSON:API is in Drupal core, needs no schema work and is predictable. GraphQL suits a front end that wants to shape its own queries and avoid over-fetching. The consumer decides, not the back end, and the decision is cheap to make early and expensive to change late.
Will our editors still get preview?
Only if it is in scope. Preview of unpublished content is the most commonly omitted requirement in decoupled projects and one of the more expensive to retrofit, so we scope it explicitly rather than letting it surface in user acceptance testing.
What about SEO?
It is solvable and it is not free. A decoupled front end needs server-side rendering or static generation, plus metadata, canonical URLs, structured data and a sitemap that the front end is responsible for rather than Drupal. All of that is normal work in a framework like Next.js or Nuxt, but it has to be scoped rather than assumed.
Can you work with our existing React or Vue front end?
Yes. Adding Drupal behind a front end you are happy with is one of the clearer cases for decoupling, and you get editorial workflow, roles and translation without touching the interface.
Is progressive decoupling a compromise?
It is usually the correct answer rather than a compromise. Drupal renders the pages and a JavaScript application handles the parts that need it, so you keep caching, preview and routing and pay for a second application only where it earns its keep.
Build
Related services
Get a straight answer on whether to decouple
Tell us what has to be fed and by whom. We will say which architecture fits, including when it is not this one.