How Milda works

Milda is structured as a classic three-stage compiler. Understanding that shape explains nearly every design decision in the product.

#The pipeline

visual editor   →   IR (canonical model)   →   generators   →   targets
(FRONT-END)         (single source of truth)    (BACK-ENDS)      React · Figma · …

Each stage has one job, and the boundary between them is strict. That strictness is what lets one design system reach many platforms without forking.

#Front-end: the editor

The Studio is the authoring surface. You compose components, define foundations, and wire up behavior visually. Crucially, the editor's data model is the IR itself — a thin view over the canonical model, not a separate editor state that has to be translated. There is no impedance mismatch between “what you edited” and “what gets generated.”

#The IR: the single source of truth

The intermediate representation is a platform-neutral description of your whole design system — components, structure, contracts, and foundations. It carries no web-specific concepts: no CSS, no HTML tags, no framework APIs. Anything platform-specific lives in a generator's realization of the IR, never in the IR itself.

Read more in The IR.

#Back-ends: generators

A generator consumes the IR and emits something concrete. The React generator emits self-contained component source plus a shared theme. A new target — Figma, Vue, native — slots in as another back-end without touching the IR or the editor. See Generators.

#Two principles that follow

• The data model is the model. The editor edits the IR directly. No adapter layer means no drift between what you see and what you ship.
• Vertical slice before breadth. The spine is one component going edit → generate → render end-to-end, rather than a complete editor with no generator (or vice versa).