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: a single brand, a single theme, components built as needed. Functional, but no systemic infrastructure. It served the product that existed, not the one that was coming.
The inflection point came when the business acquired a white-label license to launch up to two additional iGaming brands 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 produces 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.
Existing system audit, single-brand component inventory
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, which meant every architectural decision was mine to make, defend, and live with while simultaneously delivering real product. The system had to earn its place in the workflow, not 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 because it's 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. Designing with mixed themes would make the token system exponentially harder to manage: a single inconsistency cascades across every component. Dark as default reduced scope, created a clean baseline, and preserved the ability to add light theme later without rebuilding anything. Token Studio was configured for automatic light/dark switching from day one.
Four-layer token stack, global · brand · theme · component
Four-layer token architecture
The architecture runs four layers deep. Global holds raw primitives: colors, sizes, radii with no semantic meaning attached. Brand sits above it, carrying overrides specific to KTO or any future brand. Theme handles light and dark, the only layer that can override anything below it. Component sits at the top and stays neutral, it never knows what brand it's on, which is the whole point.
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 five variants 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
Three of the highest-stakes surfaces in the product were designed and delivered through the system: Register Flow (the highest-traffic surface in the logged-in product), My Account (full redesign), and RG Limits (designed, componentized, and handed off entirely within ACE).
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.
Button component, Primary, Secondary, Branded, Ghost, Icon variants
05 · Impact
Register Flow, My Account, and RG Limits, the three most critical logged-in surfaces, were all delivered through the system. Org-level commitment was real: the Head of Product set a Q4 deadline, opened a dedicated channel, and gave ACE executive visibility and a formal mandate. It wasn't a side project.
The token pipeline is running and the dark/light switching is architecturally ready. When the business opens brand two, the system won't need to be rebuilt.
These metrics are estimates based on team feedback and comparative delivery time on surfaces built through ACE. Design systems are hard to measure precisely; these reflect the direction, not the decimal.
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, so 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, which 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 (draft, beta, stable) earlier and communicate it explicitly so teams could self-serve that call.
07 · What's Next
ACE is a live, growing system. The foundation is done, but the work isn't.
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.