In the fall of 2000, 8 students at the University of Antwerp had an internet problem.
Permanent connections were expensive and hard to get.
So 2 of them, Dries Buytaert and Hans Snijder, rigged a wireless bridge between their dorm buildings and split one ADSL modem 8 ways.
It worked.
But now they needed a place to talk to each other.
So Dries wrote a small message board where the 8 of them could post whether the network was up and where everyone was eating dinner.
That was it.
That was the whole product.
Then Dries graduated and moved out, and the group wanted to keep the site alive.
- He went to register a domain
- He wanted dorp.org — Dutch for “village”
- He typo’d it
- He got drop.org instead
Looked at it, saw it was available, and decided not to fix it.
In January 2001 he released the code behind the site as open source and named it Drupal, from druppel — Dutch for “drop.”
25 years later, that dorm message board runs Pfizer, Tesla, Harvard, the Government of Canada, and a healthy slice of the US federal government.
But here’s the part of the story that matters if you’re about to hire. Years later, Buytaert admitted what happened after he released it.
The project attracted people like him. Other developers.
In his own words, it became a system built “for developers, by developers” — and if he started over today, he said, he’d lead with user experience instead.
He built a magnet for people who love writing code. And it’s been selecting for them ever since.
Which is exactly why your last Drupal hire failed. And why every instinct you’d normally use to hire Drupal Developers works against you here.
When you hire Drupal Developers, you need to flip your screening instincts upside down: the best Drupal Developer you can hire is the one who writes the least code.
Stay with me.
I’ll prove it.
TLDR
- Drupal originated from a student project but is now pivotal for major organizations like Pfizer and Harvard.
- Hiring Drupal Developers requires a shift in mindset; prioritize those who write less code and leverage existing features.
- Identify the right role needed for your site: Site Builder, Themer, Back End Developer, or Architect before hiring.
- Be wary of Drupal’s evolving landscape; many developers self-select for complex tasks, complicating hiring due to talent scarcity.
- Evaluate candidates by real problem-solving sessions, focusing on whether they look for built-in solutions instead of coding from scratch.
Table of Contents
- Who Actually Runs Drupal in 2026
- The Door That Closed in 2015
- Why Your Last Drupal Hire Failed
- Four People Share This Job Title — Know Which One You’re Hiring
- Nobody Chooses Drupal Anymore. They Inherit It.
- What It Costs to Hire Drupal Developers
- How to Judge One Without Reading Code
- The Typo He Didn’t Fix
Who Actually Runs Drupal in 2026
First, let’s kill the question sitting in the back of your head: isn’t Drupal dead?
No.
It did something stranger. It went upmarket and left everyone else behind.
Drupal today runs 3 kinds of organizations.
1. Government
The Government of Canada.
The Australian Government, which runs an entire platform called GovCMS on it.
The European Commission and the City of London.
US federal and state agencies by the dozen.
2. Universities
Harvard, Yale, and Princeton among the Ivies, plus MIT and Oxford.
University College London runs more than 500 microsites off one Drupal dashboard.
Walk into the web office of almost any large university and you’ll find it.
3. Regulated enterprise
Pfizer, Novartis, Bayer, Cisco, Tesla, Royal Mail, Lufthansa, The Economist, and the United Nations, all confirmed against Drupal’s own published case studies.
Look at that list again.
Every organization on it has a legal department, an accessibility mandate, a security review process, and 40 departments that all need to publish content without breaking each other’s pages.
That’s the job Drupal is built for.
- Granular permissions
- Structured content at scale
- Accessibility compliance baked into the core instead of bolted on
When a public university is staring down an ADA compliance deadline, that last one isn’t a nice-to-have.
It’s the whole ballgame.
So no, Drupal isn’t dead.
It’s about 1% of the web.
But it’s the expensive 1%.
That’s who you’re competing with when you hire Drupal Developers.
The Door That Closed in 2015
Here’s what makes hiring for it so damn hard.
There used to be 2 Drupals. I know because I built sites on the first one.
In the early 2000s, I was a teenager with a small web design business — logging into HostGator and GoDaddy accounts, one-click installing Drupal and Joomla from the same cPanel menu, and building sites for my parents’ vacation rental on the Oregon coast and a couple of local service businesses.
No terminal.
No engineering degree.
A guy with an afternoon could stand up a working site and fumble his way to something respectable.
That Drupal is gone.
In 2015, Drupal 8 shipped.
Under the hood it moved to Symfony and Composer — serious, modern, object-oriented software engineering tools.
Great for the platform.
Brutal for the talent pool.
The entire generation that came up the way I did — through cheap shared hosting and one-click installs — hit a wall.
Learning Drupal now meant learning professional PHP engineering.
Most of that generation looked at the climb and walked.
They went to WordPress, or Squarespace, or out of web work entirely.
The everyman market walked too.
Drupal’s share of the CMS world fell from over 7% in 2013 to around 1% today. DrupalCon North America drew 3,014 people before the pandemic. In 2025 it drew 1,288.
So who’s left?
A smaller pool that self-selected for exactly one trait: they like hard things.
And people who like hard things like writing code. Which is why hiring Drupal Developers now is nothing like it was 10 years ago.
Hold that thought.
It’s about to cost you money.
Why Your Last Drupal Hire Failed
If you’ve tried to hire Drupal Developers before, one of these stories will sound familiar.
If you haven’t, this is a preview of what’s coming.
The developer styles your pages — and the styling only shows up when he’s logged in, because he hung everything on admin-only CSS classes.
You ask for a simple content listing page.
Drupal has a built-in tool called Views that builds these with checkboxes, in an afternoon. Instead, he spends 4 days writing a custom module that queries the database directly.
It works.
And now every future change to that page requires a developer, forever.
You ask for content categories.
Drupal has taxonomy — a core system that’s handled categories since before the iPhone existed. Instead, he invents a new content type called “category” and wires it together by hand.
He needs to change how the site looks. Instead of creating his own theme, he edits Drupal’s core theme directly.
The next platform update wipes every line of his work.
Here’s what you need to understand about these stories.
None of these developers were frauds. Every one of them could code. Some of them could code well.
That was the problem.
Remember the pool we just described — the one that self-selected for people who love engineering?
A big slice of mid-level Drupal Developers carry a quiet fear that clicking checkboxes in a CMS makes them a lesser developer.
Real engineers write code. So when your project lands on their desk, they write code.
To keep their skills sharp.
To prove something.
On your dime.
And every custom line they write to solve a problem Drupal already solved is a line you own, maintain, and pay to untangle for the rest of that site’s life.
The Best Drupal Developer Knows When Not to Code
This is why the screening instinct you’d use for any other developer backfires here.
Everyone screens for “can he build it.” Almost nobody screens for the question that decides whether this hire ruins your year: will he stop?
Given a problem, does he reach for what Drupal already ships with — or does he start building?
The one who checks first is the one you want.
When you hire Drupal Developers, the impressive answer is the expensive answer.
Four People Share This Job Title — Know Which One You’re Hiring
The second reason Drupal hires go sideways: “Drupal Developer” is one title covering 4 different humans, and the one you need depends entirely on the state of your site.
If your site mostly needs running, not building — content changes, new pages, module updates, user management — you need a Site Builder.
This person configures Drupal through its own tools and writes little to no code.
The developer-brained crowd looks down on this role.
Ignore them.
For a stable site, a good Site Builder is the highest-value, lowest-cost hire on this entire page, precisely because their whole job is using what already exists.
If your site needs to look different — a redesign, new templates, front-end work — you need a Themer.
They live in Drupal’s template layer and know how to change what visitors see without touching the machinery underneath.
If your site needs to do something Drupal doesn’t do out of the box — custom integrations, connections to your CRM or internal systems, features with no existing module — now you need a true Back End Drupal Developer.
This is a real PHP engineer who also knows Drupal’s APIs.
This is also the exact person most likely to rebuild things that didn’t need rebuilding, so the “will he stop” test matters most right here.
If your site is big, old, or about to migrate — you need an Architect, at least for a while.
This is the person who decides what happens, and then hands the work to the other 3.
Most Bad Drupal Hires Are Role Mismatches
Most bad Drupal hires are a mismatch on this list.
A Back End Developer hired to do a Site Builder’s job will manufacture engineering problems to stay interesting.
A Site Builder hired to do an integration will drown.
Neither one is going to volunteer the mismatch in the interview.
Deciding which of the 4 you need is the first real step in hiring Drupal Developers.
Which brings us to the question underneath all of this.
Nobody Chooses Drupal Anymore. They Inherit It.
Here’s the pattern behind most searches for Drupal help in 2026.
It’s almost never “we’ve decided to build our new platform on Drupal.”
It’s this: you have a site somebody else built.
The person who built it is gone — quit, retired, vanished, stopped answering email. Every change you make breaks something. And you don’t know enough about what’s under the hood to even describe the problem.
You didn’t choose Drupal.
You inherited it.
And the clock is louder than you may realize.
Drupal 7 — the version a huge share of these inherited sites still run — hit end of life on January 5, 2025.
No more security patches.
Paid extended support exists, and it runs out in January 2027. Even Drupal 10 loses support in December 2026.
The exodus is already visible.
One tracking dataset watched active Drupal sites peak at 91,762 domains in December 2024 — and fall to 72,746 by July 2025. Roughly 21% of the surviving Drupal web, gone in 7 months.
Those are site owners who looked at the cost of migrating and chose to leave the platform instead.
So before you hire anyone, answer one question.
Are you maintaining this site, migrating it to modern Drupal, or leaving Drupal entirely?
Those are 3 different projects needing 3 different people from the list above.
Hiring before you’ve made that call is the single most expensive mistake available to you here.
You’ll pay a developer to keep a site alive that you were going to leave anyway, or pay a Site Builder’s salary to someone facing a migration he can’t perform.
Decide first, then hire Drupal Developers against that decision.
What It Costs to Hire Drupal Developers
Now the numbers.
A full-time Drupal Developer in the US averages around $93,000 a year, with a typical range of $85,000 to $140,000 depending on seniority.
US freelancers cluster around $44 to $62 an hour.
Agency rates run $150 to $175 an hour for a solid North American shop, $40 to $60 in Europe, and as low as $25 in the cheapest offshore markets — where, as anyone who’s tried it will tell you, you get exactly what you pay for.
But the price isn’t the real problem.
The supply is.
We recruit developers across Eastern Europe, Latin America, and Asia — 1,100+ placements across 35 countries — and Drupal is one of the thinnest specialties we’ve seen anywhere.
On Ukraine’s main tech job board, a market overflowing with PHP and JavaScript talent, open Drupal roles sit at effectively zero.
This isn’t a post-the-job-and-wait market in the US, and it isn’t one offshore either.
Which changes the math when you hire Drupal Developers from a pool this thin.
When talent is this scarce, the cost of picking wrong isn’t just a bad salary spent.
It’s months of runway gone, because the replacement search starts from the same empty pool.
The comp structure that attracts the right person here — and the markets where real Drupal experience actually hides — is exactly what we work through on a discovery call, because it depends on which of the four roles you need and which of the three paths your site is on.
How to Judge One Without Reading Code
You can’t read code.
Fine.
These are the 3 signals people actually use to hire Drupal Developers, and where each one cracks.
1. The drupal.org profile
Drupal is built by its community, and every contributor has a public track record — modules maintained, problems solved, patches submitted.
Half the community will tell you this is the only evidence that matters: if there’s no public trail, there’s no reason to believe the resume.
The other half points out, fairly, that plenty of strong developers have a full-time job and a family and no time to volunteer.
A strong profile is real signal.
An empty one isn’t proof of anything.
The closest thing Drupal has to a standardized credential — an actual exam, run by the company Buytaert co-founded.
It filters out the worst of the “generic web dev with Drupal on the resume” crowd.
It also costs money, and a loud chunk of the community dismisses it as a tax on people who’d rather prove themselves through work.
3. Watching them work
The only test that reliably catches the failure mode from earlier is putting a real, small Drupal problem in front of a candidate and watching what they reach for first.
The right hire checks whether Drupal or its module ecosystem already solves it.
The wrong one opens an editor and starts typing.
You cannot see this on a resume, and you will not surface it by asking.
It only shows up live.
Designing that test — what to ask, what a pass looks like, how to run it when you can’t evaluate the code yourself — is the hard part, and it’s the part we handle.
That’s the call to book.
The Typo He Didn’t Fix
One more time, back to Antwerp.
Dries Buytaert typed “drop” when he meant “dorp,” looked at the mistake, saw that it worked, and left it alone.
A quarter century later, the name is on software running governments and universities on 4 continents.
That instinct — look at the thing that’s working and don’t touch it — is the exact instinct you’re hiring for.
The developer pool that Drupal built over 25 years is full of talented people who can’t leave working things alone.
The scarce ones, the ones worth the search, are the ones who look at what’s already built, confirm it works, and move on to the problem that actually needs them.
Find the one who writes the least code.
Or book a discovery call and we’ll find him for you.
