genui-ds: A Design System Shaped by the Products That Use It

I knew fairly early that I was going to build several products — CTXDEX, BloomSpec, Twindexers, and probably more after that. So rather than let each one grow its own buttons, spacing, tables, empty states and visual language, I wanted a shared foundation from the beginning.

There was some history behind that instinct too. Years ago, I worked on a Unified UI initiative for a large enterprise client with many products. The problem was familiar: how do you give multiple products a consistent experience and reusable component foundation without forcing them all to look the same?

That became genui-ds — a design system I could use across my own products, learn from in practice, and keep extending as new surfaces and new product needs appeared.

Shared structure, independent identity

The core idea is simple: components should not decide their own colours, spacing or visual identity. Those decisions live in tokens, and components consume semantic meaning instead of hardcoded values.

The system follows three layers: primitives → semantic tokens → platform output. That lets one product feel distinct from another while still speaking the same underlying UI language.

Today genui-ds supports six theme identities across light and dark modes, with a rule I particularly like: new themes can be added, but existing ones are not silently changed. That makes it much safer for a shared system to support several shipped products at once.

More elegant theme delivery

I also wanted themes to be handled cleanly rather than as a pile of runtime overrides. So theme delivery is designed for server-rendered products too: the first paint can already be correctly themed, and runtime switching layers on top of that when needed.

That matters because consistency is not only visual. It is also about predictable behaviour, accessibility, and a product company being able to add a new identity without reworking every component.

The products it runs on

Three of my own products use genui-ds today, and a fourth is queued behind them.

• Twindexers
  The synthetic enterprise twin. Its Metrolane Day-0 Explorer is the newest consumer, and the one that taught me to check a reported cause before implementing it.

• CTXDEX
  The synthetic AI model and pricing universe. Its dense catalogue and pricing surfaces are where components such as ValueAbsence and RateSetGroup came from.

• BloomSpec
  The first consumer, and still the largest at around a thousand pages. It found the bundle-size and responsive-layout defects.

• Zyndeck — planned
  No public site yet. The next product due to move onto the system.

Each one pushes on a different part of the system, and each one has changed it.

The products became the real test

This is the part that made the project more interesting than I expected. A design system can look perfectly fine in Storybook. Then a real product uses it across hundreds of pages, dense tables, long navigation structures and awkward edge cases — and something breaks.

BloomSpec exposed bundle-size and responsive-layout problems. CTXDEX uncovered semantic and typography issues. Twindexers produced the most useful lesson: some reported problems were real, but the proposed causes were wrong.

That led to a rule that now matters as much as any component API: a consumer finding is evidence to investigate, not an instruction to implement. The feedback loop — and the discipline of verifying each finding against the source — has shaped genui-ds more than any isolated design review.

Components appear for real reasons

The system currently has 66 web components, but the interesting ones are not necessarily Button, Dialog or Tabs. They are components such as ValueAbsence, TermMark, RateSetGroup, DerivedValue, PendingRegion, ChargeRow and BrandLockup — pieces that exist because real products needed a distinction that a generic library usually ignores.

That is how I want the system to evolve. And later, as I build more conversational and agent-oriented products, I expect another set of components to emerge from those needs too.

Deliberately incomplete

genui-ds currently has six packages defined, but only two are built and published. The mobile, chat and conversational UI packages are still scaffolding. That is intentional — I would rather wait until a real consumer exists than build speculative components nobody uses.

There is technical debt too. The web package still does not have the unit-test suite it should have, and that remains one of the most important hardening tasks ahead.

Where it is now

genui-ds is built and continually being enhanced based on the needs of new products. It is operational today, used by three of my own products, and keeps improving each time a consumer pushes it a little further.

What I value most is not the number of components or themes. It is the loop: every product that uses genui-ds teaches the design system something, and the design system in turn makes the next product easier to build.

The real project is not just the library. It is the shared language, the discipline around change, and the way each new product makes the design system better.