Agnostics with a favourite: how we choose the platform for a website

We like to present ourselves as technology-agnostic. Given our numbers, that claim needs an explanation. We have been building websites for more than fifteen years (the oldest project we still keep in the archive dates from late 2010), and in that time we have worked with more than 350 organisations: hospitals and research centres such as Sant Joan de Déu or Vall d’Hebron, pharmaceutical companies such as Bioibérica or Ferrer, universities and schools such as UB, UPC, URL, UdG, ESADE or the Jesuïtes, infrastructure such as the Port of Barcelona, industry such as Ercros or Grupo Ehlis, and institutions such as CERN, CEOE or the Diputació de Barcelona. In nine out of ten cases, the platform was Drupal.

An agnostic with that distribution is either fooling themselves or working from a biased sample. We accept the second and we are going to explain the mechanism, because the mechanism is the useful part. The preference, on its own, is no use to anyone.

The favourite that lost our own project

Let’s start with the most visible exception. When it came to deciding what to build this website on, Drupal lost. Here a single person edits, there are no approval workflows, the content carries no special legal obligations, and we wanted a lab where we could try out a decoupled architecture and a strong integration of AI in both development and content management. With that profile, setting up Drupal would have been the same over-engineering we criticise in anyone who deploys an ERP to manage three invoices.

This is not a charming anecdote: it is the rule applied at home before selling it outside. And it is also the reason “nine out of ten” does not make us fanatics. The tenth time exists, and when it comes up, we take it.

Choosing a platform is two decisions disguised as one

The first decides which family of tools you play in. The second decides which tool, within that family, holds up to your case without breaking or being overkill.

First decision: what you are willing to rent

A proprietary platform, whether a suite like Adobe Experience Manager or Sitecore or a SaaS like Contentful or HubSpot, rents you all four things at once: code, data in its format, architecture and vendor. That can be a perfectly reasonable decision if you have the budget and accept that someone else sets the roadmap. Open source hands you ownership, at a price worth saying out loud: the spend does not disappear, it moves from the licence to development and talent. What you buy with the difference is portability, no perpetual rent, and the certainty that nobody can withdraw the product from you.

Here it is worth clearing up a common misunderstanding. The line does not run between “open source” and “commercial” in the sense of free versus paid. Typo3 is GPL from top to bottom and has a foundation behind it; Liferay has a free community edition and a commercial edition on top. The useful question is a different one: who controls the licence, and what can happen if they change their mind.

Directus, the CMS behind this website, is a good example of why that question matters. It was born under the MIT licence, in 2023 it moved to Business Source License 1.1 (free use below five million dollars in revenue and a ban on competitive use, a licence the Open Source Initiative does not recognise as open source), and in 2026 it has opened a public consultation on a new revision. We knew this when we chose it and we accepted it: if Directus changes the rules, we lose a weekend of migration. If the same thing happens to a university with two hundred sites and fifteen years of content, it is an institutional crisis. The same decision can be sensible in one case and reckless in the other. That, exactly, is what it means to have judgement instead of favourites.

The same decision can be sensible in one case and reckless in the other. That, exactly, is what it means to have judgement instead of favourites.

Second decision: how much complexity there is to govern

With the family decided, the questions become concrete. How many people edit, and with what permissions? How many sites share brand, components and users? How many languages, and who is responsible for each translation? What content needs approval before publishing, and who gives it? What legal obligations apply: accessibility, enforceable since June 2025 under the EAA with the WCAG 2.1 AA standard, data protection, change traceability? What does it integrate with: CRM, DAM, SSO, ERP, commerce? How long will it live? Who will maintain it in five years, and will they know how?

When most of those answers are “one”, “none” or “I don’t know yet”, the list of reasonable platforms is long and Drupal is almost never the best. We have built projects on WordPress and on other lighter platforms with results we are not ashamed of, and we will keep recommending them when the profile is that one: a small editorial team, a simple content model, little governance.

When the answers start to pile up, the list shortens fast. And that is where Drupal appears, not because it is better in the abstract, but because what other platforms solve with third-party plugins (structured content with its own types and fields, permissions down to field level, revisions and approval workflows, multisite, multilingual) is part of Drupal’s core, maintained by the same security team that publishes the project’s advisories. Fewer third-party pieces means less surface to audit and fewer dependencies that break with every update.

The market data tells the same story if you look at it properly. According to W3Techs, Drupal sits at around 0.7% of all websites in the world. According to HTTP Archive, between 6% and 7% of the ten thousand highest-traffic sites. Ten times more presence where the web gets complicated than where the web is just a website.

What Drupal is when it stops being a CMS

That same architecture is the reason Drupal shows up in projects that do not fit the “content management system” label. On the same core you can build shops (Drupal Commerce), learning platforms (Opigno) and communities (Open Social), and in all three cases the content model, the permissions and the workflows are the same ones that govern the public website. A hospital can have a website, an intranet and a patient portal with a single user model; a university, a hundred faculty sites with a shared brand and editorial autonomy.

And it can be served coupled, with Drupal rendering the pages, or decoupled, with Drupal as the content source for a frontend in whichever framework the team prefers. Both options coexist in the same project, and the decision is made per team and per use case, not by fashion.

When we recommend something else

Besides our own website, there are three situations in which Drupal drops out of the conversation. The first, already mentioned: a simple editorial project, one editor, a short life. The second: the client has a platform requirement we are not going to argue with, because it is part of their systems strategy and not of our opinion. The third is the most instructive: custom-built sites by third parties where we have had to step in. There we learned the reverse argument to ownership. Owning the code is no use if the only person who understood it no longer works there. A custom build is ownership without community, and the community (tens of thousands of contributors, documentation, security advisories, hireable talent) is what makes ownership maintainable.

The next editors of your website will not be people

There is one more reason to take the second decision seriously, and it points to the immediate future. The next ones to edit content on your website will not only be people: they will be AI agents that generate, update and publish. Our own lab already talks to them: Directus added native Model Context Protocol support in late 2025, and Drupal supports it too. The question that opens up is which system decides what an agent can touch, under what identity, and who reviews it. We will give away the answer: the architecture that governs people well is the one that will govern agents. We will develop this in the next pieces of this series.

Before your next meeting with a vendor

This is the questionnaire we apply before recommending a platform. Use it with any vendor, ourselves included.

1. If the licence owner changes the terms tomorrow, what do I lose and how quickly?
2. Can I export all the content in a format another system understands?
3. How many people will edit, with what permissions, and who approves what?
4. How many sites and languages will share this platform in three years?
5. What legal obligations apply (accessibility, data, traceability), and who is accountable?
6. What systems does it integrate with today, and which ones are coming?
7. What part of what I need is in the core, and what part depends on third parties?
8. Who will maintain this in five years, and how much talent is available to do it?
9. What will an AI agent be able to do on this platform, and who sets its limits?
10. Does the platform I am being offered solve my problem, or the vendor’s?

If the answer is still Drupal when you finish, you will know why. And if it is not, so will we.

Sources

• W3Techs, Market share of content management systems, 2026 — Drupal at around 0.7% of all websites.
• HTTP Archive, Drupal’s presence in the top 10,000 sites by traffic — between 6% and 7%.
• Directus, Why We’re Relicensing Directus (April 2023) and Changing Our License: One Year Later (2024) — move to BSL 1.1 and acknowledgement that the BSL is not an OSI-approved licence.
• Directive (EU) 2019/882 (EAA), applicable since 28 June 2025 — harmonised standard EN 301 549 v3.2.1 (WCAG 2.1 AA).