Assertive Community Treatment Website

Background

The Provincial Assertive Community Treatment Advanced Practice (ACT‑AP), led by Vancouver Coastal Health, needed a modern, public‑facing website to centralize information about Assertive Community Treatment (ACT) services across British Columbia. The site serves people receiving ACT services, their families, service providers, and community partners by explaining the ACT model, outlining eligibility, and highlighting stories of impact from teams across the province.

Before this project, ACT‑AP’s public website was owned and operated by a third‑party vendor on a custom Angular stack, with a closed deployment pipeline and infrastructure that did not align with internal DevOps practices. Content modeling, navigation, and UX had grown organically, making it hard for ACT‑AP staff to adjust information architecture or iterate on features like the teams map, glossary, and education calendar.

Previous website

Role

In this project, I served as both technical lead and project manager, responsible for planning the migration, coordinating stakeholders, and owning the delivery of a new platform that ACT‑AP could operate independently.

Discovery

Discovery focused on understanding both the legacy implementation and ACT‑AP’s operational reality. A series of Knowledge Transfer sessions with the vendor walked through the Angular codebase, Terraform configuration, and hosting architecture. In parallel, stakeholder meetings began that captured expectations around governance, long‑term maintenance, and how ACT‑AP wanted to track success once the website was in‑house.

On the UX side, ACT‑AP wanted the site to feel more like a clear, welcoming hub than a collection of disconnected pages. UX discovery sessions and SME workshops dug into three user journeys:

These sessions exposed pain points with the existing navigation, how FAQs and About ACT content were presented, and how difficult the education calendar and events were to scan.

Objectives

From that discovery work, the project team aligned on three main objectives.

1. Bring the platform in‑house. Replace the vendor‑owned Angular front end with an internally managed Nuxt/Vue app, and move infrastructure (AWS + Terraform) and deployment pipelines under the Learning Technologies team so future changes don’t depend on the vendor’s timelines.
2. Improve performance, accessibility, and sustainability. Reduce bundle size and complexity with server‑rendered Nuxt and a lean Tailwind component library. Rationalize the Strapi content model so pages like About ACT, FAQ, glossary, and resources can evolve without code changes. Address the infrastructure hygiene items identified in 2024, such as security groups and environment separation.
3. Make the site work better for ACT’s real audiences. Make it easier to find a local ACT team, clarify staff roles with consistent profile layouts that support both recruitment and transparency, and improve the education calendar so ACT‑AP can run ongoing training without fighting the tooling.

Process

Taking over the stack

The first phase was about “owning the stack” without disrupting service. Guided by the June knowledge‑transfer sessions, I replicated and then simplified the vendor’s Terraform configuration, adding a clearer separation between dev and prod environments and preparing for a new front‑end build pipeline on AWS. We also planned and executed the migration of security groups and bastion access so the internal team could manage infrastructure without introducing new risk.

In conversation with ACT‑AP and EYDS in February and May, we agreed on a phased deployment strategy: ship a functionally equivalent Nuxt front end backed by Strapi, then iteratively improve UX and content as the team gained confidence with the new tools. This allowed us to cut over infrastructure and hosting without forcing the ACT‑AP team to rewrite all their content at once.

Rebuilding the front end with Nuxt

With the infrastructure plan in place, I rebuilt the front end as a Nuxt.js application using Vue components and Tailwind for styling. The new architecture used server‑side rendering for better performance and SEO, while keeping the codebase small enough that ACT‑AP’s own developers could confidently extend it.

Meeting notes throughout late 2024 and early 2025 document the incremental UX and content work on top of this foundation:

Evolving content modeling in Strapi

A large part of the project was about modeling ACT‑AP’s content in a way that matched real workflows. Meeting notes from late 2024 show new Strapi collection types created for ACT teams, testimonials, modules, events, and staff overview cards, plus a set of migrations to move existing content into those structures.

We introduced a more flexible “About” page model so the ACT‑AP team could manage sections, calls‑to‑action, accordions, and supporting links entirely from the CMS. The FAQ and glossary were given their own content types, enabling better cross‑linking from other pages (for example, glossary tooltips embedded in body copy). For events, we added support for recurring series, a clearer distinction between upcoming and past events, and a staff‑focused pattern with an “Ask for an invite” action instead of a generic “Add to calendar” button.

These changes meant that many follow‑up requests captured in 2024 meetings—like revisiting the Resources and Services section, improving document access for staff, or adjusting navigation labels—could be handled as editorial changes rather than development tasks.

Collaboration and iteration

From February 2024 onward, the project ran as a collaborative, iterative effort between Learning Technologies and ACT‑AP. Regular meetings served as checkpoints to demo features, capture feedback, and negotiate scope around items such as SEO, analytics, and future personalization work.

Results

By Spring 2025, act‑bc.ca was running on an internally managed Nuxt/Vue front end, backed by Strapi and AWS infrastructure controlled by the Learning Technologies team via Terraform.