Build

Custom Drupal Development

Custom modules, content architecture and integrations for Drupal systems that have outgrown a simple CMS, including builds another team left unfinished.

Describe your platform See what it costs

An engineer reads it and replies within one business day.

  • Content architecture, documented
  • Modules and integrations, with tests
  • Source code yours from the first commit

Drupal earns its place when content is structured, permissions are granular and other systems read and write through it. Those are also the places a Drupal build goes wrong: a content model drawn from page designs, modules added without a plan, integrations left until the end. We design the entity model first and prove it on your own content, then write the custom modules and integrations it needs. We also take over Drupal builds that another team left half done.

SPREP Virtual Library catalogue search with the latest publications, built on DrupalView full size
SPREP Virtual Library SPREP's digital repository: publications searchable by programme, member country and project, and a submission workflow for registered contributors. Designed, built and maintained by us. Read the Virtual Library case study

Who this is for

  • Your content has outgrown a page builder. The same records appear in several sections, several languages or several audiences, and copying them by hand has stopped working.
  • Different people need different rights. Contributors draft, reviewers approve, publishers publish, and some content is visible only to members or staff.
  • Other systems depend on the site. Payments, a CRM, a learning platform or a records system has to exchange data with Drupal reliably, in one or both directions.
  • A Drupal build has stalled. Another team left it half done. We read the code and the configuration first, then tell you what can be kept and what has to be rebuilt.
  • You are an agency with Drupal work to place. The same engineering, delivered under your name: see white-label Drupal development.

What you get from a custom Drupal build

  • The entity and content architecture, documented: content types, fields, taxonomies, media and editorial roles
  • Custom modules written to Drupal coding standards, with automated tests
  • The integrations named in the agreed architecture, each with its failure behaviour defined
  • An editorial workflow your editors tried on their own content before it was built
  • Build tooling and deployment configuration in your repository
  • Editor training and handover documentation written for the people who will run it

Sample Content model Resource library on Drupal 11

Publication Content type

  • title Text
  • field_summary Plain text, 300 characters
  • field_document Media: document
  • field_topics Topic
  • field_country Country

Topic Taxonomy

  • name Text
  • parent Topic hierarchy
  • field_description Formatted text

Country Taxonomy

  • name Text
  • field_iso_code Two-letter code
  • field_region Region

Editorial roles

  • Contributor Creates drafts and uploads documents
  • Reviewer Approves a draft or returns it with notes
  • Publisher Publishes, unpublishes and archives
Describe your platform

An engineer reads it and replies within one business day.

How a custom Drupal build runs

The content model is where Drupal projects are won or lost, so it is the first thing you see running. Moving a field between content types costs little while the model is a prototype, and a great deal once templates, migrations and integrations sit on top of it.

How a custom Drupal build runs

  1. Discovery Content, roles, workflows and the systems Drupal has to talk to, analysed into a first entity model. Output: the requirements and the model
  2. Prototype The model running on a sample of your real content, before you sign, for your editors to try and correct. Output: the prototype
  3. Fixed price Quoted against the architecture and the integration list once the model holds, not against the brief. You keep the architecture document
  4. Build Custom modules, theme and integrations, shown working on a staging site as each part lands. You keep the repository
  5. Acceptance Tested against the agreed scope, with your editors working in it before launch. You keep the test record
  6. Warranty Defects in what we built are fixed by the team that built it. You keep the handover pack

Integrations and custom modules

Drupal is API-first: JSON:API and REST in core, GraphQL through a contributed module. We have connected it to payment providers including PayPal and Stripe, to Zoom, H5P and SCORM for learning, to CRM and marketing platforms, and to older business systems through whatever interface they offer. Reading from a system of record is usually straightforward. Writing back to one means deciding which system wins when the two disagree and what happens when a call fails halfway, and that is agreed in writing before the price is fixed.

Most requirements are configuration or a contributed module that thousands of sites already run. We write a custom module when the behaviour is specific to your organisation, when an integration speaks a protocol nothing else speaks, or when patching a contributed module would cost more than owning the code. When the job is the module itself, such as a contributed module stuck on an older Drupal version or left without a maintainer, we port or patch a contributed module as a piece of work on its own. The modules we maintain in public are on our open-source page: WE Mega Menu has a release for Drupal 10.3, 11 and 12, and Component Builder has one for Drupal 10 and 11.

Drupal release and support dates

  1. Drupal 7 End of life Community support ended on 5 January 2025.
  2. Drupal 10 Ending Security support ends on 9 December 2026.
  3. Drupal 11 Current The version a new build starts on today.
  4. Drupal 12 Next Stable release planned for the week of 7 December 2026.

Since Drupal 8, moving between major versions is an upgrade rather than a rebuild, as long as the code avoids deprecated APIs. We keep custom code off them and the list of contributed modules short, so the move to Drupal 12 is routine work. A site already on an older version is a different job: Drupal 10 to 11 and 12 upgrade or Drupal 7 and legacy CMS migration.

Where Drupal builds go wrong, and what we do instead

Early decisions that decide a Drupal build
DecisionWhat goes wrongWhat we do instead
Content modelDrawn from the page designs: one content type per layout, fields named after where they sit on screenModelled on what the content is, so one record can appear in many places and languages
Contributed modulesInstalled to solve problems nobody defined, each one more code to update at the next major versionA short list, each module tied to a requirement in the architecture document
Editor interfaceLeft until last, so the people who use it daily get whatever the build producedTried by your editors in the prototype, before anything is committed
Custom codeWritten where configuration would do, and the first thing to break on upgradeWritten only when configuration cannot do the job, to coding standards and off deprecated APIs
TestsNone, so nobody dares change anything after launchAutomated tests on the code we ship, handed over with it

Drupal systems we have built

Each of these was designed and built by us on Drupal, and each is maintained by us today: a document repository with a contributor workflow, shown above; a staff intranet built from the base of an existing site; and a training portal customised from our own learning platform.

Fagogo intranet shortcut cards to internal tools such as the records system, virtual library and project databaseView full size
Fagogo SPREP's staff intranet, built from the base of the SPREP site. Read the Fagogo case study
JFC training portal course catalogue built on EverLMSView full size
JFC A training portal built from EverLMS and customised for JFC. Read the JFC case study

SPREP has since asked us to build more sites from the base of sprep.org, among them the Pacific NbS Resource Hub, a resource library with member accounts. Its project manager on the SPREP side:

The Weebpal team are awesome and easy to work with. They have made the design and development of the "Pacific NbS Resource Hub" a breeze and they are quick, efficient and I am really happy with the quality of their work and I highly recommend them.

Ms Utulei Lui, Project Manager, PPIN project, SPREP More client reviews

What custom Drupal development costs

The price is fixed, but not from the brief. It is quoted once the content model has run on your real content and the integration list is agreed, so the usual sources of overrun are already counted. What moves a build between bands is the number of distinct content types, the number of integrations that have to hold, and how many editorial roles need different permissions, not the number of pages.

Reusable content types with an approval step sit in the Small band; several languages with a translation workflow, in Medium; search, staged approval and two-way traffic with your systems of record, in Large. The bands and what each includes are on the pricing page.

Work we have delivered

Terms that hold

These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.

  • A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
  • You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
  • A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
  • Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.

Questions we get asked

What does the prototype of a Drupal build contain?

A running Drupal site with your entity model in it: content types, fields, taxonomies, roles and the editorial workflow, filled with a sample of your real content rather than placeholder text. Your editors log in and try to do their actual job in it. It is built before any contract, at no charge, and what comes back from it is usually a change to the model, which is the point: moving a field costs little at this stage.

How do you decide what becomes a custom module?

The default is not to write one. Most requirements are configuration, or a contributed module that somebody else maintains. A custom module is the right answer when the behaviour is specific to your organisation, when an integration has to speak a protocol nothing else speaks, or when a contributed module would need so many patches that owning the code is cheaper. When we write one, it follows Drupal coding standards, ships with tests and keeps business logic out of the theme.

Can you finish a Drupal build that another team started?

Yes. We start by reading what is there: the custom modules, whether the configuration is in the repository, the patches applied to core and contributed modules, and whether the code matches what runs on the server. You then get a written view of what can be kept, what has to be rebuilt and what finishing it costs, before any build work starts.

What is in scope, and what is not?

In scope: the content architecture, custom modules, the theme, the integrations named in the agreed architecture, automated tests on the code we write, editor training and handover documentation. Not in scope unless it is written in: content entry, content migration from an existing system (separate work with its own audit), third-party licences and hosting costs, and changes to scope after the price is fixed, which are quoted as changes rather than absorbed. Being explicit about the second list before signing is what stops the first one being argued about later.

Which Drupal version will you build on?

Drupal 11, the version with security support today. Drupal 12 is planned for the week of 7 December 2026, and code kept off deprecated APIs moves to it as a routine upgrade. If your site is on Drupal 10 now, see the upgrade page.

Can a custom module be released on drupal.org?

Only if you agree: the code is yours. We write custom modules as though they could be contributed back, which mostly means keeping your organisation's rules in configuration rather than in code. If a module turns out to be useful beyond your site and you want it released, we can maintain it there with you.

Not covered here? Ask us directly.

Describe your platform

An engineer reads it and replies within one business day.

Build

Further reading

Tell us what your content actually looks like

Describe the content types, the roles and the systems it has to talk to. We will tell you whether Drupal is the right answer before quoting anything, including when it is not.

Describe your platform See what it costs

An engineer reads it and replies within one business day.