COMPLY Design System
Four companies, four codebases, four color systems — and a rebrand that threatened to only reach the marketing site, not the product underneath it. A design system doesn't have a business case of its own — I gave it one by attaching it to a launch that already had a budget and a deadline. Phase 1 shipped the same day the billboard went up in Times Square.
COMPLY is a compliance platform built from four previously separate companies. The merger happened under private equity ownership, during a stretch of heavy executive turnover that saw multiple CTOs and CEOs come and go. Each brand had its own codebase, its own color system, its own type scale, its own component language. In the largest products, two or three layers of half-finished redesigns stacked on top of that.
The cost wasn't abstract: engineering rework every time the drift widened, client confusion when firms got cross-sold between products that looked like they came from different companies, and a sales team trying to promise a unified suite that didn't look or feel like one.
I was the primary architect of the fix — building the token foundation and core components myself, then getting the system adopted by front-end engineers across all four legacy product teams.
Custom Token System Over Off-The-Shelf
The first attempt at a design system, a year earlier, reached for the fast answer: an off-the-shelf component library. It never spread past one of the four brands — the tool assumed a shared framework that didn't exist. Making it work meant ripping pieces out to fit each codebase, and every implementation became its own Frankenstein.
This time, I took a different approach: I built the system from the ground up, as primitive tokens — type, spacing, color, radius — mapped to semantic tokens that each engineering team could apply within their own codebase's constraints. The payoff wasn't just consistency and efficiency — it was a better experience for customers, no longer stitched together from four different-looking products. Because engineering was in the loop from the start, components matched how both teams already thought about the product. For the first time, design, engineering, and product had a shared language.
Ownership
Nobody owned the first attempt. That was as much of a challenge as the tooling choice — a design system decided by committee, where no one was responsible for what shipped, so nothing did. On the second attempt, I took accountability — driving the sequencing myself, prioritizing high-use components in maximum-visibility areas. Past that first launch, I led from the front: laying the foundation, building out the initial components in Figma before asking anyone else to build with them. Then I brought two designers and three contractors in to work alongside me — not to inherit a finished system, but to get their hands on it early, shape it with their feedback, and get invested in building what came next.
Once there was enough of the system in place, I shifted into a product-owner role: writing requirements for the components still needed, setting rules for how they should look and behave, and making sure every new piece stayed built on the foundational tokens instead of drifting off on its own. That's also where the first governance model started taking shape — rules meant to keep the system working once I wasn't the one enforcing them by hand.
Tying The System's Funding To The Rebrand Launch
The business wanted one thing out of Phase 1: match the product's login experience to the new logo and brand. That project already had a budget and a deadline: a public launch complete with a Times Square billboard.
I used it as a chance to deliver more than what was requested — building the actual foundation underneath it: primitive and semantic tokens covering everything from navigation to buttons and tables to cards. From the outside, Phase 1 looked like a brand refresh. Underneath, it was the start of the entire design system — set up to carry the company and the product further into the future than that first request ever intended.
Outcome
Phase 1 shipped on schedule, in lockstep with the public rebrand — logo, type, and the login experience unified across all four brands the same day the billboard went up. Phase 2 followed: navigation, dashboard layout, typography, color palettes, buttons, forms, and tables, live in three of the four brands, with the rest of the component library already mapped out and ready for implementation.
The benefits showed up fast: a single, unified experience across four products that used to look like four different companies. It also gave future work a North Star — new pages and features had something concrete to build toward, instead of drifting the way the four original brands had. Designers shipped high-fidelity mockups faster and more consistently. Engineers stopped rebuilding the same button or form field four separate ways. Product managers used the system as the source of truth for AI-assisted prototyping. The design team, eight front-end engineers, and product managers across four product teams — that, a year earlier, didn't share a single component — started working from the same design system.
Reflection
This system had to survive things a design system doesn't usually have to survive: four different codebases, a private equity owner, and enough C-suite turnover that no single executive sponsor was ever guaranteed to stick around. I'm proud of what shipped under those conditions. What got it there wasn't a better token spec than the first attempt's — it was learning from what came before and building something that worked in practice, not just in theory. I paired the fix with documentation, something none of the four codebases had ever had before. The win wasn't finishing every page of it — it was that a real template for how components should look and behave existed at all.
Knowing what I know now, I'd have built governance in from day one, not after the fact. That means earlier leadership buy-in, explicit rules for how and when components could change, and a real change-management model — not just documentation good enough to slow drift, but a structure built to run without me, past whatever reorg came next.
Untangling a complex system across a messy, real-world org?
The architecture is the easy part — the harder part is getting teams to actually adopt it, and keeping it alive through turnover. Happy to talk through it.
Get in touch