Service
Headless Drupal
Drupal as a content and commerce backend, decoupled with Next.js or Gatsby on the front — JSON:API or GraphQL, preview workflows, and editor parity.
Headless is a trade, not an upgrade — you get a free front-end runtime and pay with a moving part between content and page. We only recommend it when the front end earns it (a real app, several consumers off one model, a team that owns the UI), and when we do, editor parity is non-negotiable: live preview, working URLs, draft content rendered exactly as it will publish.
Scope
How the work is delivered
-
Fit assessment
Before any decoupling we check whether you actually need it: a front-end team, multiple consumers, a UI that out-paces Drupal's theme layer. If a fast, well-built Drupal front end wins, we say so — and build that instead.
-
Content API
JSON:API or GraphQL, modeled deliberately — not the whole entity graph dumped over HTTP. Versioned response shapes, sane includes, and pagination and filtering the front end can actually cache.
-
Editor parity & preview
Live preview from the front end against unpublished revisions, real path aliases resolved through the API, and media and embeds that render the same in the CMS and on the page. Editors never guess what they are publishing.
-
Front-end build (Next.js / Gatsby)
We build the consuming app too — SSR/ISR or static, depending on traffic and how fresh content has to be — with the Drupal client, routing, and revalidation wired in. One team, both sides of the API.
-
Caching & delivery
CDN strategy for both the API and the rendered front end, on-demand revalidation when content changes, an image pipeline, and Core Web Vitals tuned to pass on the page types that matter.
Talk through the build
Send the platform, constraints, and timeline. We'll reply with the engineering questions that decide scope.
- Reply within one business day, weekday hours UA / EU.
- 30-minute discovery call when it is useful.
- Scope written around deliverables, risks, and ownership.