Federal government

When the design system is already decided: a fixed identity and a fixed date

If you are standing up a public website inside a government identity, most of the visual decisions were made before your project started. The typography, the colour, the header, the footer and the accessibility bar all arrive as a standard you have to meet, and the launch date is usually set at the same time.

What is left to decide is how the site gets built. Which components exist, what each one is worth, and where the effort actually sits. That last question is where the cost hides, because the effort rarely lands where people expect it to.

How we came into the work: Drupal build partner behind a Canberra agency

In 2024 a Canberra digital agency working across Australian federal government brought us in as their Drupal(Opens in a new tab/window) build partner on a public website for a Defence portfolio agency. Their team carried the client relationship, the design and the delivery management. We provided the estimating and the Drupal engineering behind it, front end and back end.

That split works well for both sides. The agency keeps its client relationship whole and keeps owning the work it does best, while the build capability sits behind it without the client having to manage 2 conversations.

Mapping the build feature by feature: 2 figures on every line

Before any code, we mapped the site feature by feature and costed every line twice, once for the back end and once for the front end. Header, footer, banners, breadcrumbs, side navigation, the landing page system, news, search and the content migration all sat on one sheet with 2 figures each.

3 useful things fall out of an estimate shaped that way:

• the front end carries most of the cost, roughly 60 percent of the total on this build, which is the reverse of what most people assume
• accessibility gets a price, with skip-to-main-content and the Acknowledgement of Country appearing as their own costed lines rather than being folded into other features
• contingency stays in the open, sitting beside the base figure as its own line, which makes it something to discuss rather than something to absorb

Mobile navigation alone was an order of magnitude heavier on the front end than on the back. If a design-system site has ever felt more expensive than it looked, that ratio is why.

Naming the accessibility lines makes them visible, and visible things are harder to drop quietly when a number has to come down. For a client, that reads as a priced map rather than a single number: you can see what each component is worth before anyone commits to it.

What we built: a landing page system, news, search and a content migration

The site carries the full set of parts a public government site needs:

• a landing page system with sliders, embedded frames, and card lists that either assemble themselves from published content or are curated by hand
• news with authors, related links and its own search
• a results page for site-wide search
• content pages carrying resources and related links alongside the body

Underneath that sits the furniture a government site lives on: static and video banners, breadcrumbs, side navigation, a back-to-top control, a skip link, an Acknowledgement of Country in the footer, and content styling for typography, quotes, tables and icons. The existing content came across through a manual migration.

The engagement did not stop at the build. Feature work continued into 2025, a year on from the original build. For an agency partner, that reads as continuity: the team that built the components is the team that extends them.

What we kept from it: the dual estimate for component-heavy builds

The dual estimate is now how we cost component-heavy builds. One sheet, 2 figures per feature, accessibility priced on its own line, contingency stated separately.

On this build, roughly 60 percent of the estimate sat in the front end, the reverse of what most people assume.

It gives a client something more useful than a blended number: a picture of where the money actually goes, and 2 halves that can be sequenced, resourced or trimmed independently of each other. For an agency partner, it is also a far easier conversation to have with an end client than a lump sum.

For teams building inside a design system they did not choose

Everything on this page is 2 of our services on one government website build: Drupal development across the front end and the back end, to an identity that was already set, and a manual migration of the existing content. The feature-by-feature estimate sat in front of both.

If you are a digital agency carrying a government client, or a team standing up a public site inside a design system you did not choose, this is the shape the engagement takes: a build partner behind your own team, an estimate that prices every component twice, and accessibility and contingency named as their own lines. The same engineering is available with AI-assisted delivery where it suits the work.

If you are pricing a design-system build and want to know where the effort will actually land, send us the component list.

When the website is the public record: a federal publication estate

Some organisations have a website because they need one. Others have a website because it is the record. If your work is to give public advice, the site is where that advice gets published, cited, downloaded and checked again years later, long after the news cycle that produced it has moved on.

The organisation here is an independent federal statutory body that advises government on national policy. Its website carries:

• annual reports
• corporate plans
• strategic frameworks
• the outcomes of its meetings
• public submissions filed by industry and community organisations

The people who come looking are usually after a specific document.

That is a publication estate, not a brochure site. It sets a different bar: findable, readable, accessible, and stable for a very long time.

Our part in the work: a CivicTheme migration in 2023

We were brought in for a single job: to move the site onto CivicTheme(Opens in a new tab/window), the Australian government design system. We help build and maintain CivicTheme itself, so this was familiar ground. A migration onto a design system tends to go faster when the people doing it know why each component is shaped the way it is.

It was a short and precise engagement in 2023. Across it we:

• built the site's CivicTheme sub-theme and the configuration around it
• set up the front-end build and the component workflow the theme depends on
• added the local tooling the next developer would reach for
• handed the platform back

The organisation's own team and its partners have carried the site forward since, which is how a migration should end.

Theme and configuration only: building where the platform allows no custom code

The site runs on a shared government hosting platform. There are no custom modules on that platform, and there structurally cannot be. Core, the distribution and the contributed modules all arrive in the platform image, and an automated check refuses a deployment if anything unexpected turns up in it.

That sounds like a limit on what you can build. It is really a limit on how. Everything we delivered lives in the theme and in configuration, and that turns out to be a discipline rather than a compromise:

• no bespoke module to maintain
• no bespoke upgrade path to plan around
• a platform free to keep the software underneath the site patched

For a client, that reads as fewer things to own: what we hand back is a theme and a set of configuration, not a codebase somebody has to keep alive.

Constraints like these reward knowing the platform well. The front-end build had to fit a host that runs no build step of its own, and the platform's own code checks had to pass cleanly on files that nobody writes by hand. Both are the kind of problem you solve once and then stop paying for.

What a design system actually buys you: a stock content model

The site uses CivicTheme's content model exactly as it comes: no bespoke content types, no bespoke fields.

That is easy to skim past, and it is the whole cost argument for design systems. Every custom field is something a person has to understand, document, test and carry through the next upgrade, indefinitely.

A federal publication estate needed none of them, because the design system already covered the job. What is left to look after is a thin layer of styling on top of a library that other people keep improving. For a client, that reads as a maintenance bill that stops growing: the fields nobody built are the fields nobody has to test, document or upgrade.

Accessibility works the same way. In a design system it is a property of the shared components, maintained once for everyone who uses them, rather than a line item in each agency's budget.

Where it landed: live on CivicTheme, carried on by the organisation's own team

The site is live and runs CivicTheme.

A federal publication estate rebuilt on a shared design system, with no bespoke content types and no bespoke fields.

Our part was brief and deliberately so. A migration done well ends with a client who no longer needs the specialists, and that is what happened here: development continued in the hands of the organisation's team and its partners.

The design system underneath is still maintained and still improving, and the site inherits that work without commissioning any of it.

For government sites that have to stay findable for years

Everything on this page is 2 of our services on one federal publication estate: a migration onto a government design system, and the development that makes that design system fit a hosting platform which allows no custom code.

If you run a site whose value is the documents on it, an agency, a statutory body or a regulator, this is the shape the engagement takes: a short bounded migration, everything delivered in theme and configuration, and a handover to the team who will run it afterwards. The same work is available with AI-assisted delivery where it suits the job, at the same tested standard.

If your site still carries a bespoke theme, and every accessibility fix and every new component lands on your own budget, ask us what moving onto CivicTheme would take.

When the website is the public record: a federal publication estate

Some organisations have a website because they need one. Others have a website because it is the record. If your work is to give public advice, the site is where that advice gets published, cited, downloaded and checked again years later, long after the news cycle that produced it has moved on.

The Climate Change Authority is an independent statutory body that advises the Australian Government on climate policy: emissions reduction targets, the Emissions Reduction Fund, the Renewable Energy Target, the Carbon Farming Initiative.

Its website carries that record:

• annual reports
• corporate plans
• strategic frameworks
• the outcomes of Authority meetings
• public submissions filed by industry and community organisations

More than 1,000 documents, and the people who come looking are usually after one specific thing.

That is a publication estate, not a brochure site. It sets a different bar: findable, readable, accessible, and stable for a very long time.

Our part: the CivicTheme sub-theme, build and configuration

We were brought in for one thing: to move the site onto CivicTheme(Opens in a new tab/window), the Australian government design system. We help build and maintain CivicTheme itself, so this was familiar ground. A migration onto a design system tends to go faster when the people doing it know why each component is shaped the way it is.

It was a short and precise engagement in 2023. We delivered:

• the site's CivicTheme sub-theme and the configuration around it
• the front-end build and the component workflow the theme depends on
• the local tooling the next developer would reach for

Then we handed the platform back. The Authority's own team and its partners have carried the site forward since, which is how a migration should end. For a client, that shape reads as a bounded cost: a specialist engagement with an end date, not a dependency.

Building inside GovCMS SaaS, a platform that allows no custom code

The site runs on GovCMS(Opens in a new tab/window) SaaS, the Australian Government's shared Drupal(Opens in a new tab/window) platform. There are no custom modules on that platform, and there structurally cannot be. Core, the distribution and the contributed modules all arrive in the platform image, and an automated check refuses a deployment if anything unexpected turns up in it.

That sounds like a limit on what you can build. It is really a limit on how. Everything we delivered lives in the theme and in configuration, and that turns out to be a discipline rather than a compromise:

• no bespoke module to maintain
• no bespoke upgrade path to plan around
• a platform free to keep the software underneath the site patched

Constraints like these reward knowing the platform well. The front-end build had to fit a host that runs no build step of its own, and the platform's own code checks had to pass cleanly on files that nobody writes by hand. Both are the kind of problem you solve once and then stop paying for.

What a design system actually buys you: no bespoke content types or fields

The site uses CivicTheme's content model exactly as it comes. Not one bespoke content type, not one bespoke field.

That is easy to skim past, and it is the whole cost argument for design systems. Every custom field is something a person has to understand, document, test and carry through the next upgrade, indefinitely. A federal publication estate needed none of them, because the design system already covered the job.

What is left to look after is a thin layer of styling on top of a library that other people keep improving. For a client, that reads as a smaller bill to carry: you maintain the styling, not the system underneath it.

Accessibility works the same way. In a design system it is a property of the shared components, maintained once for everyone who uses them, rather than a line item in each agency's budget.

Where it landed: live on CivicTheme, carried by the client's own team

The Climate Change Authority's website is live at climatechangeauthority.gov.au(Opens in a new tab/window) and runs CivicTheme.

More than 1,000 documents on a federal publication estate, and not one bespoke content type behind them.

Our part was brief and deliberately so. A migration done well ends with a client who no longer needs the specialists, and that is what happened here: development continued in the hands of the Authority's team and its partners.

The design system underneath is still maintained and still improving, and the site inherits that work without commissioning any of it.

For agencies whose website is the public record

Everything on this page is 2 of our services on one federal publication estate: a migration onto a government design system, and development delivered entirely in theme and configuration on a platform that allows no custom code.

If you run a GovCMS site, or any publication estate that has to stay findable and accessible for years, this is the shape the engagement takes: a short specialist migration onto CivicTheme, a stock content model wherever the design system already covers the job, and your own team carrying the site afterwards. The same work is available with AI-assisted delivery where it suits the scope.

If you are weighing a move onto CivicTheme, or wondering what GovCMS SaaS will and will not let you build, tell us what your site has to keep publishing.

Everyone builds the same components, separately: navigation, cards and accessible forms

Every public-sector website needs the same handful of things:

• a navigation people can actually use
• a card, a button, a form that works with a screen reader
• pages that read unmistakably as official

Most organisations pay to build all of it again, from scratch, on every project.

The cost is not only the first build. It shows up again when a component changes and nobody can say which of your sites carries which version, and again when accessibility arrives late as a remediation ticket rather than early as a default. And the sites drift apart until services meant to feel like one government no longer do.

A shared design system converts that repeated spend into a single maintained asset. Designing one is the easy half. The hard half is maintaining it so that the teams downstream can take an update without fear.

What CivicTheme is: a UI Kit, a Drupal theme, modules and a Figma source

CivicTheme(Opens in a new tab/window) is an open-source, component-based design system published by Salsa Digital(Opens in a new tab/window). Its own documentation puts the purpose plainly: it was created "so governments and corporations can rapidly assemble modern, consistent and compliant digital experiences".

4 parts ship, and they stay in step:

• a CMS-agnostic UI Kit of components built with HTML, CSS and JavaScript, browsable in Storybook
• a Drupal(Opens in a new tab/window) theme that connects the content model to those components
• supporting modules, including one that adapts the theme to the federal GovCMS(Opens in a new tab/window) platform
• a Figma design source that carries the same version number as the code, so a designer and a developer are provably looking at the same release

Accessibility sits in the baseline rather than in each agency's budget. The documentation is explicit: "The components have been built and assessed to comply with WCAG accessibility standards 2.1 AA out-of-the-box."

Our part in the work: architecture, release engineering and maintenance since 2021

Salsa Digital publishes CivicTheme, hosts it and runs its community. We wrote its first commit in September 2021 and have provided the engineering behind it ever since:

• architecture of the component system
• development of the components, the theme and the supporting modules
• release engineering, to drupal.org and to npm
• ongoing maintenance as Drupal, PHP and GovCMS move forward

Everything is developed in one repository and published out to the separate ones people install from. Develop together, ship separately: that one decision lets a small team keep a theme, a component library, companion modules and a documentation site moving in step.

Underneath it, the build and continuous integration run on our own open-source project tooling, the same tooling we bring to client platforms. For a client, that reads as inheritance: the build and test discipline behind a public design system arrives with us on your own platform.

Making an update safe to take: visual regression and schema update tests

Components exist in 2 forms, Twig templates and Drupal Single Directory Components, so that Drupal consumers and non-Drupal consumers each get the implementation they need. Keeping 2 versions of every component honest by hand would be untenable, so parity is machine-enforced: tooling synchronises them, and a check command fails the build the moment they drift.

The primary defence is visual. A unit test cannot tell you that a button moved 4 pixels, and teams downstream notice.

So every pull request captures screenshots of the components, publishes a side-by-side comparison and posts the link back into the review conversation where someone will actually read it. The same pipeline does double duty: one comparison catches a visual regression against the released version, the other catches drift between the 2 component implementations.

Then there is the question every organisation actually asks: what happens to our site when we take the update? Because the system ships configuration for content types, fields and site settings, updates are rehearsed against committed database snapshots, both schema-only and schema-with-content, before they reach anyone.

For a team downstream, that is what makes an update routine rather than a project: the change has been rehearsed against a database shaped like yours before it reaches you.

Release rules follow the same instinct: on drupal.org, where a release cannot be deleted, only the development branch is ever pushed.

Where it is now: Drupal 10 and 11, GovCMS, and 4 content profiles

Live and in service. Published on drupal.org and on npm, documented at docs.civictheme.io(Opens in a new tab/window), with the component library and a live demonstration site online.

4 industry content profiles ship alongside a default:

• Corporate
• Government
• Higher Education
• Health

Each is a complete worked example rather than a starter shell, so a team can watch the system do the job before committing to it.

It tracks the platform forward: Drupal 10 and Drupal 11, current PHP, GovCMS support kept current. A steady release cadence has carried it across 4 years, with a pre-release channel so teams can test a release candidate before they take it.

A single maintained design system, 4 industry content profiles, and 4 years of steady releases.

4 years on, we are still the engineering behind it.

For teams rebuilding the same components on every site

Everything on this page is 4 of our services running on one public open-source design system: the architecture of the component system, the development of the components and modules, the DevOps and release engineering that ships them, and the ongoing support and maintenance that keeps all of it current. The same standard applies to our AI-assisted delivery: whatever writes a component, the visual comparison and the schema update tests are what decide it is safe to release.

If you run a government agency, a university, or any organisation with a family of sites that keep drifting apart, this is the shape the engagement takes: a component library that is genuinely shared, accessibility in the baseline rather than in a remediation ticket, and updates rehearsed before they reach your site.

If you are weighing up CivicTheme for your next site, or you already run it and want taking an update to be routine, tell us which sites you are trying to keep in step.

When the platform will not let you write code: the GovCMS SaaS constraint

If you publish on a government platform, you have probably met the trade it makes. GovCMS, the Australian Government's whole-of-government Drupal(Opens in a new tab/window) service, gives agencies accreditation, compliance and managed hosting. In return, its software-as-a-service tier permits no custom code:

• no bespoke modules
• no server-side services
• nothing outside the vetted distribution

It is easy to read that as a wall. Almost every hard requirement a team has met before was answered by writing code, and here that answer is gone.

Our part in the work: architecture, build and migration engineering

A federal government department was moving its public web presence onto GovCMS, and its public channels carry the whole of what it does. A partner agency delivering that move brought us in as its engineering partner, with design carried by a separate studio.

We provided technical leadership, platform engineering and migration engineering:

• the scaffolding
• the content models
• the themes
• the deployment tooling
• the migration codebase itself

3 sites on one platform: a main channel, an intake site and a publication site

The engagement covered 3 sites on the same platform:

• the department's principal public channel, carrying reference information, publications, profiles, news, events and the programmes it funds
• a standalone public front door that takes structured reports from the public through a single intake form, live in 8 weeks
• a compact standalone publication site, shipped in 5 weeks alongside it

The main site's content model is built around the department's own subject matter, with its primary reference entities as first-class content rather than tags, so anything published can be placed against them.

Business logic that had to live in configuration: layout modifiers and design tokens

The most transferable piece is layout. Editors wanted per-section control over background images, gradients, colours, padding and height, at chosen breakpoints, so we modelled presentation as content.

Any component can carry any number of modifiers, each a small piece of content with its own media query, rendered as styling scoped to that component. An editor can combine a background image, extra top padding above tablet width and a minimum viewport height, without a developer and without code the platform would have refused. For a client, that reads as independence: your editors restyle a section themselves, and nobody has to ask first whether the platform will allow the code.

We took the same approach to the whole-of-government design system, re-theming it by assigning the department's design tokens into the system's own variables rather than overriding its output. Override the output and every release becomes a merge conflict. Assign tokens and it becomes a version bump.

We also restored the heading structure that paragraph-composed pages quietly lose, which screen readers rely on.

Moving 20 years of public content with no database to read

Roughly 20 years of published material had to move with the site: reference pages, publications, profiles, news releases and the document library behind them. There was no database to read and no API to call, so the source of record became the live public site, harvested and normalised into structured data.

That creates the problem any GovCMS team with a migration ahead of them is about to meet. A migration of this shape cannot be written without custom code, and the destination does not accept custom code. We resolved it architecturally: the migration ran as its own project on the platform-as-a-service tier, where custom code is permitted, and the content landed in the software-as-a-service site.

Archived material was treated as its own class throughout, because 20-year-old content does not have the shape of this morning's media release. And validation was written as configuration, committed beside the migration, so what landed could be checked against what was harvested.

Most migrations assert that they are correct. This one could be asked. For a client, that is the difference between being told a migration landed correctly and being able to check that it did.

What it adds up to: 10 months to build, 3 years of onward maintenance

The main site was built in about 10 months and went into service with 20 years of content behind it.

The measure we like most came later: it was still being maintained and upgraded 3 years after we handed it over, including a platform update and work toward a newer Drupal version, carried by the team that received it.

Built in 10 months, and still being maintained and upgraded 3 years after we handed it over.

A site still being improved by people who did not build it is solid evidence that it was built to be handed on.

For agencies that cannot ship custom code

Everything on this page is 5 of our services running inside one whole-of-government platform: architecture that puts the logic where the platform allows it, development of the content models and themes, the deployment tooling that ships them, migration engineering that could be checked against its source, and accessibility carried through the build.

If you publish on GovCMS software-as-a-service, or you are weighing a move onto it, this is the shape the engagement takes: requirements answered in configuration and theme rather than in modules you are not allowed to ship, a design system consumed by token assignment so an upgrade stays a version bump, and a migration that runs where custom code is permitted and lands where it is not. The same engineering is available with AI-assisted delivery where the work suits it, most obviously across migration mapping and validation.

If you have a requirement your GovCMS site will not let you build, tell us what it is and we will tell you where it can live.

GovCMS: when the platform will not let you write code

If you publish on a government platform, you have probably met the trade it makes. GovCMS(Opens in a new tab/window), the Australian Government's whole-of-government Drupal(Opens in a new tab/window) service, gives agencies accreditation, compliance and managed hosting.

In return, its software-as-a-service tier permits no custom code: no bespoke modules, no server-side services, nothing outside the vetted distribution.

It is easy to read that as a wall. Almost every hard requirement a team has met before was answered by writing code, and here that answer is gone.

Our part in the work: technical leadership and migration engineering with Salsa Digital

The Department of Foreign Affairs and Trade runs Australia's international relations, trade policy, development assistance and consular services, and its public web presence carries all of it. Salsa Digital(Opens in a new tab/window), delivering the move onto GovCMS, brought us in as its engineering partner, with design carried by a separate studio.

We provided technical leadership, platform engineering and migration engineering:

• the project scaffolding and the deployment tooling
• the content models behind all 3 sites
• the themes, including the design-system work
• the migration codebase itself

3 GovCMS sites for a department with a global remit

The department's public presence was built as 3 sites.

• the corporate site, its main public channel, carrying country and regional information, publications, profiles, news, events and the programmes it funds
• tradebarriers.gov.au, the national front door where Australian exporters report the obstacles they meet in overseas markets that are not tariffs: quarantine rules, labelling requirements, customs delays. It takes reports through a single structured intake form, and was live in 8 weeks
• a site for the Cairns Group, the coalition of agricultural exporting nations chaired by Australia, shipped in 5 weeks

The corporate site's content model is shaped like a foreign ministry, with country pages as first-class content rather than tags, so anything published can be placed geographically.

Business logic that had to live in configuration: layout modifiers and design tokens

The most transferable piece is layout. Editors wanted per-section control over background images, gradients, colours, padding and height, at chosen breakpoints, so we modelled presentation as content.

Any component can carry any number of modifiers, each a small piece of content with its own media query, rendered as styling scoped to that component. An editor can combine a background image, extra top padding above tablet width and a minimum viewport height, without a developer and without code the platform would have refused. For a client, that reads as independence: your editors change how a page looks without booking developer time.

We took the same approach to the Australian Government Design System, re-theming it by assigning the department's design tokens into the system's own variables rather than overriding its output. Override the output and every release becomes a merge conflict. Assign tokens and it becomes a version bump.

We also restored the heading structure that paragraph-composed pages quietly lose, which screen readers rely on.

Moving 20 years of public content: a migration built where custom code is allowed

Roughly 20 years of published material had to move with the site: country pages, publications, profiles, news releases and the document library behind them. There was no database to read and no API to call, so the source of record became the live public site, harvested and normalised into structured data.

That creates the problem any GovCMS team with a migration ahead of them is about to meet. A migration of this shape cannot be written without custom code, and the destination does not accept custom code.

We resolved it architecturally: the migration ran as its own project on the platform-as-a-service tier, where custom code is permitted, and the content landed in the software-as-a-service site.

Archived material was treated as its own class throughout, because 20-year-old content does not have the shape of this morning's media release.

Validation was written as configuration, committed beside the migration, so what landed could be checked against what was harvested. Most migrations assert that they are correct. This one could be asked.

For a client, that is the difference between trusting a migration and being able to check it.

What it adds up to: 10 months to build, still maintained 3 years on

The main site was built in about 10 months and went into service with 20 years of content behind it.

The measure we like most came later: it was still being maintained and upgraded 3 years after we handed it over, including a platform update and work toward a newer Drupal version, carried by the team that received it.

Built in about 10 months with 20 years of content behind it, and still being upgraded 3 years after handover.

A site still being improved by people who did not build it is strong evidence that it was built to be handed on.

For teams publishing inside a platform they cannot extend

Everything on this page is 5 of our services running inside a platform that permits no custom code: architecture that puts business logic in configuration, development within a vetted distribution, migration at 20-year scale, DevOps and hosting through the platform's own tooling, and accessibility work carried in the theme.

If you publish on GovCMS, or on any accredited government platform that fixes what you are allowed to build, this is the shape the engagement takes: presentation modelled as content so editors keep control, design-system work done by assigning tokens rather than overriding output, and a migration that can be checked rather than trusted. The same engineering is available with AI-assisted delivery where it suits the work.

If your GovCMS build has a requirement the software-as-a-service tier will not let you code your way out of, tell us what the platform is blocking.

The GovCMS foundation dozens of government websites stand on

GovCMS(Opens in a new tab/window) is the Australian Government's shared Drupal(Opens in a new tab/window) platform, run by the Department of Finance. Agencies across federal, state and local government build their websites on it and get security, compliance and managed hosting in return for working inside the platform's rules. It is common ground under a large part of the Australian government web estate.

Working on a platform like that is a different kind of work from building one agency's website. A decision you make on an agency site shapes that site.

A decision you embed in the platform's own tooling shapes every project started from it afterwards, for years. That is where we spent 2018 to 2020.

What a project scaffold actually decides

Every new site on a shared platform starts from a scaffold: a project template that arrives with the platform's opinions already made.

• how the project is laid out and how its dependencies are managed
• how a developer runs it on their own machine
• what the automated checks look at before a change is allowed through
• what the platform will simply refuse to deploy

Most people never see this layer, which is exactly why it matters. Get it right and every team starting a project inherits a safe, tested path to production without having to think about it. Get it wrong and every team inherits the same friction, one project at a time.

What we contributed to the GovCMS scaffolds

We were the leading contributor to 2 of the platform's project scaffolds, govcms7-scaffold and saas-scaffold, and to the continuous integration that runs alongside them. We also contributed to:

• the platform's hosting integration on Lagoon
• its shared CI tooling and provisioning automation
• its Drupal 8 distribution and the platform's own website
• 2 of its content-safety modules

It is worth being precise about what that means. This is contribution, not stewardship. The platform belongs to the Department of Finance and its direction always has.

What the public record shows is that across roughly 3 years we were the leading contributor to the templates every consuming project starts from. The repositories are open source, so anyone can check that for themselves, which is the whole reason it is worth saying.

Scaffold design: opinionated and generic at the same time

A platform scaffold has to pull in two directions at once. It has to be opinionated enough to be genuinely useful, so that a team gets a working, tested project on day one. And it has to be generic enough to serve every agency on the platform, from a small statutory body to a large department.

Then there is the boundary. Some files belong to the project and some belong to the platform, and a project that edits the wrong one cannot deploy at all. That is why these scaffolds carry an explicit list of files a project must leave alone.

Drawing that line, between what a team may change and what the platform owns, is the central design problem of this kind of work. It is the difference between a template teams trust and one they quietly fight.

The same problem, solved twice: GovCMS and Vortex

In the same period we were answering the identical question in our own practice. Our open-source Drupal project template, Vortex(Opens in a new tab/window), grew out of it: how do you give every project a build, test and deploy path that is standard enough to maintain and flexible enough to be worth using?

Doing both at once meant each one informed the other. It is also a fair answer to a question we are asked often, which is why anyone should trust our project template. Because we did the same job inside a federal government platform, in public, where the result can be read.

What it added up to: platform foundations we later built on

The scaffolds shipped and were used. Government agency websites were built from them, including several we went on to deliver ourselves.

Across roughly 3 years, the leading contributor to the project templates every GovCMS site starts from, in repositories anyone can read.

Contributing to a platform's foundations and then delivering agency sites on top of those foundations is an unusual combination. For an agency choosing a partner on the platform, the practical difference is a team that knows which files the platform owns before the first deploy fails.

None of it is locked away, either. The platform's tooling is open source, so the work is there to read.

For agencies building on GovCMS

The work on this page sits behind 3 of our services: platform architecture, Drupal development, and the DevOps and hosting engineering that decides how sites reach production.

If you run an agency site on GovCMS, or you are choosing between SaaS and PaaS for your next build, this is the practical advantage: we contributed to the templates your project will start from, so the platform's rules are not a surprise to us. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If a GovCMS build or migration is on your roadmap, tell us where it stands.