How to evaluate a Drupal developer's competence
🎧 Listen to every article back to back
When you hire a Drupal developer or change maintenance partner, do not ask only for a portfolio. Ask how they keep the system upgradable, testable and understandable for the next developer.
In 2026, it is no longer enough to evaluate a Drupal developer simply by knowing that they have "worked with Drupal".
Drupal is a broad enough platform that the same job title can cover very different types of work:
- configuring content types and Views;
- developing custom modules;
- migrations;
- performance optimisation;
- security updates;
- accessibility;
- integrations with external systems.
A good developer does not need to be equally strong in every area. They should, however, be able to assess realistically where their strengths lie, where they need support, and how to keep risks under control throughout the project.
Start by defining the expertise you actually need
You cannot assess a Drupal developer's competence without context.
A small content-page change and the migration of a multilingual portal require very different skill sets. Before evaluating a developer, define whether you primarily need:
- maintenance and security updates;
- development of new functionality;
- custom module development;
- a Drupal version upgrade or migration;
- e-commerce or payment solution development;
- performance and caching analysis;
- support with WCAG compliance and accessibility;
- takeover of a project from another developer.
If your requirements are not yet clear, look for a developer who starts by assessing the current situation rather than immediately providing a quote. For a complex existing website, it often makes sense to begin with a technical audit rather than a large development project.
A competent developer asks uncomfortably specific questions
A developer promising to get everything done quickly is not necessarily a good sign.
A better sign is when they ask questions before starting work:
- Which Drupal version is currently in use?
- Does the project use Composer?
- Where is the Git repository hosted?
- Is the configuration exported to code?
- Is there a staging environment?
- How are deployments handled?
- Are there any known broken integrations?
- Who has authority to make decisions about content, design, and user permissions?
These questions show that the developer is considering the state of the system as a whole. If the answers are not available, the next step should be a technical review rather than starting development blindly.
Pay attention to how they talk about risks
A weak answer usually sounds like this:
> "It's simple. We'll get it done."
A stronger answer explains the conditions:
> "If the staging environment matches production and we have the necessary access, this is a small change. If the configuration exists only in the database, we first need to check what the deployment might overwrite."
In Drupal development, risks are often hidden in places that are not immediately obvious:
- a contributed module may no longer be maintained;
- custom code may rely on deprecated APIs;
- caching may hide an error until the cache is cleared;
- a permissions change may expose content to the wrong user role;
- configuration changed directly in the database may disappear during the next deployment.
A competent developer does not exaggerate these risks, but they should be able to identify them and explain how they will be mitigated.
The work must be traceable
Traceability means being able to determine afterwards:
- what was changed;
- when it was changed;
- who made the change;
- why the change was made.
It is a good sign when a developer uses:
- Git version control;
- a task or issue tracking system;
- short and clear commit messages;
- a documented deployment process;
- pull requests and code reviews where appropriate.
If all work is performed directly on the production server and there is no history of changes, the problem is not merely one of convenience or workflow. It becomes difficult to determine what changed, why it changed, and how to restore a previous working state if necessary.
Composer and configuration management are not optional extras
A modern Drupal project should use Composer to manage dependencies and Git to track changes to the codebase.
Composer helps manage:
- Drupal core;
- modules;
- PHP libraries;
- version constraints and dependencies.
Drupal configuration should at minimum be exportable and managed systematically. If important parts of the website's configuration exist only in the production database, changing development partners and deploying changes safely become significantly more difficult.
If modules are manually uploaded to the server via FTP, consider it a warning sign. This approach makes updates, audits, and rollbacks less reliable.
A staging environment must be part of the development process
Every significant change should pass through a staging environment before reaching the public website.
This is particularly important for:
- security updates;
- module updates;
- forms;
- integrations;
- payment solutions;
- changes to user roles and permissions.
If a developer makes changes directly on the live website, the risk of users encountering broken or incorrectly functioning features increases.
Ask:
- Does the project have a staging environment?
- How are changes deployed to staging?
- Who reviews the changes before they are released?
- How is the previous working version restored if something goes wrong?
For more complex projects, it is also worth asking about automated testing. Not every View or feature needs to be covered by automated tests, but critical user journeys should be testable. These may include forms, the shopping cart, login, payments, permissions, and important integrations. WebPro uses automated testing, among other methods, for this purpose.
Security updates should not depend on the client reminding the developer
A good Drupal developer monitors security advisories and applies necessary updates according to an agreed process.
Ask:
- When were security updates last applied?
- Are updates tested before being deployed to production?
- Who decides when a critical update is installed?
- How is the client informed about necessary updates and completed work?
If security updates are performed only when the client specifically asks for them, this is not systematic maintenance.
The official source for Drupal security information is Drupal.org security advisories (opens in a new tab). A developer does not need to relay every advisory to the client, but they should be able to explain how security advisories are monitored and how critical updates reach the production environment.
The codebase should be transferable to another developer
A good developer does not create a situation in which they are the only person capable of maintaining the system.
A transferable project should include at least:
- the source code;
- Git history;
- Composer files;
- the necessary access credentials;
- documentation;
- information about important integrations.
If changing development partners seems impossible or unreasonably expensive, the system may be too dependent on a single developer or service provider.
A portfolio is useful, but it is not enough
A portfolio shows which projects a developer has worked on. It does not necessarily show what they were actually responsible for.
Ask more specific questions about a previous project:
- What was the developer responsible for?
- What was the most difficult technical decision?
- How were deployments handled?
- How was the solution tested?
- What would they do differently if they were building the same project today?
An answer such as "I did all the Drupal work" does not tell you much. A more useful answer describes specific problems, trade-offs, the reasoning behind key decisions, and lessons learned from the project.
Red flags
Some signs may indicate that the development process is not sufficiently mature.
"Everything is fine. There's nothing to worry about."
Without concrete information, such reassurance means very little.
Ask:
- Which Drupal version is running?
- When was the system last updated?
- Which modules are critical?
- Is the PHP version still supported?
Changes are made directly in the database
Drupal configuration should be manageable and exportable when necessary.
If configuration changes exist only in the database, the next deployment may overwrite them. It also becomes more difficult to determine which configuration is correct and which changes have been made in different environments.
Technical audits are avoided
A good development partner should not be afraid of an independent technical audit.
An audit is not an accusation. It is a way to verify whether the system is secure, maintainable, and upgradable, and to identify technical risks that require attention.
Every month brings another crisis
If almost every change turns into an urgent fix, the underlying problem is probably in the development process rather than in isolated bugs.
A high-quality development process reduces the likelihood of recurring crises instead of creating new ones.
Practical checklist
Ask your developer or development partner:
- Which Drupal version is currently in use?
- When does official support for that version end?
- How are security updates handled?
- Does the project use Composer?
- Where is the Git repository hosted?
- Does the client have access to the source code and repository?
- Does the project have a staging environment?
- Are automated tests used?
- How are backups created, and is their recoverability tested?
- What happens to the project and access rights if the partnership ends?
- Which modules are critical to the project?
- How is custom logic documented?
If you cannot get clear answers to these questions, it is worth investigating the project's technical condition more closely.
When should you commission an independent audit?
An independent audit makes sense when:
- you are planning to change development partners;
- the website has not been systematically maintained for several years;
- updates are becoming increasingly complex and expensive;
- you do not have a clear overview of the system's technical condition;
- your development partner gives vague answers to technical questions.
An audit can provide an overview of:
- the status of security updates;
- module versions and maintainability;
- the quality of custom code;
- performance issues;
- accessibility risks;
- the overall maintainability of the system.
Summary
A good Drupal developer does more than build what users see on the website.
They leave behind a system that is:
- traceable;
- testable;
- upgradable;
- documented;
- transferable to another developer when necessary.
Clients may not be able to see technical quality directly, but they can evaluate it through the development process. Git, Composer, a staging environment, a systematic security update process, automated testing, and a clear handover process are all signs that a developer is thinking not only about solving today's task but also about the long-term health of the web platform.
If you want to understand the actual condition of an existing Drupal website, a technical audit can provide an independent assessment before you make larger decisions.
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.