Unifying Thrive’s design system

Thrive had three design systems in active use. A legacy custom component library from the original product. A MUI implementation partially adopted over time. And a shadcn uplift introduced earlier in the year that hadn’t closed out, leaving a third system layered on top of the other two. None of them were documented. None of them were governed. Components from all three were showing up in the same flows, sometimes on the same page.

That was the architecture. The product itself was worse.

A three-level nav that changed between pages. Same product, same user, different navigation depending on where they’d clicked. A search that opened to a blank dropdown, with no suggestions or recent queries, and forced users into an advanced search modal to do almost anything useful. A mobile view that was reactive in the technical sense, but fully broke the second the user navigated away from the homepage. Buttons, tables, and loaders had all diverged into multiple inconsistent implementations across the platform.

The design system hadn’t failed. It had never really existed.

I could have scrapped the shadcn work and picked something else. The fact that the earlier uplift hadn’t landed wasn’t a failure of the technology, it was a failure of scope and governance. Working with engineering, we committed to shadcn with Tailwind as the standard going forward, and put a proper initiative behind it.

The reasoning was forward-looking. Whatever we committed to next had to hold up against the 2026 vision, against a design system that needed to become AI-native, and against a team that needed room to build on top of it rather than work around it.

The call was deliberate. A second abandoned migration would have been unforgivable. This one had to actually close out, and that meant treating it as a proper focused workstream in its own right, not something squeezed between feature tickets.

Every previous attempt to fix the design system had widened into a redesign and collapsed under its own weight. This time had to be different, and that meant building proper process around the work: clear scope, a dedicated workstream, and rigour on every call that got made. Component-for-component replacement, minimal page-level adjustments, no redesign work. Use shadcn-native components wherever possible. Build on top of them only when the product genuinely needed something shadcn didn’t provide. Figma became the source of truth for design, with Storybook sitting alongside the coded components as the place the rest of the business could view live components and read the documentation embedded next to them. Figma’s MCP server was wired in with Code Connect to flag drift between Figma and the codebase as it happened.

The scope was the whole platform. Engineering did the heavy lift on the migration itself. My job was setting direction on the patterns, holding the line on consistency, and making the decisions that would outlive the migration. Base tokens (padding, radii, type, colour) were customised during the migration itself, so the platform evolved toward the 2026 visual language rather than waiting for a second jump later.

By the time the 2026 vision lands in production, the system beneath it will already be built to hold it.

A design system isn’t a project that finishes. Left to a single function, it drifts the moment attention moves elsewhere: design can’t police the code, engineering doesn’t hold the visual standard, QA can’t enforce what hasn’t been defined. So I set up a cross-functional guild to own the system as a maintained product. Three full-stack engineers, three designers, and a lead QA, backed by the CPTO and ring-fenced against the usual gravitational pull of feature work.

The guild’s remit is broad and deliberate. An AI-native system and component library that lets the team build flows at speed. Clear processes the wider business can follow autonomously and contribute to. Centralised governance to hold quality and consistency as the platform scales. Proper documentation that works for AI tools and people alike. A system that holds up across every device. Underneath it all sits the pattern taxonomy, a living record of every pattern on the platform across four tiers (Journey, Page, Component, Element) with design, code, and Figma status tracked separately against each one. The taxonomy, the processes, the governance are all means to an end. The system is the bedrock that lets us deliver high quality at phenomenal speed.

A design system has to move as fast as the people using it. Otherwise it becomes the slowest link in an org that’s accelerating at breakneck speed.

AI runs through the whole lifecycle. Components are made and amended with it. Documentation is written with it. Drift between Figma and the codebase is tracked through Figma’s MCP and Code Connect. Flows get built in Figma and pushed to code, or built directly in the codebase and pushed back to Figma so the record stays current in both directions. Slackbots handle ambient support and triage contribution requests into Jira tickets for the guild.

I stay hands-on in the frontend repo myself, and the design team is following the same pattern. Four sessions in, all but one are using AI regularly, and half have already shipped to production. None of that works without the system underneath: clean primitives, documented patterns, and drift tracking are what let AI build on top of it rather than against it.

The migration is closing out, but the system itself is only just getting started. AI-driven regression and accessibility testing is the next piece coming online, so quality gets caught before it ships rather than after. The pattern taxonomy keeps filling in, the documentation keeps deepening, and the design team keeps moving further into the codebase.

The bigger picture is the simpler one. The 2026 vision needed a foundation that could hold it. That foundation is now there, maintained by a guild, extended by a team using AI as a matter of course, and shaped to evolve with the product rather than chase it. The hard part was never picking a library. It was building the system around the system, and that’s the part that now lets everything else move.