A grocery-delivery app (20M users) rebuilt on a design system I made from scratch. Read this for design systems and getting a whole team to adopt one.
During my last nine months at Snapp Express I led two efforts that fed into each other: Broccoli, a design system built from scratch, and Blossom, a full rebuild of the customer app on top of it, with zero backend changes. This wasn’t a fresh coat of paint. It was clearing years of design debt under live product constraints, and it taught me how to bring structure to chaos, align teams quickly, and scale design in a way that made shipping easier, not just prettier.
Why We Needed Broccoli
When I joined there was no real system, just fragmented files, one-off components, and flows that contradicted each other. Every designer worked in their own style, developers rebuilt the same UI again and again, QA cycles dragged, and PMs couldn’t tell what was actually shipping. On top of that, redesigning the app was a team KPI, so the clock was already running.
I proposed a real design system and called it Broccoli, but the goal was never just nicer visuals. It was to fix the process that kept producing the mess. The bet was simple: if components carried their own rules, the team would stop re-deciding the same things on every screen.
How I led it: I audited what existed and what didn’t, reused whatever was salvageable to move fast, and built the foundation from there, tokens, spacing, and color, structured along Material lines so it would scale and feel familiar to engineers. Then I ran a dev kickoff so the team saw it as something that saved them time rather than added process. Most developers were already on board, more frustrated with the status quo than I was. PMs were the skeptics, right up until the first rebuilt screens showed up and the argument made itself.
I proposed a real design system and called it Broccoli, but the goal was never just nicer visuals. It was to fix the process that kept producing the mess. The bet was simple: if components carried their own rules, the team would stop re-deciding the same things on every screen.
How I led it: I audited what existed and what didn’t, reused whatever was salvageable to move fast, and built the foundation from there, tokens, spacing, and color, structured along Material lines so it would scale and feel familiar to engineers. Then I ran a dev kickoff so the team saw it as something that saved them time rather than added process. Most developers were already on board, more frustrated with the status quo than I was. PMs were the skeptics, right up until the first rebuilt screens showed up and the argument made itself.
Rebuilding the App with Blossom
Once Broccoli was stable we rebuilt the entire customer-facing app on top of it. That phase was Blossom, and its defining constraint was deliberate: we didn’t touch the backend. The data layer and product logic already worked well, so the whole effort went into UI, flow, and development speed. Scoping it that way is what made a full rebuild feasible at all. It kept the risk contained and gave engineering a clean, mechanical migration instead of a rewrite.
I personally rebuilt around 90% of the screens in Figma using only Broccoli components, no one-offs, and worked closely with the developers so each design mapped directly to clean, reusable code. To get leadership behind it, I pitched a short, sharp deck: before-and-after screens, the time it would save in QA and dev, and how teams like Airbnb and Shopify treat their systems. It worked. The CPO and CTO backed it fully.
I personally rebuilt around 90% of the screens in Figma using only Broccoli components, no one-offs, and worked closely with the developers so each design mapped directly to clean, reusable code. To get leadership behind it, I pitched a short, sharp deck: before-and-after screens, the time it would save in QA and dev, and how teams like Airbnb and Shopify treat their systems. It worked. The CPO and CTO backed it fully.
What the Rebuild Looked Like
With the system in place, the rebuild became less about invention and more about consistency. The home and vendor pages were the highest-traffic surfaces, so they went first, and rebuilding them entirely from Broccoli components proved the system could carry the real product, not just a tidy demo. Every fold reused the same tokens and components, which is exactly what let the team move quickly once the foundation existed.
The harder part was adoption, not construction. A system only pays off when people actually pull from it, so I kept it close to production, documented the decisions so engineers could extend it without me, and let the early screens do the convincing. Once a developer could ship a screen by composing components instead of rebuilding them, Broccoli stopped being my project and became the team’s default.
The harder part was adoption, not construction. A system only pays off when people actually pull from it, so I kept it close to production, documented the decisions so engineers could extend it without me, and let the early screens do the convincing. Once a developer could ship a screen by composing components instead of rebuilding them, Broccoli stopped being my project and became the team’s default.
First and Second Scroll Folds - Vendor Page and Home Page
What I Learned
I was running the system and the redesign at the same time, which meant managing PM expectations, building components, shipping product features, and holding quality together all at once. My team lead backed me and one teammate helped maintain the system, but I drove most of it end to end.
If I did it again: I’d narrow the system’s scope to the main shopping product first instead of trying to cover the seller and operations products too early. I’d push for more motion and flexibility, since the result was clean but a little rigid. And I’d share progress more publicly as it happened, so adoption could spread across the org faster than it did.
If I did it again: I’d narrow the system’s scope to the main shopping product first instead of trying to cover the seller and operations products too early. I’d push for more motion and flexibility, since the result was clean but a little rigid. And I’d share progress more publicly as it happened, so adoption could spread across the org faster than it did.
Results
⏱ QA time dropped from 3 days to under 1, once every screen pulled from one source of truth
🔨 ~90% of the app rebuilt by me, entirely from system components
🤝 Developers stopped rebuilding components by hand and composed screens from the library instead
💬 Designers moved faster with fewer handoff questions, because each component carried its own usage rules
🔨 ~90% of the app rebuilt by me, entirely from system components
🤝 Developers stopped rebuilding components by hand and composed screens from the library instead
💬 Designers moved faster with fewer handoff questions, because each component carried its own usage rules
Presentation Link
🔗 Here you can read all the presentation file