Building a Compose Design System at Scale
Article Summary
Matias Isella from Glovo reveals how they built a Compose Design System that serves multiple apps at scale—without being locked into Material Design. Their API decisions could save you months of architectural headaches.
Glovo's Android team faced a critical choice: how to build a scalable Design System that ensures consistency across platforms while giving teams flexibility to innovate. This deep dive covers their architectural decisions around Material Design, View System support, and API patterns that balance flexibility with consistency.
Key Takeaways
- Replaced Material Design externally but reused components internally for best of both worlds
- Chose Compose-only support to accelerate adoption over maintaining dual implementations
- Used restrictive APIs over slot APIs to prevent component variants and maintain consistency
- Implemented closed styles with enums to ensure exhaustive evaluation and prevent ad-hoc variations
- Leveraged KDoc @sample tags for documentation that doubles as integration tests
Glovo built a production Design System by prioritizing opinionated APIs and closed styles over maximum flexibility, ensuring consistency while still enabling controlled experimentation.
About This Article
Glovo's UX team needed semantic tokens that didn't fit Material Design's standard API. They had to choose between extending Material in ways that would create inconsistencies or building something custom from scratch.
Matias Isella's team swapped out Material Design on the outside while keeping access to Material components internally. They only exposed their custom tokens and components through the public API, which let them match the UX specs exactly.
Glovo used Compose compiler reports with strong skipping mode to keep most Design System components skippable. This prevented unnecessary recomposition and helped maintain performance across their applications.