A design system for 30+ brands, and a client who came back

In 2022 the product was white-label: more than thirty construction companies each got their own colors, logos and imagery. With that many brands, the product could not work without design tokens. Implemented naively, a hundred components for thirty brands would mean three thousand variants that nobody would maintain.

In 2025 the app could no longer be installed on current Android versions, because its libraries had been abandoned and the APIs it relied on were deprecated. An app in that state disappears without an error: new users simply cannot install it, and existing users lose it the moment they change phones. At the same time, a large share of the phones on a construction site are several years old, so the fix could not leave them behind.

The design system (2022, alone). I exported the design tokens from Figma into JSON, generated SCSS from them and built about a hundred components on top, organized by size, type and kind. The library is versioned and distributed as a package, with its own documentation.

No component knows its own color, only the name of a token. A new client is a new set of values, not new code, and that is what keeps thirty brands maintainable.

I made the library framework-agnostic on purpose, because two different products use it. Tied to one framework, it would force every consumer outside that framework to build its own implementation of the same design, which is the problem a design system exists to solve.

With a hundred components, the organization by size, type and kind has a practical purpose. Without consistent organization, a library that size turns into a search through file names: a developer who does not find what they need in thirty seconds concludes it does not exist and writes their own CSS, and the design system ends up bypassed without anyone deciding to drop it.

The Android app (2025, three of us). We got the app running again on both current and older devices. We brought camera permissions into compliance after a store policy change, upgraded the dependencies used for viewing documents and moved work off the main thread.

• ~100 components carrying 30+ white labels, built solo in two months
• A versioned package with documentation, used by two products
• The Android app installs and runs again on both new and old devices
• The same client, back after three years, on an unrelated discipline

The documentation was custom-made, without a standard tool, so it became one more thing to maintain and one more thing every new developer had to learn. For a library that thirty brands depend on, I would choose a standard documentation tool, even though it is the boring option.