Micro-Frontends in the Real World: Lessons from an Enterprise Government Platform

Why micro-frontends?

When a platform grows beyond a single team, a single Next.js app becomes a bottleneck. Micro-frontends let teams ship independently — but they come with real costs.

What worked for us

1. A shared design system first. Before splitting apps, we built reusable components with Tailwind CSS and Storybook. Consistency across modules became free.
2. Clear module boundaries. Each micro-frontend owns a business domain, not a page. Cross-domain features go through explicit contracts.
3. A monorepo. Shared tooling, one CI pipeline, atomic cross-module changes.

What to watch out for

• Dependency drift — pin shared dependencies, or two modules will ship two React versions.
• Routing seams — navigation between modules must feel native; invest in a shell router early.
• Over-splitting — if two modules always change together, they are one module.

Takeaway

Micro-frontends are an organizational tool, not a performance one. Adopt them when team scaling hurts, not because they are trendy.