Most guides on this topic treat “hiring a Drupal developer” like hiring any other contractor: post a job description, screen resumes, check references, done. That approach fails more often than it works, because it skips the one question that actually determines success: what kind of Drupal work does your project need.
Drupal is not just one skill. It is a platform with several distinct disciplines living under it, and a person who is excellent at one can be genuinely inexperienced at another. Hiring the wrong profile for your project is the single biggest reason Drupal engagements go over budget, stall, or produce a site that is difficult to use or expensive to maintain.
The stakes of getting this right are higher than Drupal’s size suggests. Estimates put Drupal’s overall share of the web at well under one percent of all websites, yet it holds roughly six to seven percent among the top 10,000 highest-traffic sites. Drupal shows up disproportionately on large, complex, high-stakes sites, which is exactly where a bad hire does the most damage.
Drupal work is not one job
Before you write a job post or call an agency, it is worth spending some time to identify which services you actually need:
Site building. Configuring content types, fields, views, and workflows using Drupal’s UI and configuration system, largely without writing custom PHP. This is the fastest-growing segment of Drupal work, especially with Drupal CMS lowering the barrier for marketing and content teams.
Backend development. Writing custom modules, working with the Entity API, building integrations, and extending Drupal’s PHP codebase. This is what most people picture when they say “Drupal developer,” and it is the hardest skill to find.
Front-end/theming. Building themes, working with the render pipeline, and increasingly pairing Drupal with a decoupled front end (React, Vue, or similar) via JSON:API or GraphQL.
DevOps and infrastructure. Managing hosting, deployment pipelines, Composer dependencies, and environment configuration. Platforms like Acquia, Pantheon, and Platform.sh each have their own conventions a developer needs to know.
Security and maintenance. Monitoring Drupal’s security advisories, applying core and contrib updates, and keeping a site patched without breaking it. This is ongoing work, not a one-time hire.
A person who’s spent four years doing site building in Drupal CMS may have never written a custom module. A backend specialist may produce an ugly, inaccessible front-end markup. Neither is a bad developer. They’re just not interchangeable, and a job post that asks for all five at a junior salary may not attract people with deep expertise.
Match the project to the hire, not the other way around
Understand what you’re actually doing before you ask who should do it.
- New build on Drupal CMS or a straightforward site, mostly site building and theming, a strong generalist or a smaller shop.
- Custom platform with integrations (CRM, ERP, membership systems, SSO), backend development is the core skill, and you need someone who can read and extend other people’s code, not just write greenfield modules.
- Migration off Drupal 7 or an old Drupal 8/9 site, migration experience specifically. Upgrading is not the same skill as building new, and a developer who has never run a real Migrate API project will underestimate the work badly.
- Ongoing maintenance and security patching for an existing site, you don’t need a builder at all. You need someone with disciplined update habits and a support/retainer relationship, not a project-based hire.
- Decoupled or headless setup, backend developer plus a front-end developer who understands the API layer between them. Treat this as two roles even if one person can nominally do both.
The four ways to hire, and what each one actually costs you
Freelance marketplaces (Upwork, Fiverr, Toptal, and similar). Lowest entry cost, widest variance in quality. Works reasonably well for a narrow, well-scoped task: fix this bug, build this one module, patch this one vulnerability. It works poorly for an open-ended build, because you’re the one who has to catch architecture mistakes, and there’s real risk of a freelancer going quiet mid-project with no one to hand off to.
Staffing or dedicated-developer shops. You get a resource, not a team. This is a good fit if you already have Drupal expertise in-house to direct the work and review output. It’s a poor fit if you’re hoping the hire will also make architectural decisions for you, because staffing models are usually priced and structured around execution, not ownership.
In-house hire. Makes sense if you have enough ongoing Drupal work to keep someone busy full time, typically a large platform or a portfolio of Drupal sites. The catch: experienced Drupal talent is a small and aging pool relative to demand. In the Drupal community’s own 2025 developer survey, respondents aged 21 to 29 fell from 59 the year before to 44, and almost none were under 21, a pipeline problem that shows up directly in how long these hires take. Add long hiring cycles and the fact that a single in-house developer is a single point of failure, and the risk compounds. If they leave, you have no one until you rehire, and handoff documentation is rarely as complete as everyone assumes.
Drupal agency or certified partner. Highest hourly rate of the four, but you’re buying a team, not a person: backend, front-end, project management, QA, and usually a security/maintenance retainer bundled in. Continuity survives any one person leaving. This is the right default for mid-size and larger organizations, or anyone whose website is business-critical enough that “the developer who understood it quit” can’t be an acceptable outcome.
There’s no universally correct answer here. A five-page nonprofit site and a multi-site university platform with SSO and a donor CRM integration have almost nothing in common, and the right hiring model follows the project, not the other way around.
What to actually test for
Generic interview questions (“tell me about a challenging project”) tell you almost nothing about Drupal competence. These do better:
“Walk me through how you’d add a new contrib module to a site.” You’re listening for Composer, not a zip file dropped into a modules folder. Anyone still describing manual file uploads as their default workflow is behind current practice.
“How do you handle configuration between your local environment, staging, and production?” You want to hear about configuration management (config sync, config split for environment-specific settings) and a clear answer for how they avoid one environment’s settings silently overwriting another’s. A vague answer here is a strong predictor of “why did the staging config just wipe out our production menu” problems later.
“How do you handle security updates, and how do you find out about them in the first place?” Look for familiarity with Drupal’s security advisory process and an actual patching cadence, not “we update when something breaks.”
“When do you reach for a contrib module versus writing something custom?” You want judgment here, not a rule. A developer who always builds custom is creating maintenance debt. A developer who bolts together ten contrib modules for something simple is creating a different kind of debt. Good answers reference tradeoffs: maintenance burden, security surface, how well-maintained the contrib option is.
“Tell me about a major version upgrade or migration you’ve run.” If your project involves moving off Drupal 7 or an older Drupal 8/9 site, this question matters more than any other on this list. Migration work has its own failure modes, and someone who has only ever built new sites will underestimate it.
“What’s your QA process before something ships?” Even a modest answer (a defined manual test pass, a staging review step) beats no answer. Automated testing (PHPUnit, Behat) is a strong signal on larger projects, but its absence isn’t automatically disqualifying for a small site.
Red flags worth taking seriously
- A portfolio that’s entirely templated, look-alike sites, with no ability to explain what was custom-built versus configured out of the box.
- No familiar answer to how they track security advisories. This is table stakes, not a nice-to-have.
- A default instinct to patch Drupal core or a contrib module directly, rather than using overrides, hooks, or a proper patch workflow. Direct core hacks are a maintenance time bomb.
- Claims broad Drupal experience but can’t explain, in plain terms, the difference between a module and a theme.
- Has never touched a major version upgrade or content migration, but your project requires one.
- Won’t commit to any post-launch maintenance or update plan. A site that’s never patched again is a security incident waiting to happen.
The 2026 landscape, briefly
Drupal 7 reached end of life in January 2025, so any developer still actively maintaining a Drupal 7 site is doing so outside official support, which raises the security stakes considerably. Drupal 9 and 8 are further behind still. If your site is on any of these, migration expertise should be a hard requirement, not a nice-to-have.
Version fragmentation across the installed base is real and worth planning around. Web technology tracker BuiltWith puts Drupal 10 at roughly 31 percent of active Drupal installs, which means most live Drupal sites today are running something older or have already moved on to 11. Don’t assume the developer you hire has necessarily worked on the version your site is actually running.
Drupal 11 is the current major version, and Drupal 10 support is winding down as Drupal 12 approaches later in 2026. Drupal CMS, the newer distribution built on Drupal 11 core, has meaningfully lowered the barrier for marketing and content teams to build and manage sites without a developer for every small change. That’s a real shift, but it changes what kind of Drupal help you need more than it removes the need for it: complex integrations, custom data models, and performance work at scale still call for an experienced backend developer, Drupal CMS or not.
On budget
Resist the urge to shop by hourly rate alone. A $35/hour freelancer who takes 200 hours and produces something that needs to be partly rebuilt costs more than a $150/hour developer who takes 40. Scope and skill match drive total cost far more than the rate on the invoice. Get a specific, written scope before comparing numbers, and be skeptical of any quote that wasn’t preceded by real questions about your actual requirements.
The short version
Define the work before you define the role. Match the hiring model to how business-critical the site is and how much Drupal judgment you already have in-house to direct the work. Vet with specific, technical questions, not general ones. And if your site is on Drupal 7 or hasn’t been patched in a while, treat that as the first problem to solve, not something to defer until after the next redesign.
Need dedicated Drupal expertise?
Connect with Alliance for custom Drupal builds, seamless platform migrations, or an embedded developer to scale your project fast.