Cabbin
Made for
Cabbin
Location
Dubai, UAE
Year
2026
what it is
Cabbin is an AI-native marketplace inspired by real needs and behaviors I observed during my years in aviation. I’m using AI to take the whole product from concept through strategy, design, and code - turning an idea into a working MVP. Let me tell you about it.
Shopping local, but anywhere
Cabbin (as in Cabin Crew) is - you’ve guessed it - totally inspired by the aviation lifestyle. During my own time in #crewlife, I discovered a cool little privilege of living borderless: real frequent travelers have their own way of shopping local. They get their groceries from Germany, their cosmetics from Korea, their beachwear from Brazil, their supplements from Australia. I think that’s fabulous. And I want to let everyone in on it.
So I started building Cabbin: a community marketplace where frequent travelers can bring back and share their favorite finds from around the world. And why have things shipped halfway around the world by a company, if someone is going there anyway?
For now, Cabbin is invite-only, because the MVP is built around the very thing that makes this idea work: community and trust.
BUILDING CABBIN
The obsessive animal in me wouldn’t start building a single thing without carefully defining the scope first. This was as much for the AI as it was for myself, as I wanted to maintain a record of good enough product context to make good decisions throughout.
The idea was to create a Project Knowledge base. I wrote an MVP Spec Sheet to map out absolutely all the V1 features and flows, including Admin actions and Analytics Dashboard. Yes, I’m thinking about the metrics I’d want to track for future iterations. AI also nudged me into writing additional documentation: architecture, data model, request state machine, API behaviors and database schema. I fed all these into the Knowledge Base. Some of it turned out useful, some of it became obsolete surprisingly quickly. You build and you learn.
Then I built the wrong thing. I initially committed to Lovable for the product build. It was a fast way to get moving, particularly with its Supabase integration, but the repo structure became messy. More importantly, I realised I was letting the AI decide too much about how my project itself was organised.
I ditched the build and started again, having decided that I needed to own the repo architecture first: I created the GitHub repository structure myself, and separated the product from the design system from the beginning. That reset turned out to be one of the most useful decisions I’ve made on Cabbin. Now, I could give it a structure, rules and a body of knowledge — and ask AI it to work inside them.
SUPER TIDY AI-NATIVE DESIGN SYSTEM
I knew right away I wanted to have full control of Cabbin’s UX and UI. I also knew I didn’t want to design the entire product before writing any code. I had already designed the landing screen and established the first Cabbin brand colors in Figma. I also had a small collection of Figma Variables: primitive and semantic tokens. That was nowhere near enough to design an entire product, but it absolutely was enough to establish its visual direction.
So I gave Claude my Product Specs and asked a different question: if I want to build this product with AI, what should a world-class, AI-native design system look like? And how can I build the smallest possible system capable of supporting the next product decision, then let real product usage evolve that system, through an AI workflow?
Plus, I had a bigger ambition for the Cabbin Design System: I didn’t want it to belong to Claude, or even to Cabbin’s app codebase. I wanted a tool-agnostic (but not framework-agnostic), AI-native system that any AI agent (or human) could pick up, read, use, test, and scale.
So I built the repo architecture itself around this concept: the design system lives in its own independent repository, separate from the Cabbin app. It contains the system principles, AI instructions, token architecture, React + Tailwind implementation rules, components, documentation and a Storybook playground. The Cabbin app then consumes the design system rather than owning its components. This separation creates an intentional gate: a component has to exist, be documented, tested and human-reviewed in the Design System before the product can confidently use it. You can read all about it in my Design System Case Study.
Also, in the spirit of not reinventing the wheel, I wanted my system to be built on Google’s Material 3 Expressive principles. That means I review, fix, test, and implement each new component as I build them, scaffolding the Design System as I go. If I had to describe it, I’d say “Cabbin is a React Design System based on Material 3 Expressive principles, implemented with Tailwind CSS and Cabbin-owned tokens”. If we ever meet, I’ll be proud to tell you all about it.
FROM PRODUCT ROADMAP TO INTERDEPENDENT SPRINTS
Knowing how software is built at scale, I wanted this build to feel like a real product development process, even though I’m doing it without an engineering team. Using the Product Specs and the dependencies between features, Claude helped me decompose Cabbin into a sequence of independently buildable and testable increments.
I landed on 11 Epics covering the entire Cabbin experience, from Pre-Authentication, Onboarding & Account Activation through the Dashboard, Authenticated Flows, Notifications, and Admin. The rule was simple: a sprint isn't finished until the whole slice can be tested, including authenticated states, edge cases and negative cases.
I’m currently at sprint 5, and this has worked really well so far. The design system evolves at the same pace as product complexity.
So that’s Cabbin. It started with an observation from my life in aviation, and it has turned into a marketplace, a design system, an AI-native development workflow, and overall a rather ambitious experiment in how much one curious designer can actually make.
