Design systems that travel

Why Paisa had to exist

Paisa, Rupifi’s design system, was born from a scaling problem, not an aesthetic one.

Early on, the products ran on packaged UI libraries. That’s the right call for an MVP. It’s quick, it’s cheap, and it gets you to market. But the moment the portfolio started growing, the library became the ceiling. It couldn’t be customised far enough. It had no answer for the newer features and experiences we were designing. And it gave us nothing to build brand recognition on, since every Rupifi product looked like the same generic kit everyone else was using.

So the team did what every team does without a system. We forced new experiences on top of components that were never meant for them. I call it frankensteining, stitching a UI together from parts that don’t quite fit, and it works right up until it doesn’t. What starts as a shortcut becomes the thing slowing every new product down. A design system stops being a nice-to-have exactly when you start shipping faster than a borrowed library can keep up.

What a system actually buys a lean team

The point of Paisa was never the components. It was speed and consistency at scale. Settle the button, the spacing, the error state once, and the team spends its judgement on the hard, product-specific problems instead of re-deciding the basics on every screen. Consistency also compounds into brand recognition, which a pile of default library components can never give you. And it’s a management artifact as much as a design one, because a documented system is how a new hire reasons about the product without asking someone.

Adoption is where systems live or die

Here’s the part most write-ups skip. Building the system was the easy half. Getting it adopted was the real work.

Engineering had every reason to resist. A new system meant redoing work that already functioned, and “it already works” is a hard argument to beat with “it’ll scale better later.” So I didn’t try to win it with a mandate. I made the long-term cost of frankensteining visible, showed what each new product would keep costing without a foundation, and then removed the friction instead of just asking for buy-in. We documented the whole system in Storybook, and critically, the design team co-owned that Storybook alongside the front-end team. It wasn’t a spec thrown over the wall for engineering to maintain. It was shared infrastructure with shared ownership. That’s what turned it from my initiative into the team’s system.

Figma to code, now with AI

The way I build systems has shifted. Paisa was Figma-first in a traditional pipeline. KuKi, the system behind the app I’m building now, goes from Figma to Claude Code directly, and the gap between “the system is documented” and “the system is true in the codebase” has nearly closed.

The bigger change is who can touch the system. With AI, managing the git of a design system stops being an engineering-only job. My design team can create and merge PRs and publish changes to the system directly from Claude Code, without waiting in a queue. That has made design and engineering collaboration faster and far more seamless than any handoff process I’ve run before. The wall between designing a component and shipping it has mostly come down, and once you’ve worked that way, the old back-and-forth feels absurd.

Live showcase

The panel below is this site’s own token system, rendered live from its stylesheet, not a screenshot. A small working example of the idea: one source of truth, everything else derived from it.