When people ask me what the hardest part of building HuskyX was, they usually expect me to say the components, or the politics of getting 200+ brands to agree on anything. Those were hard. But the part that required the most patience was tokenization, precisely because the right move was to wait.

Why we deliberately did it last

Tokenization was never an afterthought in HuskyX. It was the plan from early on. But we sequenced it after the system's structure and code were fully defined, and that decision was intentional for two reasons.

First, the system itself needed to mature. Tokens are a formalization of decisions, and if you formalize decisions that are still moving, you spend your time refactoring token architecture instead of shipping websites. We had 45+ brand layouts to migrate in the first wave alone, under tight timelines driven by subscription and legal constraints. The structure had to settle before we could encode it.

Second, and this is the part people underestimate, the tooling was not ready. Figma and Token Studio simply were not capable of supporting a system of this scale at the time. Rather than fight the tools, I led consultations with both Figma and Token Studio directly, helping shape the product features that were necessary for this to work at our scale. Some of the capabilities that now exist in those tools came out of those conversations. I believe what we ended up with is unique in the industry, and it only worked because we timed it right.

The moment the ecosystem caught up

A turning point for my own conviction was Penpot Fest. I attended, and watching the open design tools community rally around design tokens, including the announcement of the Penpot and Tokens Studio collaboration and the push toward the W3C design tokens standard, confirmed something I had been arguing internally for a long time: tokens were not a niche technique for design system enthusiasts. They were becoming the connective layer between design and code across the whole industry. Seeing that momentum in one room, from tool makers and practitioners alike, gave us the confidence that building our entire theming pipeline on tokens was not a bet on a trend. It was a bet on where the whole discipline was heading.

What we actually built

Once both the system and the tooling were ready, we tokenized 58 components into nearly 2,500 interconnected tokens. This was not a flat list of color values. The tokens encode the relationships that hold the system together: how a brand's core palette cascades into component states, how typography scales resolve per breakpoint, how spacing and border radius propagate from brand-level decisions down to a single button.

The critical piece is the pipeline. Tokens are authored in Token Studio against our Figma workspace, then parsed directly into production website CSS. More than 90% of the process is automated. The remaining edge cases are handled through small amounts of custom CSS, kept deliberately narrow so the system's integrity is never at risk.

What it changed

Before tokenization, building a fully custom-branded instance of the system took days. Now it takes hours. Each brand gets its own verified, independently workable theme under light central supervision. A brand team can adjust its theme without touching another brand's, and without being able to break accessibility or layout rules, because those live below the token layer.

That is the quiet power of doing tokenization properly. It is not a styling convenience. It is the mechanism that lets one design system credibly serve brands as different as washing powders and baby formula, at a pace that made the program's founding target of 50% cheaper and twice as fast an operational reality rather than a slide in a deck.

The lesson I take from it: tokenize late, but design for tokenization from day one. The structure earns the tokens. Not the other way around.