How to assess Drupal development quality
A good Drupal site works. A very good Drupal site still works after the next security update, the next developer and the next three years.
Drupal project quality cannot be assessed from the browser. A clean design and fast loading time are visible — code structure, deployment process and technical debt are not.
Here are the indicators to ask about and look for.
Version control and deployment
What should be in place:
- Code is in Git, changes go through pull requests or at minimum through branches
- Production is not deployed to directly — there is a separate development and staging environment
- Deployment is automated or at least documented step by step
Red flag: If someone says "we uploaded via FTP" or "we made the change directly in production" — this is never a one-off incident, it is a working culture.
Automated tests
What should be in place:
- Critical user journeys are covered with Playwright or similar browser tests — login, checkout, form submission
- PHPUnit tests for business logic that does not depend on the browser
- Tests are run before every deployment
Why it matters: Without tests, every security update is a calculated risk. A module gets updated, something breaks — if the end user is the first to notice, the damage is already done.
Ask: do you have automated tests? How many user journeys are covered? When were they last run?
Composer and dependency management
Drupal 9+ projects should use Composer for managing modules and libraries. If a project was built without a Composer workflow, it typically means updates are done manually — which is slow and error-prone.
Check: is there a composer.json and composer.lock in the project? Are modules updated through Composer?
Code standards
Drupal has its own coding standards. These are not aesthetic preferences — they ensure the next developer can read the code.
Tools that should be present:
- PHP_CodeSniffer with the Drupal standard
- PHPStan for static analysis
- Ideally a CI pipeline that checks standards automatically
Module health
Drupal contrib modules need regular updates. Outdated modules are a security risk.
Check:
- How many modules have pending updates?
- Are there modules that are no longer actively maintained? (Drupal scanner checks this automatically)
- Are there custom modules depending on deprecated APIs?
Documentation
Minimum documentation that should exist:
- README with deployment instructions — how to set up the environment, how to deploy
- Comments in complex business logic modules explaining *why* something is done a certain way
- A change log for significant technical decisions
If documentation is completely absent, the project's maintainability depends entirely on the same person always being available.
What to ask before switching partners
If you are planning to change development partners or want to understand the current state of your project, ask the existing partner:
- Where is the code? Is there access to the Git repository?
- Is there a staging environment? How closely does it match production?
- Are there automated tests? Where are they?
- How was the last deployment done?
- Is there a documented deployment process?
The answers give a quick picture of the project's actual state. If the answers are vague, it is worth ordering a technical audit before the next significant piece of work.
Kaido Toomingas
WebPro Company OÜ
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.