Micro-Frontends: Building UI at Scale

The Core Idea

A micro-frontend architecture breaks a large web application into smaller, independently developed and deployed UI modules. Each team owns a vertical slice of the product, from database to user interface. This aligns naturally with domain-driven design and Conway's Law: your architecture will reflect your organisation.

The benefits are real:

• Teams can deploy independently without coordination overhead
• Technology choices can vary per team
• Failures are isolated — a broken module does not take down the whole application
• Codebases stay focused and manageable

The Hidden Challenge: UX Fragmentation

This is where micro-frontends often stumble. When each team builds their own UI in isolation, you quickly end up with an inconsistent user experience — different button styles, different spacing, different interaction patterns, different colour palettes. The product feels stitched together rather than designed.

The solution is not to constrain team autonomy, but to invest in shared foundations.

Design Tokens and a Shared Component Platform

The key enabler is a well-maintained component platform. This is not just a component library — it is a living design system that teams consume as packages. It includes:

• Design tokens: the single source of truth for colours, typography, spacing, and motion. Defined in Figma, exported and distributed as code. When a brand colour changes, it changes once and propagates everywhere.
• Components: you do not need to build these from scratch. Wrap established third-party libraries such as PrimeNG and apply your design tokens through their theming system. You write minimal logic and get battle-tested behaviour in return.
• Documentation: Storybook as the interactive catalogue, including searchable fonts and icons backed by a library that makes it easy to import exactly what you need. Developers can browse and integrate without guessing.

UX Leadership Must Span Teams

This is the part that is easy to miss. If you distribute UI responsibility across teams without someone owning the experience end to end, you will still end up inconsistent — just inconsistently following a design system.

You need a UX responsible who operates across all teams, not embedded in any single one. Their job is to own the Figma workspace, review component proposals, set interaction standards, and guide teams when edge cases arise.

Without this role, every team will make reasonable local decisions that add up to a disjointed global experience.

Development Becomes Like Lego

When the platform is mature, building a new page becomes assembly work. A product team picks up pre-approved, pre-tested components. The layout was sketched in Figma, reviewed by the UX responsible, signed off by stakeholders — before a line of production code was written.

This is opinionated development, and it is powerful:

• Less decision fatigue for developers
• Fewer review cycles on UI details
• Faster time to production for new features
• Higher confidence that the result matches the design
• Significantly better AI-assisted development — when your component library is available to an AI coding assistant, it can compose pages using your actual components rather than generating arbitrary markup. The result is consistent with your design system from the first suggestion.

A Practical Workflow

A healthy micro-frontend workflow looks like this:

• Feature is defined; a Figma design is produced using existing design tokens and components
• UX responsible reviews for consistency with the overall experience
• Stakeholders review and approve the design
• If new components are needed, they are added to the component platform through a proper review cycle
• Development teams implement the page by composing the approved components
• The result is predictable, consistent, and maintainable

Concerns to Keep in Mind

Micro-frontends are not free. The costs include:

• Bundle size: if each team ships its own framework runtime (or worse, different versions), users download the same code multiple times. Module federation or careful shared dependency management is essential.
• Cross-cutting concerns: authentication, error boundaries, analytics, and routing all need coordination. These should be handled at the shell level, not duplicated.
• Authentication and authorisation: who owns the identity layer? Tokens need to be acquired, stored, refreshed, and passed consistently across all modules. If each micro-frontend handles this independently, you get diverging behaviour and security gaps. A shared auth service or shell-level token management is a must.
• Data distribution: modules often need overlapping data — user context, permissions, feature flags, shared domain state. Without a clear strategy (shared store, broadcast events, or a common API layer), modules end up making redundant requests or holding stale, inconsistent state.
• Platform investment: the component library and design system require dedicated maintenance. This is not a side project — it is infrastructure.

When It Works Well

Micro-frontends make the most sense for large organisations with multiple product teams working on a shared application. The investment in shared tooling pays off when the alternative is a monolithic frontend that has become a coordination bottleneck.

For smaller teams or earlier-stage products, the overhead is often not worth it. Start with a solid component library and a well-structured monolith. Extract when you genuinely need to — not before.