KTO needed a design system that could serve multiple iGaming brands from a single component architecture. I built it from scratch, solo, while shipping real product at the same time.
01 · Context
KTO had a basic design system in place. It served a single brand, a single theme, and components built as needed. Not chaos, but not infrastructure either. It was a starting point, not a foundation.
The inflection point came when the business acquired a white-label license allowing up to two additional iGaming brands to be launched on top of the existing one. The existing system wasn't wrong. It just wasn't built for what was coming.
The question shifted from "what should this screen look like?" to "how do you design one system that can produce brands that feel completely different from each other?" That's an architecture problem before it's a design problem.
Context: KTO also runs Frontline, a separate design system scoped exclusively to the logged-out product, covering marketing pages, growth surfaces, and content at scale. Two systems, two surfaces, different jobs. ACE is the logged-in, product-facing system.
02 · The Challenge
The stated brief was "build a design system." The real challenge was harder: how do you design a system that works for brands that need to feel different from each other, without rebuilding it every time a new brand arrives?
I was the only designer on this. That meant every architectural decision was mine to make, defend, and live with. And I was making them while simultaneously delivering real product — which meant the system had to earn its place in the workflow, not just exist as a parallel initiative.
The theme problem
The product was running mixed — some surfaces in light, some in dark. That inconsistency alone would multiply the complexity of any token architecture. Standardizing themes was a prerequisite for everything else, and it required a clear org-wide call before a single token could be structured correctly.
Shipping before the system was done
Teams needed to use ACE components in production — Register Flow, My Account, RG Limits — while the system was still being built. That's not a failure state, it's how systems get stress-tested in the real world. But it meant maturity decisions had to be explicit and communicated, not assumed.
03 · Key Decisions
Naming. Systems need names that communicate their intent. I chose ACE: short, iGaming-native, and an acronym that describes the architecture itself. Atomic Components Ecosystem. The name does the work of explaining the model before anyone opens the Figma file.
Standardizing on dark theme first. My reasoning: designing with mixed themes would make the token system exponentially harder to manage — one inconsistency would cascade across every component. Dark as default reduced scope, created a clean baseline, and preserved the ability to add light theme later without rebuilding components. Token Studio was configured for automatic light/dark switching from day one.
Four-layer token architecture
Global — raw primitives. Colors, sizes, radii. No semantic meaning yet.
Brand — brand-specific overrides. KTO's palette. A future brand's.
Theme — light and dark. The last layer that can override anything.
Component — neutral. Never overridden by brand.
Other key decisions
Typography above components, not inside them. When a new brand arrives with its own type scale, you'd need to override component-level tokens — breaking the neutral-component principle. Moving typescale above components meant a single change propagates everywhere.
Style Dictionary as the build layer. Token Studio is the source of truth. Style Dictionary merges all JSON sets on build — adding a new brand means adding a new brand JSON, not restructuring the architecture.
A dedicated component JSON for dev consumption. Each component explicitly lists its required tokens. It made handoff predictable and kept the structure documented rather than living in someone's head.
04 · The System in Action
The first full component set shipped to development was buttons — all variants: Primary, Secondary, Branded, Ghost, and Icon — handed off to the dev lead with full token chains documented. From there, ACE started showing up in real product surfaces.
Product surfaces shipped via ACE
Register Flow — designed and handed off through the system. One of the highest-traffic, highest-stakes surfaces in the product.
My Account — full redesign built on ACE components.
RG Limits — designed, component-ized, and handed off within the system.
Adoption signal
The Head of Product asked, unprompted, for the Native Casino app to be aligned with ACE, and floated integrating it with Figma Make as a next step. That kind of pull from outside the design team is what a design system is supposed to generate.
05 · Impact
Register Flow, My Account, and RG Limits — three of the most critical logged-in surfaces — all delivered through the system. Org-level commitment was also real: the Head of Product set a Q4 deadline and a dedicated channel was opened for it. ACE had executive visibility, cross-team participation, and a formal mandate. It wasn't a side project.
When the business opens brand two, the system won't need to be rebuilt. The token pipeline runs. Dark/light switching is architecturally ready. That was the point from day one.
06 · What Didn't Work
AI tooling and token discipline don't yet play well together
Current AI design tools — including Claude and Figma AI — use raw hex values, not design tokens. In a token-first system, that's a real gap. It means AI-assisted workflows and the system's core principles are in tension. I identified this early but there's no clean solution yet. It's something to watch and plan for as AI tooling matures.
Shipping before the system was stable created friction
Some teams were using components in production before confidence levels were formally defined. That led to recurring "should we use this yet?" decisions that required manual answers each time. If I were starting over, I'd define a component maturity model earlier — draft, beta, stable — and communicate it explicitly so teams could self-serve that decision.
The Figma/Tokens Studio connection was a bottleneck. The token architecture was ready for light/dark switching well before Figma reflected it. Better documentation of that gap at the time would have avoided confusion.
07 · What's Next
ACE is a live, growing system — not a completed project. The roadmap from here:
In progress
Complete the component queue currently in design: form elements, navigation, modals. Define and publish a component maturity model for team-facing consumption.
On the horizon
Align the Native Casino app to ACE — the first cross-surface expansion. Prepare the brand slot architecture for brand two when the business is ready to activate it.
The infrastructure exists. The next phase is scale.