Skip to content

Drupal

How to Choose a Drupal Development Company (Without Getting Burned)

· 4 min read

A fair share of our Drupal work is rescue work: a site half-built by another vendor, a migration that stalled at 80%, a codebase no one left behind documentation for. Which means we’ve seen, in forensic detail, how choosing the wrong Drupal development company plays out.

The frustrating part? The warning signs were almost always visible before the contract was signed. So here’s the vetting checklist we’d use if we were hiring a Drupal development firm ourselves — including the questions that make weak agencies squirm.

1. Ask who, specifically, writes the code

“We have 200 developers” tells you nothing. The question that matters: who will be in my repository, and how many years of Drupal — not generic PHP — do they have? Drupal is its own discipline. Its hook system, its render pipeline, its configuration management, the judgment call of contrib-module-vs-custom-code — these take years to develop taste for. An agency staffing your project with juniors “supervised by a senior” is billing you senior rates for a training program.

What to listen for: named people, real Drupal tenure, and drupal.org profiles with actual contribution history.

2. Make them show you a migration, not a brochure

Anyone can build a fresh Drupal 11 site on a clean database. The skill ceiling shows in migrations — legacy content, custom modules with no tests, URL structures that must survive. Ask for a specific example: what version, how many pages, what broke, what happened to organic traffic in the 90 days after launch. A team of genuine Drupal migration experts will answer with specifics and at least one honest war story. A brochure agency will change the subject.

3. Ask where SEO lives

This is the question that eliminates the most agencies, and the reason it’s on this list is blunt: most Drupal shops treat search as someone else’s job. They build the site, then “recommend an SEO partner” — at which point the partner discovers the URL structure is wrong, the metadata layer is missing, and the JavaScript rendering hides half the content from crawlers. Retrofitting SEO into a finished build costs multiples of doing it during the build.

Ask directly: is SEO in-house or referred out? Who configures Pathauto, Metatag, and Schema markup, and in which sprint? If the answer involves the word “partner,” price in a second project. (This is, transparently, why we run an SEO practice inside the same team as our Drupal engineering — the two disciplines belong in one room.)

4. Demand a fixed price for scoped work

Open-ended hourly billing on a well-scoped project transfers all the risk to you. A confident agency will audit first, then commit to a number. Hourly has its place — genuine R&D, exploratory rescue work — but “we bill hourly for everything” usually translates to “our estimates don’t survive contact with reality.”

5. Check the security posture

Drupal’s enterprise reputation rests on its security process, but that only helps if your agency actually applies patches. Ask: what happens when a critical security advisory drops on a Friday? The right answer names a process — advisory monitoring, an SLA measured in hours, a staging pipeline that lets patches ship same-day. “We apply updates during monthly maintenance windows” means your site sits exposed for up to thirty days at a time.

6. Location matters less than overlap

Searching for a “Drupal development company USA” makes sense — but what you actually need is timezone overlap, communication quality, and accountability, not a specific zip code. We work remote-first with clients in Denver, Minneapolis, Los Angeles, and Virginia; the teams that succeed with us aren’t the ones nearest our desks, they’re the ones we talk to every day. Whether you outsource Drupal development entirely or embed external specialists into your own team, insist on: daily overlap with your business hours, a senior point of contact (not an account manager relay), and response times measured in minutes on Slack.

7. Read the off-boarding terms before you sign

The quiet test of an agency’s confidence is how easy they make it to leave. Your code should live in your repository from day one. Hosting on your accounts. Documentation written as they go, not ransomed at the end. Any vendor who holds infrastructure hostage is telling you how the relationship ends — believe them.

The shortlist test

Once you’re down to two or three candidates, give each the same small paid discovery task — an audit of your current site, for instance — and compare what comes back. One report will be a template with your logo on it. Another will name specific modules, specific risks, and specific numbers. That difference is the difference, and it costs you a week to learn.

If you’d like to see how we’d handle that test, request a free audit — or read about how our Drupal development services are structured, including the comparison table we publish against typical agency practice. We wrote it to be held accountable to.