monday.com
Vibe Design System
Scaling a shared UI foundation across hundreds of developers and designers.
No relation to vibe coding — the name predates it.
Vibe Design System is monday.com's shared interface foundation. My work focused on the layers between foundational components and real product experiences: reusable compositions, domain-specific UI libraries, migrations, floating UI infrastructure and the tooling needed to make consistency practical at organizational scale.
- developers & designers using the system
- 500+developers & designers using the system
- core design system components
- 60+core design system components
- shared UI components across the organization
- 300+shared UI components across the organization
- adoption of major versions
- 95%adoption of major versions
- bundle-size reduction
- 40%+bundle-size reduction
These describe the system and its reach across the organization. A shared foundation at this size is the work of many teams — mine was the infrastructure, the layers above the primitives, and the tooling that kept them coherent.
01Problem
Consistency doesn't scale by itself.
A design system can provide primitives, but large product organizations quickly develop another layer of complexity. Teams need domain-specific patterns, microfrontends evolve independently, component APIs accumulate requirements, and even small inconsistencies become expensive when repeated hundreds of times.
The challenge wasn't only maintaining a component library. It was creating an ecosystem where teams could move quickly without fragmenting the product experience.
02System
System
Every layer exists so the one above it has less to decide.
System map
Foundations
tokens / primitives
Vibe Design System
60+ shared components
Compositions
reusable product-level patterns
Domain UI libraries
team / domain-specific shared UI
Microfrontends
product experiences
Shared UI metadata
MCP / skills / agents
AI-assisted product development
both paths consume the same shared UI layer
Domain-specific UI libraries were connected to monday.com's AI infrastructure, allowing internal tooling, MCPs, skills and agents to understand and compose shared product UI primitives rather than treating frontend code as an opaque implementation detail.
As the internal AI tooling evolved, those libraries became part of the interface between product infrastructure and AI. Shared components could be exposed through MCPs, skills and agents, so tooling could reason about UI that already existed instead of generating disconnected interfaces from scratch.
03Compositions
The layer between primitives and products
I led the internal compositions layer and the component libraries built on top of Vibe Design System.
The goal was to avoid forcing every product team to independently rebuild the same higher-level UI patterns, while still giving domains enough flexibility to model their own workflows.
Interaction model
button ≠ product pattern
Design-system primitive
Button, Menu, Field
Domain behavior
what this team's UI does
Product state
loading, empty, permissions
Reusable composition
owned by the system, shaped by the domain
04Migrations
A design system only works if people actually move with it.
New components were only part of the work. Keeping the interface consistent also meant moving existing product surfaces forward as the system evolved.
Migration strategy became a first-class engineering concern: how to introduce major versions, modernize APIs and implementation details, preserve product behavior, and still make adoption realistic for hundreds of engineers.
95%
major-version adoption
I wrote about how we approached it
How to Ship a Major Version People Actually Upgrade To
monday.com Engineering — 2026
Retrospective model
New system version
major release
- 01Compatibility analysis
- 02Migration tooling
- 03Adoption tracking
- 04Team support
- 05Cleanup of legacy APIs
repeated for every major version
05Floating UI
When everything floats, everything has to coordinate.
Modern product interfaces contain many independently rendered floating elements: menus, popovers, tooltips, dialogs, dropdowns and contextual surfaces.
Treating each one independently creates stacking, focus, positioning and interaction conflicts. Part of the infrastructure work involved giving these elements a shared behavioral model rather than solving the same problem repeatedly inside individual products.
Architecture overview
Shared floating UI infrastructure
stacking / focus / positioning / dismissal
06Performance
Shared UI has a multiplication effect.
Performance work inside a shared component system compounds across the entire product. Modernizing the library therefore included measuring the cost of individual components rather than treating bundle size as a downstream application problem.
Component-level bundle checks became part of the system, contributing to a reduction of more than 40% in bundle size.
System map
Component
one implementation
Bundle check
measured at component level
Shared library
published to the organization
hundreds of product surfaces
07Collaboration
Design and engineering as one system
The work required daily collaboration with designers and product teams. Component APIs, visual behavior, composition boundaries and migration decisions were rarely purely technical or purely visual.
Product requirements continuously fed back into the system, while the system created constraints that helped the wider product stay coherent.
System map
Design
System
components, APIs, constraints
Product teams
requirements travel up, constraints travel back down
08Outcome
Outcome
- 95% adoption of major versions
- 60+ design-system components
- 300+ shared components across the organization
- Infrastructure serving roughly 500 developers and designers
- 40%+ reduction in bundle size
- A compositions layer and domain libraries between primitives and products
- A tighter connection between UI infrastructure and AI tooling
The interesting part wasn't any individual component. It was designing the system around the components so that consistency could survive scale.