The Hard Part Isn't Building the Design System

Design systems have become a core part of modern product development. They help teams move faster, build consistent user experiences, and make the relationship between design and engineering more efficient.

Most of the tools and writing around design systems assume a fairly narrow starting point, though: one product, one brand, one platform, one team. In that world, defining a color palette, setting typography, and building a handful of reusable components is enough.

Real product organizations are rarely that tidy. More often, one service's functionality gets split across separate applications by persona: a passenger app, a driver app, an internal operations console, each owned by a different team, on a different stack, expected to feel like one product. Add web, iOS, and Android being built in parallel, and it gets harder still.

The challenge is no longer creating components. It's keeping design decisions consistent across products, platforms, teams, and time. That's the problem Chassis was built to solve.

What holds a design system together

A design system is more than a UI library of reusable components. It's the infrastructure connecting three layers: design tokens (the raw values, like color, spacing, typography, radius, shadow), the components built from them in Figma and in code, and the process that keeps all three in sync as the product changes.

Get that right, and design and engineering share one vocabulary. A component's name, behavior, and purpose mean the same thing to everyone touching it, and moving a decision from design into code stops being a game of telephone. Small projects manage this without much effort. It gets progressively harder as the number of products, platforms, and brands grows.

Where it breaks down at scale

Growth rarely comes from building more components. It comes from supporting more variation.

Web, iOS, and Android can share a brand identity, but each platform comes with its own conventions and constraints. Colors and typography usually stay shared, since they represent the brand. Component sizing, spacing, and interaction behavior often can't.

Add multiple brands running on the same infrastructure, each with its own palette and visual identity, and the goal changes. Instead of a separate system per brand, you need one shared infrastructure that still supports what makes each brand distinct. Multiple products sharing that infrastructure, each with its own user needs and business logic, multiplies the same tension again.

Small disconnects that compound

None of these problems show up all at once. They build up over time, one small gap at a time.

Color is usually one of the first things a design system defines, and one of the first things that starts drifting as the system grows. What one team calls "disabled button" ends up a shade off from another team's version, and differences like that eventually surface as visible inconsistency in the product.

Dark mode meaningfully raises the complexity of a design system. Every color needs a correctly defined light and dark counterpart, and any missing or incorrect mapping shows up as a contrast, accessibility, or consistency bug.

Visual assets are just as much a part of a design system as components are. Preparing, updating, and distributing them in the right formats for different platforms is usually its own process, and when that process is manual, it becomes a steady source of errors.

Design and code drift apart too. A Figma file gets updated and the code never catches up. A new component gets designed and engineering builds something different from it. Eventually the design file and the shipped product represent two systems that happen to share a name.

The real problem: decisions get scattered, not lost

Platform differences, brand and app needs, dark mode, asset management, and drift between design and code look like a set of separate problems. Underneath, they share one root cause. Design decisions end up scattered across different tools and different teams.

A color decision lives in Figma. Its counterpart lives in CSS. Another version lives inside the mobile apps. Another lives in a brand guidelines document somewhere. Over time, teams stop working from one system and start reconciling several different ones, and the shared language a design system is supposed to provide quietly falls apart.

The decisions aren't lost. They're just scattered across more places than any one team can track.

How Chassis actually solves it

Chassis doesn't approach this by building another component library. Building a new button or card is not a hard technical problem. Keeping that button, and the decisions it's built from, consistent across every platform and team using it, is.

Tokens are the source, not a byproduct

Most design systems start with components; tokens get generated afterward, retrofitted to match whatever the components already do. That works fine for one app or brand. It breaks the moment there are two, because the components stop being the source of truth and start being a translation layer, forked per app, re-implemented per platform. Chassis inverts that: tokens are the single source, and everything else (Figma variables, web styles, iOS and Android code) is generated from them automatically. Change a token once, and it flows to every platform from the same place.

One library, many modes, not many libraries

The common fix for multi-app, multi-platform, multi-brand is forking: a components library per platform, a token set per app. Chassis keeps one token source and one component library, and treats brand, theme, and app as selectable modes instead of separate codebases. Building for one specific brand, app, and platform just means selecting those modes, not maintaining a separate copy of the system.

Design works the same way. A designer switches modes inside a single Figma file to preview a different brand, theme, or platform, instead of opening a different file for each combination. The architecture grows by configuration rather than by forking, so design and code stay in lockstep because both are structured around the same modes, generated from the same source.

No translation layer between design and code

In Chassis, the name a designer gives a color in Figma is the same name used in the web styles and in the native iOS and Android code. That part matters more than it sounds. Most design systems stop at the browser, treating mobile as someone else's problem to reimplement by hand later. Chassis generates all three from the same source, so a design decision doesn't get re-translated, re-named, or approximated on its way to a phone. It just shows up there, already correct. Instead of synchronizing separate implementations, every platform simply consumes the same decisions.

Those three decisions show up as five packages, each responsible for one piece of the architecture but generated from the same source:

• Tokens holds the source values everything else is generated from.
• Figma is a component library bound to the same token definitions.
• Assets distributes images, fonts, and illustrations across brands and platforms.
• CSS generates classes from tokens, matching Figma in name and look.
• Icons optimizes source SVGs and compiles them into an icon font and SVG sprite.

Each package works fine on its own. Used together, they close the gap between a design decision and its implementation.

If you're evaluating whether this fits your stack, Tokens is the best place to start. Everything else in the system builds from it.

The code for all five packages is public under Chassis on GitHub. Issues, questions, and pull requests are welcome. This is early, and feedback from people actually building with it will shape where it goes next.