Sorry, you need to enable JavaScript to visit this website.

A Defence portfolio agency's website, built to a government design system

Government websites are built inside an identity that has already been decided, and the real cost hides in the components. In 2024 we provided the Drupal engineering behind a public website for an Australian Defence portfolio agency, as the build partner to a Canberra digital agency.

At a glance

Year
  • 2024
Status
  • Completed
Technologies

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.

  • Government
  • Drupal
  • Design system
  • Migration