Future-proof design system

An AI workflow to build the product and its design system in the same loop

Made for

Location

Dubai, UAE

Year

2026

what it is

Cabbin is an invite-only, aviation-inspired marketplace. I’m using AI to build the whole product, from concept to shipped MVP. You can read all about it in my Cabbin Case Study. But Cabbin is also an experiment: could I build a genuinely design-forward product without designing the entire thing first — and evolve its design system at the same time?

The conventional design system story tends to look something like: define > design > build > extract > document > maintain.
Or, at the other extreme: prompt AI > generate UI > fix the mess later.

But I wanted neither; I wanted a workflow where the product and its design system could evolve together. I already had enough visual direction to know what Cabbin should feel like: a landing screen, brand colors, and a small collection of primitive and semantic Figma Variables. But I deliberately didn't want to design the whole product before development. That left me with an interesting constraint:

How much Design System do you actually need before you can make the next product decision?

I wanted to spend less time designing screens in Figma and more time designing the system that could produce those screens well. That became an exercise in systems thinking, design governance, AI fluency, and process design. The experiment: build the smallest possible system capable of supporting the next product decision, then let real product usage evolve that system, through an AI workflow.

ARCHITECTURE IS KING

I learned this the hard way. I initially started Cabbin in Lovable (easier Supabase integration) and let the AI establish too much of the project structure for me. The repo quickly became messy, and I realised I was outsourcing an architectural decision I actually wanted to own. So I stopped, started again, created the GitHub repositories myself, and designed the relationship between the product and Design System first thing. So I landed on a workspace with two sibling repositories:

cabbin-ds: the reusable design system.
cabbin-app: the actual Cabbin product.

The app then consumes the design system as a dependency, creating an intentional gate: a component has to exist, be documented and be human-reviewed in the design system before the product can use it. The separation is intentional: if the design system lived inside the app, the easiest path for AI would always be to solve the immediate screen. By keeping it independent, I created friction in the AI workflow: the component has to earn its way into the system before it becomes part of the product's vocabulary.

I also wanted my system to survive the tools used to build it, so each repository has an AGENTS.md: a tool-agnostic instruction layer that tells an AI agent how the project works. "Cabbin-ds" holds documentation covering the system principles, component authoring, token architecture, and a Storybook playground. "Cabbin-app" holds product specs, UI patterns, and sprint planning. This separates design system decisions from implementation details, and the documentation becomes part of the system itself. The token pipeline is also intentionally decoupled from the final implementation: Figma Variables > DTCG JSON > Style Dictionary > CSS/Tailwind. The components are currently React-specific because Cabbin is a React product. But the design decisions underneath them don't belong to React, Tailwind, Figma, Claude, or any particular tool. If tomorrow's AI tool changes, the system shouldn't have to start over.

So, architecture is king: it’s not just where the code lives. It’s the governance structure; it’s how the AI consumes instructions and behaves in the workflow, it’s how the design system gets organized; it’s how product and design system behave together.

DESIGNING THE WORKFLOW

I knew from the start I wanted to have full control of Cabbin’s UX and UI. I also knew I wanted to create a Design System without designing it: I wanted to borrow from proven principles, but still own the design decisions. In the spirit of not reinventing the wheel, I chose Google’s Material 3 Expressive principles to be my component foundation, Base UI for interaction behavior, and the Lucide library for icons. Then I wanted everything to be styled with my design tokens.

The workflow is something like this: I make the next product/design decision > AI reads the relevant rules and checks the existing system > it builds or extends the component > it documents and tests the component, then composes it into the product > I review it in Storybook and in the real browser, and give targeted feedback > AI fixes the underlying cause and documents the decision > I mark the component “stable” > GitHub pull request > CI tests > merge > next sprint item.

New components enter an “in-review” state. They get a Storybook entry, tests and documentation, and I test them both in isolation and in the actual product screen. Until I explicitly mark a component “stable”, the AI isn’t allowed to treat it as trusted vocabulary for future work. So “in-review/stable” becomes a governance mechanism for AI. At the same time, this creates a continuous feedback loop: the product continuously stress-tests the design system and the design system continuously constrains the product.

A SELF-EVOLVING CONSTITUTION

Whenever the project exposes a gap, I turn the gap into a rule. For example, a token missing from Figma became a Figma backfill ledger; a security issue became a requirement for security audits at the end of every sprint; layouting decisions became documented UI patterns. The principle is simple: if the system doesn't know how to handle something, we fix the system. Whenever something went wrong, I could ask: “why did this happen?”. If the answer was “because the system doesn't have a rule for this”, then the fix becomes: new system rule > documentation > future enforcement.

HOWEVER…

AI can make a bad decision very consistently. That's why the governance layer matters so much.

Figma falls behind code. In my workflow, the product can expose a new token need before I have reflected it back into Figma. I do have an explicit Figma backfill ledger to track this “debt”. But hey, do we even need it?

The system can become too specific to Cabbin. Every new product requirement adds to the design system, so the system can slowly become a catalogue of historical requests. That's why every new component begged the question: is this a reusable design decision, or just a solution to a specific problem?

The system hasn't been stress-tested by another product. I cannot yet claim that the whole design system is broadly reusable. However, it is designed for portability.

WHAT AI DIDN’T DO FOR ME

My AI agent is a great second pair of technical eyes. Once a rule is clear, AI applies that rule relentlessly: implementing components and states, creating the .tsx, Storybook story, tests and documentation, running type checks, linting, unit tests, migration checks and builds, debugging, etc. It also catches things I didn't ask for or had no idea about.

But AI definitely didn’t design the product for me, nor did it give me a magic workflow. It can make a super good component, but it doesn't necessarily know whether the component should exist. My highest-value contribution remained: information architecture (what’s the user’s mental model?), cognitive load (what can we remove?), product policy (is a declined application the same as a ban?), responsive behavior (what should the mobile experience actually be?), interaction heuristics (what’s an error, or a warning, or neither?), system strategy (should a missing token become a new token, an existing token, or a change to the underlying scale?). I still find AI is strongest below the level of judgment.

Me: judgment
AI: execution

I like this division of labour. The designer's role moves up the abstraction stack: instead of spending time manually drawing every state, I'm spending time defining the system that determines how those states should be created.

NOT REVOLUTIONARY, BUT PRETTY AWESOME

Using AI to build a design system: not revolutionary. But what I set out to do was to build a product from scratch, without an engineering team, while deliberately avoiding a fully designed product upfront, and building its design system simultaneously. I'm doing that with AI acting as the implementation engine and the design system acting as the constraint/governance layer.

For me, that's the exciting future of AI-native product design: less time producing every interface artifact in advance, more time designing the rules, relationships and constraints that allow the interface to evolve coherently. The AI can turn a relatively small design decision into a working implementation, the product can immediately test whether that decision survives real usage, and the design system can evolve from evidence.

I didn't start with a perfect Design System and then built Cabbin. I started with a product, a few visual decisions, a set of constraints and a question: what is the smallest system that I need to make the next good decision? The product keeps answering that question. The Design System is being designed by the product — with a human still firmly in charge of deciding what the product should become.