Industry

Government Website Development on Drupal

Public websites, document libraries and staff intranets for government and intergovernmental bodies, handed over with their source code.

Talk about a public sector project Public sector case studies

An engineer reads it and replies within one business day.

  • sprep.org redesigned in 2017 and 2024
  • Library and intranet built for SPREP
  • Warranty of 1 to 3 years

Who we build this for

  • Intergovernmental organisations
  • Government agencies
  • Regional programmes
  • Public service departments

Case studies

What have we delivered for public bodies?

The work below is for the Secretariat of the Pacific Regional Environment Programme (SPREP), the regional organisation that Pacific governments and administrations set up to protect and manage the region's environment. We work with SPREP directly, every site is live, and we maintain each of them.

  • SPREP: sprep.org, the organisation's main public site, redesigned with its Drupal theme rebuilt in 2017 and again in 2024. SPREP came back to us for the second redesign, then gave us the sites developed from it.
  • SPREP Virtual Library: the digital repository for SPREP publications, reports, factsheets and media, searchable by programme, member country, project and curated collection, built as a site of its own.
  • PRISMSS: the Pacific Regional Invasive Species Management Support Service, developed from the sprep.org base, with programme work and activity outcomes reported by country, in English and French.
  • Fagogo: SPREP's staff intranet, developed from the sprep.org base, with the policies, resources and internal systems staff use every day behind a staff login.

SPREP also commissioned the Pacific NbS Resource Hub from us and introduced us to the Pacific Islands Roundtable. Both serve conservation networks, and they are described on the nonprofit and intergovernmental page.

See more of the work

What shapes the work

What makes public sector delivery different?

Government and intergovernmental work is not a harder version of commercial work. It is a different set of constraints, and the ones that matter most are usually the ones discovered late.

  • Accessibility is a requirement, not a preference.

    Public information has to work for people using screen readers, keyboard navigation and other assistive technology, and a public body is often asked to show that it does.

  • Multilingual is structural.

    Official languages and the languages members actually read are rarely the same list, and a second language decided late means a content model rebuilt late.

  • One organisation, many sites.

    A secretariat runs programmes, projects and networks that each want an address of their own. Built one at a time, they drift apart in design, in security updates and in who is allowed to edit them.

  • Publications are the record.

    Reports, policy documents, meeting papers and datasets are cited for years. A redesign that loses them, or makes them hard to find, costs the organisation its own archive.

  • Staff and the public read different copies.

    When the intranet and the public site are kept apart, nobody can say which version of a policy or a form is current.

  • Procurement asks who can maintain this afterwards.

    Many public bodies are required to show the delivered system can be maintained independently of the supplier who built it. A platform that only its vendor can operate fails that test on paper before it fails it in practice.

How we build it

How do we build for public bodies?

The approach below comes from the sites we built and maintain for SPREP, the Pacific's intergovernmental environment organisation, and the programmes around it.

  • Redesigns that keep the archive findable

    We redesigned sprep.org and rebuilt its Drupal theme in 2017 and again in 2024, for a site whose news, publications, projects and meeting documents had become hard to find. That is our website redesign work.

  • A family of sites from one base

    PRISMSS, the Pacific NbS Resource Hub and the Fagogo intranet were each developed from the sprep.org base and carry its identity, while each keeps its own address and editors. What a family of sites involves is set out on our Drupal multisite page.

  • Document libraries and knowledge hubs

    The SPREP Virtual Library catalogues publications, reports, factsheets and media by programme, member country, project and curated collection, with a submission workflow for contributors across the region: our intranet, portal and knowledge hub work.

  • Intranets for staff

    Fagogo gives SPREP staff one place, behind a staff login, for policies, templates, meeting minutes and the internal systems they use every day, with favourites they mark for themselves.

  • Accessible and multilingual

    PRISMSS serves the region in English and French. Where a public body has to show its site meets accessibility requirements, our accessibility audit tests it against WCAG 2.2 and Section 508 by criterion, with every finding and a fix estimate.

  • Applications made online

    Our nearest work to an online public service is for a private company: for H&N Corporation we built visa and passport applications made through an account, with the documents each service needs uploaded in their own fields, a status the applicant can follow, and an administration area where staff process each application.

Which of our services does this work use?

  • Drupal website redesign: a new interface and theme for a site whose content still works, as on sprep.org.
  • Drupal multisite: one base for an organisation with many units.
  • Intranets and portals: staff intranets, document libraries and resource hubs, such as Fagogo and the Virtual Library.
  • Accessibility audit: a WCAG 2.2 and Section 508 review with every finding mapped to a criterion.
  • Drupal site audit: one fixed-price review of an existing site, in a report you keep, before you decide what to change.

Why does source code ownership matter more here?

Because it is often a procurement condition rather than a preference. Every engagement ships the full repository (application code, custom modules, theme, build tooling and deployment configuration) built on Drupal and open-source infrastructure, so it runs on your servers, your cloud account or ours.

Another team can pick it up: Drupal coding standards, automated test coverage on the code we ship, and documentation written for a developer who has never met us. That is the whole argument on why you own what we build.

How are public sector programmes priced?

Large programmes are scoped, not estimated. Before any contract, and without an invoice, we produce the solution architecture, an integration map, a working prototype of the highest-risk workflows, a phased delivery plan with acceptance gates, and a risk register. Only then do we commit to a fixed price. The sizes and the milestone structure are set out on our pricing page; from the Enterprise size upward, work runs on phase gates with written acceptance criteria and hypercare under SLA.

Development work carries a warranty of one year by default and up to three, including the security releases of Drupal core and contributed modules applied while it runs, worked by the team that built the system (what the warranty covers, and what it does not). Longer-term operation is a separate support and maintenance arrangement, and migrations off older Drupal versions are handled by our Drupal migration practice.

What does a public sector engagement look like from your side?

The first phase produces documents your procurement and audit functions can read, not just code. The architecture, the integration map and the risk register exist so that the people who have to sign for the programme can see what they are signing for, and the phased plan exists so that acceptance is against written criteria rather than an opinion at the end.

During delivery, each phase gate releases against those criteria. Working software is in front of you throughout, which is how a scope conversation stays a conversation about something real. After go-live, larger programmes run a hypercare period under SLA before moving to steady-state support.

We ask early where the data is legally allowed to live and which existing systems must keep running unchanged, because both change the architecture rather than the schedule. Both are cheaper to design for than to retrofit, and both are routinely discovered late on public sector projects. Procurement questions we are asked repeatedly are answered on our FAQ page.

See it working before you commit

We build a working prototype first, so you decide against something real.

  • Full source code, handed over
  • Price fixed once the architecture is agreed
  • Warranty of 1 to 3 years
Talk about a public sector project See what it costs All sectors