Delivering GC digital services looks similar across departments: design web content so the public can find the service, build a form to collect requested information, and send updates throughout the process until completion.

GC service teams need these parts, whether it’s for renewing a passport, filing taxes, or enrolling in a benefit program. Historically, departments have built these pieces from scratch or procured software that often does more than what’s needed or needs to be customized. This is expensive, slow, duplicative, and often doesn’t solve the entire problem. 

We’re the Platform team at CDS: our goal is to provide solutions for these common needs with our products (currently three: GC Notify, GC Forms, and GC Design System). Most GC departments use at least one of these, and we’re seeing an increase in teams using multiple products together to provide a digital service. 

Our growth didn’t come from a technology choice or picking the right product at the right time. It came from a specific way of working and an operating model, applied consistently three times over.

Why this isn’t a technology story

Government has no shortage of technology solutions. What it consistently lacks is a model for building something once, on behalf of everyone, and keeping it accountable to actual users rather than to the department that funded it. That’s the gap Platform was built to close, and it’s a gap in operating model, not tooling.

Starting deliberately small

In 2019, CDS didn’t set out to build the most impactful product it could imagine. We forked the open-source GOV.UK Notify (the UK Government Digital Service’s notification tool) because it was the fastest way to stand something up, prove that Platform-built tools were worth investing in, and start learning. 

It was a deliberately unambitious starting point: the product stayed imperfect while the team found partners, adapted it to a Canada’s bilingual context, and let real users tell them what to fix next, rather than trying to anticipate everything in advance.

That restraint was the strategic move. It got the model moving without betting the organization on an unproven idea, and it gave the team room to earn credibility before asking for more.

From one product, to a portfolio of three

The credibility we built became the case for what came next. Three products, one thesis: departments shouldn’t have to rebuild or buy the same pieces service by service. CDS Platform builds them once, and teams plug them in where they’re needed.

Our growth is compounding on three fronts at once (more clients, more volume, and higher-stakes use cases for bigger impact):

• GC Notify was built in 2019 to provide a commonly needed notification tool for service updates:
  Over 106 million notifications have been sent by 929 live services (across 61 departments). Examples: Health Canada Recall and Safety Alerts and the Canadian Dental Care Plan (CDCP).
• GC Forms launched in 2021 to solve the same underlying pattern of filling out forms (up to Protected B data) to access GC services:
  Over 895 thousand forms have been submitted to our approximately 3 thousand users (across 74 departments). Examples: Department of Finance Canada (FIN) tariff consultation and Indigenous Services Canada (ISC) Nursing initiative. 
• GC Design System followed in 2023, it was built to support consistent user experiences across GC web and applications:
  Over 92 teams are using it (across 28 departments), with 20 services already live and many more in progress. Example: Department of Fisheries and Oceans Canada (DFO).

Want more details? Dig into our operating model!

• Structured as agile, multidisciplinary teams with end-to-end ownership:
  Each team owns its work end to end, with product management, research and service design, engineering, accessibility, security, and user support all pulling toward the same outcome.
  
• Draws on cross-function support that are critical to product success (policy, growth, client experience, and support):
  Each brings specialized expertise just in time, without becoming a dependency the team has to manage around. It’s what lets a small product team carry end-to-end accountability without having to build every capability itself.
  
• Teams have the autonomy to test, learn, and adjust course as they go, rather than deliver against fixed specifications:
  Teams hold real authority over their own roadmaps, release cycles, and priorities. That’s a different accountability structure than the typical departmental IT project, where delivery, funding, and user outcomes are often owned by different groups with different incentives.
  
• A shared, disciplined rhythm keeps three products pointed in the same direction:
  The Platform key results and cross-team initiatives are set out at the beginning of the fiscal year in alignment with CDS objectives. Each is reviewed every quarter to ensure that teams have what they need and are headed in the right direction. This approach gives every team member the clarity they need to do their job and the context to understand how it contributes to the bigger goal.
  
• Maintain shared ways of working that other product teams could build on:
  Teams stay lean because they don’t duplicate what’s shared. They plug into each product’s rituals with subject-matter expertise, rather than each product building its own function for policy, awareness, research, or support infrastructure.
  
• Every product is held to the same seven principles (secure, accessible at WCAG 2.1 AA or higher, multilingual, scalable, self-serve, user-centered, and built so departments can combine them without touching each other’s codebases):
  Each of these principles carries its own weight on its own terms, but together they exist for one purpose: to strip away the traditional barriers that stand between a public servant and delivering a service.
  
• Roadmaps are built from evidence, not opinion:
  Last fiscal year alone: 1,100+ support tickets analyzed for pain points, 22 UX research studies, 1,412 client surveys, and 2,567 people through product demos. Central teams create a continuous feedback loop to product teams which helps them determine what to prioritize.

Where this goes next

Scaling doesn’t require a new way of doing things, it requires the same discipline that got the first product off the ground: pick the next right-sized problem, give an accountable team the room to own it, keep user needs at the core of every decision that’s made, build the shared foundation once so nobody has to build it twice, and keep iterating in the open as real usage tells you what’s next. 

That’s what agile, continuously improved delivery looks like at this scale: not a single win, but a repeatable way of finding the next one. That discipline is what Platform is scaling, and it’s why there’s no real ceiling on the growth ahead: just the next problem we can build solutions for.