Decoupling Drupal pays when one editorial back end feeds several front ends, when the interface is an application rather than pages, or when your front-end team already works in React or Vue. For a single website it usually costs more than it returns: two applications to deploy, and editorial preview and caching to rebuild by hand. We tell you which case you are in before quoting either, and when decoupling fits, we build Drupal as the content, identity and permission back end behind it.
Who this is for
- More than one front end. A website, an app and a partner feed served from one editorial workflow. This is the case decoupling was designed for.
- The interface is an application. Heavy client-side state, real-time updates, complex interaction. Drupal then works best as the content, identity and permission layer beneath it.
- A front-end team that already exists. If you employ React or Vue engineers and no Drupal front-end developers, decoupling matches the architecture to the people who maintain it.
- A front end that already works. You are happy with it and need a content back end with real editorial workflow, roles and translation behind it.
- Told to go headless, and unsure. For one content website with a normal editorial team, a well-built Drupal theme costs less to build and far less to run. That is how sprep.org works, whose theme we rebuilt in 2024, and it is enterprise website development.
What you get from a decoupled build
- The architecture decision in writing: coupled, progressive or fully decoupled, and why
- A Drupal back end with the content model, editorial workflow, roles and translation
- The API layer, JSON:API or GraphQL, with permissions enforced on the Drupal side
- Editorial preview of unpublished content in the front end
- Cache invalidation from Drupal through to the front end and the CDN
- Two build pipelines, documented for a team that was not in the room
Sample Decoupled scope sheet Agreed before the price is fixed
API
- JSON:API or GraphQL chosen By the front end that consumes it
- Roles and permissions enforced in Drupal
- Cache tags carried through to the front end
Editorial
- Preview of unpublished content
- Image styles served through the API
- Translation and language negotiation
Delivery
- Server-side rendering or static generation
- Metadata, canonical URLs and sitemap from the front end
- A pipeline and monitoring for each application
An engineer reads it and replies within one business day.
How a headless Drupal build runs
How a headless Drupal build runs
- Discovery Every front end, app and feed that needs the content, and who edits it. Output: the architecture decision
- Prototype One content type flowing from Drupal to the front end, with preview, before you sign. Output: the prototype
- Fixed price Quoted against the agreed scope sheet, preview and caching included. You keep the scope sheet
- Build Back end, API and front end built together, shown on staging as each part lands. You keep both repositories
- Acceptance Editors preview, publish and translate through the new front end before launch. You keep the test record
- Warranty Defects in what we built are fixed by the team that built it. You keep the handover pack
Coupled, progressive or fully decoupled
The choice is not binary. Progressive decoupling keeps Drupal rendering the pages and mounts a JavaScript application only into the parts that need it, such as a booking widget, a dashboard or a configurator. You keep Drupal's caching, preview, layout and URL handling, and pay for a second application only where it buys something.
| Question | Coupled | Progressive | Fully decoupled |
|---|---|---|---|
| Who renders the pages | Drupal, with Twig templates | Drupal, with JavaScript in the parts that need it | A separate JavaScript application |
| Editorial preview | Built in | Built in | Has to be built |
| Caching and URLs | Drupal's own | Drupal's own | Rebuilt in the front end, with cache tags carried through the API |
| Things to deploy | One | One | Two, each with its own pipeline and monitoring |
| Fits when | One content website with a normal editorial team | Pages with a few interactive parts | Several front ends, or an interface that is an application |
How a headless Drupal build is put together
Drupal supplies JSON:API in core and GraphQL through a contributed module. 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. The consumer decides, and the decision is cheap to make early and expensive to change late.
Decoupled Drupal Drupal keeps the content; the front ends are separate applications
Drupal Content model, editorial workflow, permissions and preview
JSON:API or GraphQL
Website React or Vue, rendered on the server
Mobile app On the same back end
Cached pages
CDN Serves visitors from the edge
What decides whether a decoupled build succeeds is rarely the protocol. It is the parts left until last: Drupal roles and permissions enforced in the API rather than reimplemented in the front end; cache tags carried through, so an editor's change invalidates exactly what changed; preview of unpublished content; image styles delivered through the API; and language negotiation where the site is multilingual. We scope each of these explicitly, because a decoupled quote that does not mention preview is a quote that will be revised.
Behind the API, the back end is ordinary Drupal engineering: the content model, permissions, and custom modules where configuration cannot do the job. We have published Drupal modules on drupal.org since 2012; the ones we maintain are listed on our open-source page.
What a headless Drupal build costs
A decoupled system is two deployables. It needs two pipelines, two environments and monitoring on both, and that shows in the quote: the same content model costs more to deliver decoupled than coupled. We build on standard containers so neither half is tied to one vendor; that side of the work is Drupal DevOps and CI/CD.
The price is fixed once the architecture and the scope sheet are agreed. Which band a build sits in depends on the content model, the integrations and the number of front ends, as for any other build; the bands are on the pricing page.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Should we go headless?
Only if you have more than one front end to feed, an interface that is 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.
Will our editors still get preview?
Only if it is in scope. Preview of unpublished content is the requirement most often left out of decoupled projects and one of the more expensive to add later, so it is on the scope sheet from the start.
What about SEO with a decoupled front end?
It is solvable and it is not free. The front end needs server-side rendering or static generation, and it becomes responsible for metadata, canonical URLs, structured data and the sitemap instead of Drupal. That work is scoped, not 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: you get editorial workflow, roles and translation without touching the interface.
Can the same back end feed a mobile app?
Yes, that is one of the reasons to decouple. We build the app only as part of the web project, when a native app is warranted; see our FAQ on mobile apps.
Not covered here? Ask us directly.
Discuss your architectureAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Custom Web Application Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Tell us what your content has to feed
List the front ends, apps and partners that need your content, and who edits it. We will say which architecture fits, including when it is not this one.
An engineer reads it and replies within one business day.