CMS & Commerce
Drupal
Structured content, fine-grained permissions and multilingual done properly — built by engineers who run what they ship.
Overview
Drupal is an enterprise-grade, open-source content management system written in PHP and built on Symfony components. Where most CMS platforms treat content as pages of formatted text, Drupal treats it as structured data: everything is an entity with typed fields, and you model your content the way you would model a database — content types, fields, taxonomy, and relationships between them. That single design decision is why Drupal runs so many university, government, non-profit and large-institution sites. When your content is genuinely complex — thousands of interrelated records, editorial workflows, and views that assemble content in different shapes for different audiences — Drupal gives you a modelling toolkit that page-oriented systems simply do not have.
We use Drupal where content architecture is the hard part of the problem. Its core strengths are structured content and complex modelling through entities, fields and the Views query builder; granular role-based permissions that let you say precisely who may do what to which content; first-class multilingual support where translation is built into the content model rather than bolted on; and a security track record that institutions trust. The Drupal Security Team coordinates disclosure and patching across core and thousands of contributed modules, which is a large part of why risk-averse organisations standardise on it.
Modern Drupal is also a capable headless back end. Through the JSON:API module in core, and GraphQL where a query language fits better, you can run Drupal purely as a content repository behind a React front end or a native app, keeping its editorial and permissions strengths while decoupling the presentation layer. We are equally clear about the cost: Drupal has a steeper learning curve and a higher build cost than WordPress, a smaller developer talent pool, and a history of disruptive major-version upgrades. For a simple brochure or marketing site it is over-engineering, and we will tell you so before you spend the money.
Best for — Large, editorially sophisticated sites — multilingual, permission-heavy and high-governance — where structured content modelling is the deciding factor over the ease and speed of WordPress.
Why teams choose Drupal
Content modelled as structured data
Entities, typed fields, taxonomy and relationships let you model content the way it actually behaves, then query and assemble it with Views. You stop copy-pasting layouts and start describing content once and presenting it many ways.
Governance that scales to large teams
Granular role-based permissions and editorial workflows mean many contributors can work safely in one system, each able to touch only what their role allows. This is what makes Drupal defensible for institutions and regulated organisations.
Multilingual and headless without a rebuild
Translation is native to the content model, and JSON:API and GraphQL let the same Drupal instance serve a traditional themed site or a decoupled front end. You keep editorial strengths whether you render in Drupal or in React.
Why businesses choose Drupal
- Your content is genuinely complex and structured, and you have outgrown — or would quickly outgrow — what a page-oriented CMS can model cleanly.
- You need real editorial governance: many contributors, defined roles, review and approval, and an audit of who can do what.
- Multilingual, accessibility and long-term institutional stability matter more to you than the fastest, cheapest possible launch.
- You want the option to run headless later — serving a React front end or native app from the same content — without re-platforming.
What we build with Drupal
The capabilities this technology is genuinely strong at — and what we most often build with it.
Entities, fields and content types
Drupal’s entity system is the foundation: nodes, users, taxonomy terms and custom entities, each with typed fields you define. We model your content types deliberately so that structure, validation and reuse are built in from the start rather than patched in later.
Views — the query builder
Views lets you build lists, grids, feeds, blocks and pages by querying entities and fields, with filters, sorts, relationships and contextual arguments — without writing SQL. It is the tool that turns a well-modelled content store into the many different presentations a real site needs.
Taxonomy and structured relationships
Drupal’s taxonomy system and entity references let content relate to content: categories, tags, hierarchies, and typed links between records. This is what makes faceted navigation, related-content blocks and complex information architecture straightforward instead of a hack.
Granular role-based permissions
Permissions in Drupal are fine-grained and role-based down to individual operations on individual content types. Combined with modules for content moderation and workflows, this gives you editorial governance that scales from a handful of authors to a large distributed team.
Native multilingual
Drupal translates content, interface and configuration across as many languages as you need, with language negotiation and per-field translation built into core. For genuinely multilingual organisations this is a core reason to choose Drupal over the alternatives.
Headless via JSON:API and GraphQL
JSON:API ships in core and exposes your content model as a standards-based API with no custom code; GraphQL is available where a typed query language suits the front end better. Either way, Drupal becomes a content back end for React, native apps or multiple channels at once.
Use cases
University and public-sector sites
Large sites with many content owners, strict accessibility requirements, multilingual audiences and long lifespans — the environment Drupal was effectively built for and where its governance and security posture pay off.
Multilingual content platforms
Publications, membership bodies and international organisations that manage the same structured content across many languages, with translation woven into the editorial workflow rather than duplicated by hand.
Complex intranets and knowledge bases
Permission-heavy internal sites where different teams see and edit different content, with structured records, taxonomy-driven navigation and workflow-based review built in.
Headless content back end
Drupal as a decoupled repository feeding a React front end, a mobile app, or several channels through JSON:API or GraphQL — keeping editorial and permissions strengths while the presentation layer lives elsewhere.
When Drupal is the right choice
- Right when content architecture is complex — many interrelated content types, structured fields, and views that assemble the same data into different shapes for different pages and audiences. This is Drupal’s home ground and where it outperforms every page-oriented CMS.
- Right when you need fine-grained, role-based permissions and editorial governance: dozens of editors, reviewers and approvers, each allowed to touch only specific content in specific ways. Drupal’s permission model was built for exactly this.
- Right when multilingual is a core requirement rather than an afterthought — translated content, interface and configuration across many languages, with translation built into the content model instead of grafted on by a plugin.
- Wrong for a simple brochure or marketing site — a few pages, a blog, some campaign landing pages. Here Drupal is over-engineering: WordPress will be faster to build, cheaper to run, and easier for a marketing team to operate. We will steer you there rather than sell you complexity you do not need.
- Wrong when speed to launch and a small budget matter more than long-term content structure, or when nobody on your side will own the editorial model. Drupal rewards deliberate modelling and punishes teams who want the CMS to decide everything for them.
Drupal: pros and cons
Strengths
- Best-in-class structured content modelling — entities, fields, taxonomy and Views make complex, interrelated content tractable in a way page-based systems cannot match.
- Granular role-based permissions and editorial workflow support built into core, suited to large teams and high-governance environments.
- Strong, native multilingual support where translation is part of the content model rather than a plugin bolted on afterwards.
- A serious security posture: a dedicated Security Team, coordinated disclosure, and a track record that governments, universities and large institutions rely on.
Trade-offs
- A much steeper learning curve than WordPress. Drupal expects you to understand its entity and configuration model, and productive work needs experienced developers, not hobbyists.
- Higher build cost. The same site costs more to build in Drupal than in WordPress because you are modelling content properly rather than installing a theme and a handful of plugins.
- A smaller developer talent pool. Good Drupal engineers are harder to find and hire than WordPress developers, which affects both build and long-term maintenance.
- Major-version upgrades have historically been disruptive and occasionally amounted to rebuilds. Modern Drupal’s continuous-upgrade model has improved this considerably, but the reputation is not entirely undeserved.
Architecture
A Drupal build succeeds or fails at the content-modelling stage, so that is where we spend our early effort. We work out the entities, content types, fields and relationships before writing much code, because in Drupal the model is the architecture — get it right and Views, permissions and multilingual all fall into place; get it wrong and you fight the system for the life of the site. We favour proper entity references and taxonomy over overloaded single content types, so the structure reflects how your content actually behaves.
Underneath, Drupal runs on PHP and Symfony components, with a configuration management system that lets us version site configuration in code and deploy it predictably from development to production rather than clicking through admin screens on the live site. We keep custom code in well-defined modules, lean on stable contributed modules rather than reinventing them, and decide early whether the site is traditionally themed or decoupled — because that choice shapes the whole build. Where a headless architecture fits, JSON:API or GraphQL exposes the model to the front end while Drupal stays the source of editorial truth.
Performance
Drupal is a database-driven system that assembles pages from many entities and fields, so naive builds can be slow — the flexibility that makes it powerful also gives it more work to do per request. We treat caching as a first-class design concern: Drupal’s render cache and cache tags let it invalidate precisely the fragments that changed rather than rebuilding whole pages, and a reverse-proxy or CDN layer serves anonymous traffic without touching PHP at all.
Beyond caching, performance comes from disciplined Views queries, avoiding N+1 loads across entity references, and keeping the contributed-module count honest — every module is code that runs on every request. We profile real pages rather than guessing, tune the database, and where read volume is high we put a caching layer such as Redis in front of it. For decoupled builds, much of the render cost moves to the front end, and Drupal’s job becomes serving cacheable API responses quickly.
Security
Security is one of the strongest reasons organisations choose Drupal. The Drupal Security Team coordinates responsible disclosure and patching across core and thousands of contributed modules, and publishes advisories on a predictable schedule — which is why governments, universities and large institutions are comfortable standardising on it. Drupal’s permission and access systems are also genuinely granular, so you can enforce who may see and change what at the level of individual operations, not just broad admin-versus-editor roles.
Our part is to keep that posture intact. We keep core and contributed modules patched promptly, we are conservative about which contributed modules we install because each one is attack surface, and we sanitise output and use Drupal’s form and database APIs rather than hand-rolling queries. We treat authentication, access control and configuration as deliberate decisions, and we keep the update path healthy so that applying a security release is routine rather than a crisis.
Scalability
Drupal scales in two directions, and they need different attention. It scales editorially — more content types, more languages, more contributors and more governance — and this is where its structured model shines, because a well-designed content architecture absorbs new requirements without a rebuild. Adding a content type or a language extends the model rather than fracturing it.
It also scales under traffic, though that is more an infrastructure question than a Drupal one. Anonymous traffic is served overwhelmingly from cache — reverse proxy, CDN and page cache — so the PHP and database tier only handles authenticated, dynamic requests. From there it is standard horizontal scaling: multiple application servers behind a load balancer, a tuned database with read replicas where needed, and a shared cache such as Redis. Decoupled architectures scale the front end independently and let Drupal concentrate on serving cacheable content, which suits high-read, multi-channel workloads.
Drupal integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start with the content model, not the theme. Before anything visual, we map the entities, content types, fields, taxonomy and relationships, and we agree the permission and workflow structure — because in Drupal these are the decisions that are cheap to get right early and painful to change later. From there we build in vertical slices: a real content type, editable, permissioned and rendered end to end, so you see working software rather than an admin screen full of promise.
The engineers who model your content are the ones who build and maintain it. That is what we mean by operating what we build — decisions are made by people who will live with the upgrade path and the maintenance reality, so we favour stable contributed modules, versioned configuration, and a clean upgrade posture over whatever is fashionable. You get honest advice, including the advice that WordPress would serve you better if that is genuinely the case.
The service behind it
Delivered throughWeb DevelopmentWhat we build with Drupal
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Drupal in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in CMS & Commerce
Why teams choose us for Drupal
Senior engineers only
Drupal rewards experience and punishes guesswork. The people modelling your content have done it before and have seen how a model ages — there are no juniors learning the entity system on your project.
We operate what we build
We run the sites we ship, so we optimise for the upgrade and maintenance reality, not the launch demo. That means conservative module choices, versioned configuration, and a healthy path to the next major version.
Honest about Drupal versus WordPress
If your site is a brochure or a marketing platform, we will tell you WordPress is the better and cheaper choice before you commit. We recommend Drupal only when its structured content, permissions or multilingual strengths genuinely earn their cost.
Comfortable headless or traditional
We build Drupal both as a themed site and as a decoupled back end behind React via JSON:API or GraphQL, and we help you choose between them on the merits rather than the fashion.
Typical timeline
- 01
Content modelling and discovery
One to three weeks agreeing the entities, content types, fields, taxonomy, permissions and languages. In Drupal this is the foundation, so we settle it before build volume grows.
- 02
First working slice
Two to three weeks building one real content type end to end — editable, permissioned and rendered — to prove the model against reality rather than a diagram.
- 03
Iterative build
Content types, Views, workflows and multilingual delivered in short cycles, each shippable, with configuration versioned in code and deployed predictably.
- 04
Hardening and handover
Caching and performance tuning, a security and accessibility pass, and documentation so your editorial team and developers can own and extend the site.
How pricing works
- Fixed-scope builds for well-defined sites — a defined content model, a set number of content types and languages, and an agreed feature set — quoted once we understand the modelling and governance requirements.
- Monthly senior engagement for ongoing content platforms where the model evolves, new sections and languages are added, and you want continuity rather than a one-off deliverable.
- Audits and rescues of existing Drupal sites — a stalled build, a difficult upgrade, a performance or security review — priced by the assessment.
- Drupal maintenance and upgrade support: keeping core and modules patched, applying security releases, and managing the move between major versions on a healthy schedule.
Hire Drupal engineers
Need Drupal capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Drupal engineersCommon questions
Should we choose Drupal or WordPress?
It depends on how complex your content is. WordPress wins on ease, ecosystem size, cost and speed to launch — it is the right choice for marketing sites, blogs and brochureware. Drupal wins when content architecture is genuinely complex: many interrelated content types, fine-grained permissions, native multilingual, and high-governance editorial workflows. If your site is simple, we will steer you to WordPress; if the hard part is modelling structured content, Drupal earns its extra cost.
Is Drupal secure enough for a government or university site?
Yes — that is one of its core strengths. Drupal has a dedicated Security Team that coordinates disclosure and patching across core and thousands of contributed modules, with advisories on a predictable schedule, which is precisely why governments, universities and large institutions standardise on it. Its granular permission model also lets you enforce access at the level of individual operations. Security still depends on keeping core and modules patched, which we treat as routine maintenance rather than an afterthought.
Can Drupal be used headless with a React front end?
Yes. JSON:API ships in Drupal core and exposes your content model as a standards-based API with no custom code, and GraphQL is available where a typed query language suits the front end better. You can run Drupal purely as a content back end feeding a React application, a native app, or several channels at once, keeping its editorial and permissions strengths while the presentation layer lives elsewhere.
Are Drupal upgrades still as painful as people say?
Historically, major-version upgrades were disruptive and occasionally amounted to rebuilds, and that reputation is not entirely undeserved. Modern Drupal has moved to a continuous-upgrade model, so staying current is far less painful than the old major-version jumps, provided the site is kept up to date rather than left to drift. We keep the upgrade path healthy from the start so that moving between versions is routine rather than a crisis.
Why is Drupal more expensive to build than WordPress?
Because you are modelling content properly rather than installing a theme and a handful of plugins. Drupal expects deliberate content architecture, has a steeper learning curve, and draws on a smaller pool of experienced developers, all of which raise the build cost. That cost is worth paying when content complexity, permissions or multilingual are the hard part of your problem — and it is not worth paying for a simple site, which is exactly when we will recommend WordPress instead.
Building on Drupal?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.