Government is organised by department. People are not: the case for one shared web platform
When you need something from government, you rarely know which department owns it. You know what you need: a permit, a payment, advice after a storm.
Yet a lot of government websites are still laid out the way the organisation is, because that is how digital tends to grow. One department at a time, each with its own site, its own supplier and its own way of publishing.
Victoria set out to change that. The Single Digital Presence programme aimed to bring 50 government websites onto one platform with one publishing standard, working to a principle that is still the clearest sentence we know on the subject: content belongs to the people who need it, not to the department that happens to own it.
What we built: the API layer, the multi-site engine and the testing architecture
Single Digital Presence is open source, and the record of who built what is public with it. Starting in 2017, we created most of the repositories behind the platform's Drupal(Opens in a new tab/window) layer, including its API layer, its multi-site engine and its testing architecture.
The pattern was the same across all of them. We laid the foundations before any feature work:
- the project scaffolding every repository is built from
- the continuous integration that runs on each change
- the automated tests over the behaviour that matters
- the developer workflow the teams work in day to day
The department's own team and its delivery partners then filled that structure with features. For a client, that order reads as a head start: whoever arrives next inherits a working pipeline instead of building one. The programme's technical lead credited the distribution and its testing approach from a conference stage in 2019.
In 2019 the Department of Premier and Cabinet contracted us directly, off the Victorian Government eServices Register, to write the developer documentation for the platform: how to work with the code, test an API endpoint and release a module. It shipped as a documentation site with a build that refuses to deploy if an internal link is broken.
One Drupal content system, many public websites: decoupled publishing with real preview
The heart of the platform is one Drupal content system serving many separate public websites, each with its own domain, brand, menus and homepage, all edited by agency staff in the same place. There is no separate installation per site.
A site is a piece of structured content, which makes bringing another agency on board a content decision, not a rebuild. For an agency joining later, that reads as a shorter path to launch: your site is configured on a platform that already runs, rather than procured and built again.
The public websites are rendered by a JavaScript front end, so Drupal serves content rather than pages. That split is good for performance and reuse, and it raises the question every organisation asks about decoupled publishing: how do editors preview their work when the content system renders nothing?
The platform's answer is one of the neatest we have seen, and it was not ours. The editor clicks Preview and lands on the real front end, which renders the unpublished draft exactly as the public will see it. We have carried that technique with us ever since.
Keeping a platform honest as it grows: shared testing across many repositories
The platform's Drupal code lives in many small repositories, each tested on its own. That is good for release safety and hard on consistency: every repository needs its own development environment, test harness and build pipeline, and copies of the same setup drift apart the moment nobody is watching.
We answered it in 2 pieces. The first was a shared test module giving every repository a neutral content type to write tests against, with a filter that scrubs its own fingerprints out of the site's exported configuration, so the test harness stays out of what the site ships. The second was a development toolkit that repositories fetch rather than copy: one small file each, one command surface, one place to change how everything is built and tested.
Where it got to: vic.gov.au, nearly a decade on
The platform is in service. vic.gov.au(Opens in a new tab/window) runs on it, its repositories are public and still active, and its front-end component library is published for anyone to install.
Each layer, hosting, content management and front end, was designed to be taken on its own, so another agency could adopt just the part it needed. Other Victorian agencies were building on the model within the first 2 years.
Nearly a decade after those first commits, vic.gov.au still runs on the platform.
The work outlived the engagement, and the teams who came after us could keep building on it. That is the outcome we care about most.
For governments bringing many websites onto one platform
Everything on this page is 3 of our services on one shared government platform: architecture for a multi-site Drupal system, development of the modules and the API layer behind it, and the DevOps that builds and tests every repository.
If you run a department, an agency, or a group of sites that each grew their own way, this is the shape the engagement takes: foundations first, tests and pipelines before features, and a platform layer other teams can build on. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If you are consolidating agency websites onto one publishing platform, or trying to keep a growing set of repositories consistent, tell us what your estate looks like.