A Drupal developer builds the parts of a site that configuration alone cannot express — custom modules, entity types, access rules, integrations and upgrade paths — and is judged by how cheap the site is to change two years later. This page describes the work as it exists on Drupal 11 today, how to tell an experienced Drupal developer from a PHP developer who has installed Drupal once, and how to hire one without guessing.
What a Drupal developer does that a general PHP developer does not
Drupal is a framework with strong opinions. Most of the work is not writing PHP; it is knowing which of Drupal's layers a requirement belongs in and staying inside that layer. A developer who ignores those opinions produces code that runs on launch day and fails at the first core update.
Three things come up on every project:
- Where the behaviour goes. A content type, a view or a display mode is cheaper than a module. A well-maintained contributed module is cheaper than custom code. Custom code is for the part of your business that is genuinely yours.
- How the data is reached. Drupal's entity layer carries access control, revisions, translation and cache invalidation. Code that goes around it loses all four silently.
- What happens at the next major version. Every shortcut is a small deferred payment, and they all come due in the same week.
The technical baseline as of Drupal 11
Version facts on this page were read from Drupal core on disk rather than recalled. The core release checked here is 11.4.6 (Drupal::VERSION, core/lib/Drupal.php).
- Minimum PHP
- 8.3.0. Core defines it as
Drupal::MINIMUM_PHPat line 117 ofcore/lib/Drupal.php, and the installer, the update runner and module installation all refuse to run below it. - Recommended PHP
- 8.4, defined as
Drupal::RECOMMENDED_PHPat line 135 of the same file. - Database
- MySQL, MariaDB, PostgreSQL or SQLite, through drivers shipped in
core/modules.
If a hosting quote or a job description still says PHP 8.1, it predates the platform it is describing. That single number is a fast way to date any Drupal advice you are reading, including advice about hiring.
Hooks are becoming classes, and plugins are becoming attributes
Two long-running changes decide how modern a codebase is. Hook implementations can now be methods on a service class carrying the #[Hook('...')] attribute — the attribute lives in core/lib/Drupal/Core/Hook/Attribute/Hook.php — which makes them injectable and testable instead of global functions.
Plugins moved the same way. In core/lib/Drupal/Core/Plugin/DefaultPluginManager.php, the constructor's fifth argument is $plugin_definition_attribute_name and the sixth is the older annotation name; core checks whether argument five is an Attribute class and only falls back to annotation discovery when it is not. A developer who can explain that difference has been reading core recently. One who cannot will be surprised by it during an upgrade.
The entity query that refuses to run
A concrete example of Drupal enforcing its own rules: an entity query with no explicit access decision throws. core/lib/Drupal/Core/Entity/Query/Sql/Query.php line 159 raises "Entity queries must explicitly set whether the query should be access checked or not." Every entity query in your codebase should carry ->accessCheck(TRUE) or a deliberate, commented FALSE. If you inherit a codebase full of raw SQL against node_field_data, that rule was being avoided rather than followed.
If you already know the answer to that one and want the engagement-level view of the same subject, the Drupal development services page covers how this work is scoped and priced.
Five interview questions that have right answers
Generic technical interviews do not separate Drupal developers well. These do, because each has a defensible answer and a revealing wrong one.
- "When would you write a custom module instead of using Views?" Good answers are about specificity and query cost, and admit that Views wins more often than developers like. A candidate who never reaches for Views will build you a maintenance bill.
- "A view changed in production and the change vanished after the next deploy. What happened?" The answer is configuration import overwriting an unexported change. If they cannot describe the export/import cycle, configuration management is not part of their workflow.
- "How do you make a block cacheable when its content depends on the current user's permissions?" Cache contexts and cache tags, not disabling the cache. "I set max-age to 0" is the wrong answer that most performance problems begin with.
- "How would you change markup that a contributed module outputs?" Template override or preprocess in the theme, or a hook — not editing the module. Editing contrib in place is the single most expensive habit in Drupal.
- "What is the oldest Drupal version you have upgraded from, and what broke?" Specific pain is the signal. Vague confidence is the risk.
The mistakes that cost real money
These are the ones that turn up in review after review, and none of them are exotic:
- Core or contributed modules edited in place. The change disappears at the next update, and nobody remembers it existed.
- Caching disabled to make a bug go away. It converts a correctness problem into a permanent hosting cost and leaves the original bug intact.
- Configuration changed in production and never exported. Guaranteed to be reverted, usually during a release.
- Modules installed by hand instead of Composer. They cannot be updated predictably and drop out of security tooling entirely.
- Access decisions made in templates. If a Twig file decides who sees a field, the data was already loaded and is often still reachable through JSON:API or a view.
Two of these are worth reading about in more depth: Drupal configuration management covers the export cycle, and blocks versus block content explains a structural mistake that duplicates content across a site.
When you need a Drupal developer, and when you do not
Plenty of Drupal work does not need one. Adding fields, building views, configuring displays and installing documented contributed modules are all reasonable for a capable in-house team. Bring in a developer when the work is one of these:
- A major version upgrade with custom modules nobody on the team wrote.
- Performance that did not improve after caching and hosting were tuned — which usually means the cause is in the code.
- An integration touching money, personal data or a compliance obligation.
- The same bug returning in different forms, which is a sign the problem is structural.
If the requirement is really about system design across several sites or services rather than one codebase, that is a Drupal architect question. If it is about templates, accessibility and front-end performance, it belongs with a Drupal themer.
What it costs
Rates vary widely by country, engagement length and how much risk the developer is absorbing, and any single number quoted on a page like this would be invented. What reliably moves the price is narrower: experience with the specific version you are upgrading from, whether the work includes taking responsibility for a launch date, and whether the codebase has been reviewed before the estimate. A fixed-scope review before an estimate almost always costs less than the variance it removes.
Common questions
Is a Drupal 7 developer qualified for Drupal 11 work?
Not automatically. Drupal 8 replaced the procedural architecture with Symfony components, dependency injection and Twig, and the changes since have continued in that direction. A Drupal 7 background is genuinely valuable for migrations, because someone has to understand the old data model — but ask what they have shipped on 9, 10 or 11.
Can one person cover development, theming and architecture?
On small and mid-sized sites, often yes, and it removes a lot of coordination cost. On enterprise programmes the roles separate because the decisions have different time horizons: a themer's decision is visible this sprint, an architect's shows up in year three.
Do I need a developer to keep a Drupal site secure?
You need someone applying security releases promptly and using Composer so advisories reach you. That is maintenance work rather than development, but it cannot be skipped: most Drupal incidents are unapplied updates, not novel exploits.
How do I check a developer's Drupal work before hiring?
Ask for a drupal.org profile and read the issue queues they participate in. Public code and public disagreement are more informative than a portfolio of screenshots, because you can see how they respond to review.
Next steps
If you are hiring, start by writing down your current Drupal version, your PHP version, how many custom modules you carry and which of them nobody understands. That list is most of a scope document, and it makes every conversation with a developer shorter.
You can see the contributed modules and themes behind the advice on this page in the portfolio, request a written estimate through request a quote, or get in touch if you would rather describe the problem first and decide afterwards.
