What Drupal Development Services Should Include

What Should Drupal Development Services Include?

Drupal development services should include 12 line items, and each one needs a deliverable you can inspect. Grouped by project stage, they are:

• Before the build: discovery and architecture, and content modeling.
• During the build: build choices, QA and testing, accessibility, security review, performance, and deployment through continuous integration and delivery (CI/CD).
• At and after launch: documentation and handover, support after launch, the upgrade path, and ownership and licensing.

A phase name with no output you can check, such as an architecture document, a test plan, or a runbook, is a statement of intent, not a scope. 

What Changes About a Drupal Proposal Written in Late 2026?

A Drupal proposal written in late 2026 has to plan for Drupal 12, which core maintainers scheduled Drupal 12.0.0 for the week of December 7. Drupal 12 upgrades only from 11.3.0 or later, because all earlier core updates were removed.

Reaching 11.3 isn't enough. The core release schedule ends security support for 11.3.x in that same week, and Drupal 10 reaches end of life on December 9, 2026. A new build should launch on 11.4 or later, or on Drupal 12. Drupal 11.4.x stays supported until April 21, 2027, so a build that launches on it needs its next upgrade planned from the start. The hosting plan should also confirm PHP 8.5, which Drupal 12 requires.

Where Are the Real Trade-Offs in a Drupal Development Proposal?

The real trade-offs in a Drupal development proposal are architecture choices that are hard to reverse. Three matter most: discovery, custom code, and test automation. Each one moves risk between you and the agency.

Should Discovery Come Before a Fixed Scope?

Discovery should come before a fixed scope when it ends in documents you keep: an architecture document, a content model, an integration list, a hosting plan, and acceptance criteria. Without discovery, a fixed bid absorbs the unknowns in the quote or in change orders.

The decisions to settle in discovery are the ones baked into data, not code, because changing them after launch means a migration rather than a refactor:

• Content model. Entity types, bundles, and field storage and cardinality. 
• Page-building approach. Paragraphs stores pages as nested entities: structured and reusable, but rigid for editors. Layout Builder stores layouts per entity or bundle: flexible for editors, but harder to reuse in other channels. Drupal Canvas builds pages from single directory components, tying content to the component library. Switching later means migrating every page. 
• Frontend architecture. A coupled Twig theme, a decoupled frontend such as Next.js, or a hybrid, plus the CSS framework underneath, such as Bootstrap or Tailwind. Canvas and Layout Builder assume Drupal renders the page; a decoupled frontend needs its own way to interpret layouts. The CSS framework ends up in templates and often in content. Switching later means rebuilding the component library and often reworking how pages are stored.
• Content separation model. Multisite isolates databases, so sharing content later is hard. Domain Access shares one database across domains, so untangling it later is hard. Group separates content by access and membership inside one site. Each choice shapes permissions, editorial workflow, and how content can be shared or split.
• Source of truth for integrations. Which system owns which data, such as the CRM, digital asset management (DAM), and single sign-on (SSO). Getting this wrong creates sync problems that never fully go away. 
  Theming details, most module choices, and build tooling can safely be decided later. 

Should a Drupal Build Use a Custom Module or a Contributed Module?

Each Drupal build choice decides who carries the maintenance. A contributed module from drupal.org is maintained by its community, while a custom module is maintained by whoever holds your support contract. 

Our default order is Drupal core, then maintained contributed modules (and Varbase, in our case), then custom code. A custom module earns its place when:

• The logic is specific to the client’s business, so no contributed module could own it.
• The contributed candidate is unmaintained, has no security advisory coverage, or has an install base so small you’d effectively maintain it alone.
• The contributed module pulls in a large dependency or configuration surface for a small need, and a few hundred lines of custom code is easier to reason about.

An approved custom module stays small, tested, documented, and written to Drupal coding standards. When a good contributed module is only missing a feature, the better move is to patch it and contribute the fix upstream, not fork it into custom code.

Drupal's security advisory policy covers only stable releases of projects whose maintainers opted in. According to The DropTimes, the Security Team marked 16 contributed projects unsupported between June 10 and August 19, 2026. 

A strong proposal lists each contributed module with its release status. To see whether an agency maintains any of them, check what a Drupal agency's contribution record tells you.

What Should Testing and Performance Targets Look Like?

Testing in a Drupal proposal should combine automated and manual work. Automated tests that cover custom code and critical user journeys catch regressions on every release, and manual testing catches what tools can’t judge, such as whether a keyboard user can finish a form. An automated scan alone isn't an accessibility deliverable.

Performance needs numbers, not adjectives. Google's Core Web Vitals set three thresholds for good performance, measured at the 75th percentile of page loads:

• Largest Contentful Paint (loading): 2.5 seconds or less.
• Interaction to Next Paint (responsiveness): 200 milliseconds or less.
• Cumulative Layout Shift (visual stability): 0.1 or less.

What Should Not Be in a Drupal Development Proposal?

Three kinds of scope don’t belong in a Drupal development proposal: rebuilding tools you already own, such as a CRM or marketing automation platform; proprietary add-ons that tie the site to one vendor; and padding, meaning scope with no output you can check. The first two add work now and dependence later.

How Do You Spot a Proprietary Add-On?

A proprietary add-on is any module, page builder, or platform layer you can't take with you when the contract ends. Warning signs include per-site licenses, code that lives only in the agency's repository, and modules hosted outside drupal.org, which the Drupal security advisory policy doesn't cover.

Ask for a module inventory that marks each item as Drupal core, a contributed module, or custom code delivered to your repository. Anything outside those three is a dependency you're buying.

Vardot's View: Score the Exit Before the Build

Our view: the best test of a Drupal development proposal is how the site leaves the agency that built it. If another team could take over the week after launch, using only what the contract delivers, the rest of the proposal was probably scoped well.

The exit test is an architecture test. A handover-ready Drupal codebase has:

• Configuration exported to code, with secrets kept out of the repository and environment-specific settings handled through config split or environment variables.
• Composer-managed dependencies with a committed lock file, no hacked core or contributed modules, and every patch documented with its reason and upstream issue. 
• Core and contributed modules on supported releases, with security updates applied at handover.
• Reproducible environments: a local setup (DDEV or similar) and a CI/CD pipeline your team can run without the original vendor.
• Automated tests that cover custom code and critical user journeys, run in CI, and come with a coverage report. What’s covered matters more than a coverage percentage.
• Documentation for the content model as well as every custom module, because a new team needs to understand the structure before the code.
• Documented results against agreed SEO, security, and accessibility checklists (for example, WCAG 2.2 AA, the OWASP Top 10, and Core Web Vitals), so you inherit a known baseline rather than unknown debt.
• Client ownership of the repository, hosting account, domain, DNS, and third-party service accounts. A client-owned repository on vendor-owned infrastructure isn’t a full handover.

None of that can be added at the end.

The exit test matters most on multisite platforms, where one codebase serves many campuses, country offices, or brands. A fix in shared code reaches every site, which is the upside. The risk sits in configuration: each site carries its own, and undocumented decisions drift site by site until no two sites behave the same way. The worst case is a copy-pasted site factory with no shared baseline, where every gap repeats, and every fix must be repeated too. The remedy is to document the shared baseline once and record each site’s deviations. 

One disclosure, so you can apply the test to us. Vardot maintains Varbase, an open-source Drupal distribution published on drupal.org. Disabling its installer leaves the site running on plain Drupal core. Hold Varbase, and the rest of our Drupal development services, to the same exit test.

How Do You Score a Drupal Development Proposal?

Score each Drupal development proposal line by line against the scorecard below. 

Drupal development proposal scorecard: 12 line items, what a strong proposal names, signs of padding, and the question to ask.

A proposal that answers every question in the last column, in writing, is one you can enforce at acceptance. Use the scorecard on every Drupal development company on your shortlist, including us. How we QA every Drupal component shows the QA and accessibility rows in practice.

Which Scorecard Lines Should Weigh Most for Your Organization?

Some lines in a Drupal proposal scorecard should be pass or fail rather than weighted, depending on your situation:

• You're replacing an incumbent agency. Handover, documentation, and ownership are pass or fail.
• You’re a US public university or a state or local government agency. Accessibility is pass or fail: under the DOJ’s extended ADA Title II dates, WCAG 2.1 AA is required by April 26, 2027, for entities serving 50,000 or more people, and by April 26, 2028, for smaller ones. 
• Your site runs Drupal 10 today. Launch version and upgrade path are pass or fail; see why Drupal 10 sites must reach 11.3 and the Drupal 10 to 11 upgrade walkthrough.
• You run many sites, such as campuses or country offices. Build choices weigh most, so ask how the proposal reuses configuration across sites.

If a proposal fails a line you marked pass or fail, ask for a revised scope before you compare anything else, including cost.

What Should You Do After Comparing Drupal Proposals?

After scoring Drupal development proposals, ask the agency that answered the most scorecard questions in writing to walk through your pass-or-fail lines before you discuss budget.

If you're comparing proposals now, see how Vardot, a Top Tier Drupal Certified Partner, structures enterprise Drupal development services from discovery through launch and hypercare.