Migrating CarTrade's component library from an in-house Storybook system to a strict 1:1 Figma to MUI mapping, enabling AI-assisted design-to-code workflows for the entire product team across CarWale, BikeWale, CarTrade and OLX.
For nearly three years, CarTrade Tech ran on Oxygen, an in-house Storybook-based design system that one team had originally shipped to support CarWale. It was a thoughtful, well-engineered library when it launched. The problem was scale. By 2025 the organisation had four consumer brands operating on the same foundation: CarWale, BikeWale, CarTrade and OLX Autos. Each brand had its own product roadmap, its own design vocabulary, and its own velocity expectations.
The symptoms were textbook design system drift. Engineers were re-implementing components that already existed in Oxygen because they could not find them or because the existing version did not cover the variation they needed. Designers were forking patterns into their own Figma files when Oxygen lagged behind new requirements. New hires spent their first month learning a system that diverged from industry conventions, which made the onboarding cost real and recurring.
The deeper, more strategic issue arrived with the rise of AI-assisted coding. Cursor, Claude Code, and Figma's MCP server were starting to reshape how product teams ship features. These tools have orders of magnitude better training data and integration support for MUI and other widely-adopted libraries than they could ever have for a proprietary in-house system. Staying on Oxygen meant locking the org out of the entire AI tooling ecosystem at precisely the moment the ecosystem was becoming a competitive advantage.
The brief from leadership was open ended: get the design system into shape. The path I committed to was specific. Migrate everything to MUI with strict 1:1 Figma to code parity, and design every component to be readable by AI tools.
I spent the first six weeks on a structured audit rather than touching any new design. The migration's success would depend on knowing exactly what we were migrating from, and Oxygen's three years of organic growth meant the surface area was much larger than anyone had a mental model of.
The audit had three parallel tracks. Component inventory mapped every component in Oxygen against where and how it was used across the four product surfaces, which immediately revealed that close to a third of components were either unused, used in a single place, or near duplicates of another component. Engineering interviews with leads across the four brands surfaced the friction points each team had been quietly working around, the kind of operational knowledge that almost never makes it into a doc. Designer interviews captured the patterns designers had forked into their own files and the reasons they had forked them, which became the priority list for what MUI components needed customisation.
The most important output of the research phase was not the inventory itself but the MUI gap analysis: a matrix mapping every Oxygen component against its nearest MUI equivalent, scored on visual fidelity, behavioural parity, and the effort required to bridge the gap. The matrix told us which components were drop-in replacements, which needed custom theming, and which required building extensions on top of MUI. Without this matrix the migration would have been a series of ad-hoc decisions instead of a sequenced programme.
I scoped the migration as a multi-quarter programme with explicit ownership, governance, and a public roadmap. The framing mattered. Design systems initiatives have a well-known failure mode where they become a side project that nobody is fully accountable for and that everyone is happy to deprioritise when feature work gets noisy. We were going to avoid that mode by treating the system as a product with users, a roadmap, and shipped releases.
Three principles guided every decision. First, atomic parity: every Figma component had to have an exact MUI counterpart with matching prop names, default values, and interaction behaviour. Loose mappings break AI generation, and we were not going to compromise the AI workflow to save migration effort. Second, AI-readable output: components needed predictable structure, semantic naming, and clear documentation so that Cursor MCP could read a Figma frame and produce working code without human intermediation. Third, no breaking changes mid-flight: product teams kept shipping on Oxygen while individual components migrated, with feature flags routing usage between the two systems until each component reached parity.
The operating model was a Design System Council that I formed with one senior designer and one senior engineer from each pillar product. The council met weekly, reviewed proposals, owned breaking-change decisions, and had explicit authority to block changes that violated the principles. This single decision did more to keep the migration on track than any tooling we built, because it created a forum where conflicting brand requirements could be resolved with full context rather than escalated up and down chains of command.
MUI over building our own extension on Oxygen. The temptation to keep Oxygen as a parent layer and migrate underneath was real, because it would have preserved some of the existing investment. I argued against it on two grounds: hiring in 2025 is heavily skewed toward MUI fluency, so any new designer or engineer we hired would be slower on a proprietary system, and AI tools have orders of magnitude better support for MUI. The right move was to accept the migration cost rather than carry the proprietary tax forward.
Strict 1:1 Figma to code mapping, even when it slowed us down. Many design systems use loose mappings where a Figma component approximates the code component. This works for human designers and breaks AI generation, because the AI tool has no way to know which code component a given Figma frame corresponds to. We committed to exact mappings with matching names, props, and structure. The upfront cost was significant but the downstream payoff in AI workflows justified it within the first quarter.
Governance through the Design System Council. I have seen too many design systems fail not because the technical work was wrong but because cross-team disagreements festered into open splintering. The Council made breaking-change decisions explicit, time-boxed, and reversible. Brands could appeal a decision but had to accept that the decision had been made.
Documentation as a first-class deliverable. Every component shipped with usage guidelines, do/don't examples, and AI-readable metadata. Documentation is the most consistently neglected part of design systems work because it does not produce a visible artifact. We treated it as part of the definition of done.
Reading Figma, writing MUI
The migration is ongoing, with primitives and the most-used patterns now in production across the four brands. The most visible outcome is engineering velocity on new features when teams are using components that have reached MUI parity. Without quoting specific numbers, the qualitative feedback from engineering leads has been consistent: building on the migrated components feels meaningfully faster than building on the equivalent Oxygen components ever did.
The second visible outcome is on the hiring side. Job postings for designers and engineers can now reference a stack that candidates recognise, which has materially improved the quality of applications we receive. Several candidates have specifically called out the AI-ready system as a reason they were interested in the role, which is a hiring signal that did not exist before.
The most lasting outcome is cultural. The design and engineering organisations now share a common vocabulary about components, tokens, and patterns. Where designers used to hand off Figma files and engineers used to interpret them, both sides now work against the same component library with the same names. Onboarding new designers no longer requires a week of Oxygen orientation. The system has become something teams want to use rather than something they are required to use.
If I were starting over, I would invest more in the migration toolchain on day one. We built it incrementally as needs surfaced, which meant some early-migrated components had to be redone when our tooling matured later. A two-week upfront investment in tooling would have saved a quarter of rework downstream.
I would also socialise the AI workflow earlier. Designers and engineers needed to see Cursor MCP generating working code from a Figma frame before they truly understood why the strict mapping discipline mattered. Once they saw it live, scepticism turned into advocacy almost overnight. The lesson, and one I now apply across systems work, is that demos beat decks every single time. A two-minute video of the AI workflow on a real component was more persuasive than the months of written argument that preceded it.