The Decoupled Drupal Decision Kit
Scorecard Preview
Decoupled Drupal means a separate front-end application renders your pages while Drupal manages the content. It is one of three production architectures, not the only alternative to a standard Drupal site.
This kit helps you choose the one your channels, release cadence, and team can support.
| Architecture | Who renders the page | Codebases | Front-end releases |
|---|---|---|---|
| Coupled | Drupal renders the HTML | One | Tied to Drupal releases |
| Progressively decoupled | Drupal renders the page; JavaScript components handle specific interactive regions | One deployable application | Tied to Drupal releases |
| Fully decoupled (headless) | A separate front-end application renders everything | Two, with two pipelines | Independent |
The rule the scorecard is built on: if no one is funded to run front-end engineering for three years, the recommendation stops at progressively decoupled, whatever the total says.
Five Questions
- What consumes your content that is not a browser? (weighted × 3)
- Does your front end need a release cadence Drupal cannot give it? (weighted × 2)
- Can you fund front-end engineering for three years? (weighted × 2)
- How little composition autonomy do your editors need? (weighted × 2)
- Does the interface exceed what server-rendered templates can deliver? (weighted × 1)
Each answer is scored from 0 to 3 and weighted, for a maximum total of 30. Your total points to staying coupled, progressively decoupling, or fully decoupling.
Who Is This Kit For?
CTOs, CIOs, and VPs of Technology who own a Drupal platform and the budget behind it. Use it when you are:
- Reviewing an agency proposal that recommends going headless
- Planning a redesign or replatform and choosing the architecture
- Running a decoupled Drupal site on a front-end framework that is losing support, such as Gatsby
- Pricing the three-year run cost of a decoupled front end, not just the build
Fill it in with the three people who own the answer: the platform budget owner, the front-end engineering lead, and the editorial lead.
The Case for Decoupling Got Narrower in 2026
Most decoupling decisions rest on proxy arguments: a better editing experience, a component model, or the need for an API.
Drupal now answers all three natively, through Drupal Canvas, Single Directory Components, and JSON:API in core.
What still justifies decoupling is the short list that always carried the case: real multichannel delivery, a front end that must ship on its own schedule, and a team funded to run two codebases.
The kit scores those directly, so the decision rests on them.
- Three architectures, defined. Coupled, progressively decoupled, and fully decoupled, compared on who renders the page, codebases, and release cadence.
- What changed in 2026. The releases that removed old reasons to decouple, and the three reasons they left standing.
- Five weighted questions. Scoring anchors from 0 to 3 for channels, release cadence, front-end funding, editorial autonomy, and interface complexity.
- The scorecard and veto rule. A fill-in scorecard, score bands for each recommendation, and a worked example from a state university portal.
- Your first 90 days. What each outcome changes in next quarter's work.
- Cost comparison and worksheet. Eight cost lines across all three architectures, the four line items decoupled budgets leave out, and a three-year worksheet to price against your own rates.
- The AI trade. How Drupal's eight 2026 AI roadmap priorities carry over to each architecture, and why AI shouldn't settle the decision.
- If you are already decoupled. Three questions and a path for platforms on an aging front-end framework, with Gatsby as the example.
- Eight questions to ask any agency. Including us.