DRUPAL 8, 9, 10 & 11 · ACQUIA CERTIFIED

Drupal built to survive the developer after you.

Most Drupal problems we are asked to fix are not bugs. They are decisions. A content type that should have been three. A contrib module patched in place and never documented. Business logic buried in a preprocess function where nobody will ever look for it.

We have been building Drupal since version 6 and have watched what happens to those decisions four years later. So we build the boring way: core standards, configuration in code, custom modules that a Drupal developer who has never met us can read and extend.

Working with us as an agency? See white-label Drupal

Discuss a Drupal project See what we have built
DRUPAL, END TO END
WE BUILD
  • Custom modules and plugins
  • Twig themes and design systems
  • Multisite and multilingual
  • Views, entities and workflows
  • Headless front ends
WE ALSO RUN
  • Apache Solr search
  • Redis and Varnish caching
  • CI/CD on Acquia and Pantheon
  • Security patching
  • Performance and Core Web Vitals
What we build

Six areas, and what each one actually involves.

Drupal is broad enough that "Drupal developer" says almost nothing. This is the work we are hired for.

01

Custom modules

Bespoke functionality written to core standards, with proper dependency injection, update hooks and configuration schema so it upgrades cleanly.

  • Custom entities, fields and field formatters
  • Workflow, moderation and editorial tooling
  • Queue and cron based background processing
  • Update hooks so deployments are repeatable
02

Theming and front end

Twig themes built from a design system rather than a single mockup, so the site still looks right when an editor builds a page nobody designed.

  • Twig templates and component libraries
  • Layout Builder and paragraph based editing
  • Accessibility to WCAG AA where required
  • Headless front ends in React or Vue
03

Multisite and multilingual

One codebase serving many sites, or one site serving many languages, without the maintenance burden multiplying alongside.

  • Shared codebase with per-site configuration
  • Config split for environment differences
  • Translation workflow for content and interface
  • Domain and language negotiation
04

Integrations

Drupal rarely lives alone. Most enterprise builds spend as much effort on what Drupal talks to as on Drupal itself.

  • REST, JSON:API and GraphQL endpoints
  • CRM, marketing automation and DAM connections
  • Single sign-on with SAML or OAuth
  • Scheduled sync jobs with proper failure handling
05

Search and performance

A large Drupal site is fast or slow depending on decisions made in the data model, not on how much hardware it runs on.

  • Apache Solr with facets and tuned relevance
  • Redis object cache and Varnish page cache
  • Query and index analysis on slow pages
  • Core Web Vitals and front-end budgets
06

Hosting and DevOps

The build is only half of it. Repeatable deployment is what stops a good site degrading over the following two years.

  • CI/CD with Composer, Drush and automated checks
  • Acquia Cloud, Pantheon and AWS
  • Environment parity with DDEV locally
  • Zero-downtime release process
Honest fit

Drupal is not always the answer.

We would rather lose a Drupal project than deliver one that should have been something else. This is roughly how we advise.

Drupal is a strong fit when

  • Content structure is complex and relationships matter
  • Editorial workflow needs roles, review and permissions
  • Multiple sites or languages share one codebase
  • Integrations with internal systems are central
  • The organisation will still own this in five years

Drupal is usually the wrong fit when

  • It is a brochure site of a dozen pages
  • The team has no technical support and never will
  • The requirement is really a bespoke application
  • A store is the whole product and Shopify would do it
  • Budget covers a build but not the years after it
How we work

The unglamorous parts that decide how it ages.

Standards enforced by tooling

PHPCS with Drupal and DrupalPractice rules, PHPStan for static analysis, and a pull request template that requires the checks to pass before review.

Configuration in code

All configuration exported and version controlled, with config split where environments legitimately differ. Nothing important lives only in a database somebody has to remember to copy.

Composer and Drush all the way

Dependencies through Composer, patches declared in composer.json rather than applied by hand, and deployment through Drush so the same commands run everywhere.

Documentation for the next developer

A README that explains the architecture and the decisions, not just the install steps. Written for somebody who has never spoken to us, because eventually that is who reads it.

Questions

What clients ask about Drupal work.

Which Drupal versions do you work with?
Drupal 8, 9, 10 and 11 for new builds and ongoing work, plus Drupal 7 for migrations off it. Our founder has been working in Drupal since version 6 and is an Acquia Certified Developer for Drupal 11.
Do you build custom modules or use contrib?
Contrib first, always. A well-maintained contrib module with a security team behind it beats bespoke code that only we understand. We write custom modules when the requirement genuinely has no contrib answer, or when using one would mean bending the site around a module rather than the module around the site.
Can you do headless or decoupled Drupal?
Yes. Drupal as the content back end with a React, Vue or Next.js front end talking to it over JSON:API or GraphQL. We will also tell you honestly when decoupling adds cost without adding value, which for a content-led marketing site it often does.
Do you follow Drupal coding standards?
Yes, and we run the tooling that enforces them. PHPCS with the Drupal and DrupalPractice standards, PHPStan for static analysis, and configuration exported to code so environments stay in sync. If your team has its own standards on top of that, we use yours.
How do you handle configuration management?
Configuration is exported to code and version controlled, so deployments are repeatable and environments do not drift. For multisite or multi-environment setups we use config split so each site or environment can vary where it needs to without forking the codebase.
Can you work with our existing Drupal team?
Yes, and a good portion of our Drupal work is exactly that. We take tickets from your board, follow your branching model and submit pull requests to your review process. Nothing merges without your team seeing it.
Which hosting platforms do you work with?
Acquia Cloud, Pantheon and AWS most often, plus plain Ubuntu servers where a client already has infrastructure. We build the CI/CD pipeline with Composer and Drush so deployments do not need a maintenance window.
Do you handle Drupal security updates?
Yes, either as part of a project or on a monthly support retainer. Core and contrib security releases get applied and tested on staging first, and anything with a critical advisory is treated as same-week work rather than waiting for the next sprint.
Can you improve the performance of an existing Drupal site?
That is a common starting point. It usually begins with an audit: slow queries, missing indexes, uncached views, oversized images, render cache misses and third-party scripts. Most sites have a handful of specific causes rather than one general slowness, and the audit tells you which.
Do you work white-label for agencies on Drupal projects?
Yes. Most of our Drupal work reaches the end client under an agency brand. We work inside your repository and process, and your client never deals with us directly.
Get in touch

Tell us about the Drupal build.

Send the repository, the brief, or a description of what is not working. Within one working day you get a reply from the engineer who would run it.

Before anything is signed, you get a written technical assessment: the real scope, where the risk sits, what we would build differently and why, and a fixed price against it. It costs nothing and it is yours to keep either way.

Reply within one working day, from an engineer Free written technical assessment Fixed scope and price before you commit
Request a technical assessment WhatsApp

Related

MIGRATION Drupal migration Moving off Drupal 7, 8 and 9 without taking the site offline. WHITE LABEL White-label for agencies How we work under your brand, inside your repository and process. AI AI integration LLM features built into the platform you already run.