A public website carries the brand, answers the audience and is edited every day by people who are not developers. It has to look right, load fast on the phones your audience actually uses, work with a keyboard and a screen reader, and often speak more than one language. Enterprise website development adds the parts a small site never meets: several markets or departments publishing on one site, editorial roles with an approval step, and links to the systems the organisation already runs. We design and build it as one piece of work, on your real content from the first prototype. Drupal is the core of what we build; we also take on websites that do not run on it.
Who this is for
- Your website is the main channel. Programmes, publications, events and news for an audience that finds you there before anywhere else.
- The site has outgrown its design. A new brand, a structure nobody can navigate, or content that is hard to find. When the content underneath is sound, that is a Drupal website redesign rather than a rebuild.
- You publish in several languages. Each language needs its own pages, menus and addresses, and a translation workflow that says who drafts, who reviews and who publishes.
- Editors publish every day. They need fields that match how they think about the content, and a site they cannot break by accident.
- Your site is not on Drupal. We take on other stacks too. Vue.js and React are tools we use for the parts of a page that behave like an application, such as a search or a booking step; they sit alongside the site rather than being a separate line of work.
What you get from a website build
- A design system: colour and type tokens, components and page templates, built from your brand
- Page templates tested on your real content, including the longest titles and the emptiest pages
- A speed budget for each page type, checked on real pages before launch
- Keyboard, screen reader and contrast checks during the build, against WCAG 2.2 AA
- A multilingual content model and translation workflow, where you publish in more than one language
- Search basics at launch: metadata, structured data, redirects and an XML sitemap
- Editorial roles and an approval workflow, with sign-in through your organisation's directory where you need it
- Editor training and documentation written for editors rather than developers
Sample Website launch checklist Signed off on staging before launch
Templates and editing
- Every template on real content Longest title and emptiest listing included
- Empty, error and not-found pages designed
- Each editorial role publishes through its approval step
Access and speed
- Keyboard-only pass through each template
- Screen reader pass against WCAG 2.2 AA
- Speed budget met on each page type Mid-range phone, mobile connection
Languages and search
- Every template checked in every language
- Redirects from old addresses tested
- XML sitemap and hreflang in place
An engineer reads it and replies within one business day.
How a website build runs
You correct something you can click rather than approve a diagram. The first working version runs on your own content, so the long titles, the empty listings and the pages nobody drew show up while they are still cheap to fix.
How a website build runs
- Discovery Audiences, content, languages and the pages that carry the work, mapped with your team. Output: the site map and wireframes
- Prototype Key templates working on your own content, before you sign, corrected until they match what you meant. Output: the prototype
- Fixed price Quoted against the agreed list of templates, components and languages. You keep the priced scope
- Build Design system, templates and content model, shown on a staging site as each part lands. You keep the repository
- Acceptance Performance, accessibility and each language checked on real pages before launch. You keep the launch checklist
- Warranty Defects in what we built are fixed by the team that built it. You keep the handover pack
Speed, accessibility and languages, built in
Most slow sites are slow because of decisions made during the build that nobody measured: images shipped at the size they were uploaded, fonts that block the first paint, third-party scripts added after launch, and pages that do database work on every request. We set a speed budget per page type and check it on real pages over a mobile connection before launch. Making an existing site faster is its own piece of work: Drupal performance optimization.
| Area | Set during the build | Checked before launch |
|---|---|---|
| Speed | Image styles, font loading, caching and a budget per page type | The speed budget for each page type, on real pages on a mid-range phone |
| Accessibility | Colour contrast, focus states, headings and form labels in the components | Keyboard-only and screen reader passes through each template, against WCAG 2.2 AA |
| Languages | Translatable fields, menus and addresses, and the translation workflow | Every template in every language, including text that runs longer than English |
| Search | Metadata, structured data, canonical addresses and hreflang | Redirects from old addresses and the XML sitemap |
Checking a site somebody else built against WCAG is a separate engagement: accessibility audit.
Websites we have designed and built
Each of these sites was designed and built by us, and each is maintained by us today. PRISMSS serves its region in English and French; the Pacific Islands Roundtable site runs conference registration; the Pacific NbS Resource Hub gives contributors member accounts; H&N Corporation brought service areas that used to sit apart onto one site.
H&N's director, on working with us:
I've had the pleasure of partnering with WeebPal for the past 5 years. They are a highly reputable international technology company, known for their professionalism, innovation, and consistent delivery of high-quality solutions. Working with WeebPal has been a truly valuable and reliable experience. I highly recommend WeebPal to anyone seeking a reliable and innovative tech partner.
What a website costs
A website is scoped from the number of distinct templates and components, the number of editorial roles and the number of languages. Page count barely matters: many pages built from a small set of templates is a small job. You see the key templates working on your own content before the price is fixed, so the quote is written against something you have clicked.
A small informational site sits in the Micro band, and reusable content types with an approval step in Small. An enterprise website usually starts at Medium, with several markets and languages and a translation workflow; it moves to Large when the site also holds rules, such as faceted search, staged approval and two-way links to your CRM or other systems of record. Many units on one platform, each with its own brand, is the Multi-Entity band, described on Drupal multisite. What each band includes is on the pricing page.
Work we have delivered
The full case studies behind the screenshots on this page.
-
Pacific Islands Roundtable
The Pacific Islands Roundtable site: a standalone Drupal build we designed and developed after a referral from SPREP, and maintain.
Read the case study -
Pacific NbS Resource Hub
The Pacific NbS Resource Hub: a Drupal knowledge platform we designed and built for SPREP from the sprep.org base, and maintain.
Read the case study -
SPREP
We redesigned sprep.org and rebuilt its Drupal theme twice, in 2017 and 2024, working directly with SPREP, and we maintain the site.
Read the case study
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
Can you build from our existing designs?
Yes. If you have a design system, we build from it. If you have page pictures with no components behind them, we turn them into a system first, because otherwise the inconsistency in the files becomes inconsistency in the code. If there is no design, our UI/UX team produces one.
Will our editors be able to break the layout?
They should not be able to. Editors assemble components rather than recreate layouts, and the fields validate what they accept. The editing side is designed as a deliverable, and the team is trained on the site it will use.
Do you build websites that are not on Drupal?
Yes. Drupal is the core of what we build, and where our depth is. We also take on sites on other stacks, and we say at the start if another platform would suit you better. Vue.js and React appear where part of a page behaves like an application; they are not a separate line of work.
How fast will the new site be?
As fast as the speed budget set for each page type during the build, and that budget is checked on real pages over a mobile connection before launch rather than hoped for afterwards. If your current site is slow and you want it fixed rather than replaced, that is its own piece of work: Drupal performance optimization.
Is accessibility included?
Yes, built to WCAG 2.2 AA rather than added afterwards. For public sector buyers it is usually a procurement requirement, and retrofitting it costs more than building it in. Checking a site somebody else built is an accessibility audit.
We publish in several languages. What changes?
The languages are decided in the content model, not added later, because retrofitting translation onto a model that assumed one language is most of a rebuild. The translation workflow and hreflang handling are set up with it; the details are in our FAQ on multilingual sites.
Not covered here? Ask us directly.
Describe the site you needAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Custom Web Application Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Headless and Decoupled Drupal
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Tell us about the site you need
Describe your audiences, the languages you publish in and who edits what. The first prototype puts your key templates on your own content, with each language and the editorial roles in place, before you are asked to sign.
An engineer reads it and replies within one business day.