Web Direction Code: Micro FrontEnd at Scale by Mecca

Shabnam and I presented at WebDirection Code about micro frontends at Mecca. It was a chance to share what our engineering team built over the past few years -- and what we learned the hard way.

The problem we solved

Mecca's frontend started as a monolith. One repo, one build, one deployment pipeline. As the team grew, this became a bottleneck. Every feature change required coordinating across teams. A bug in one feature could block deployment of everything else. CI took forever.

We moved to a micro frontend architecture. Each team owns an independent frontend application with its own repo, build pipeline, and deployment cycle. These apps compose together to form the user-facing product.

I started the talk by asking the audience how many had worked with micro frontends. Less than 20% raised their hands. This architecture is still uncommon, but for organizations at a certain scale, it solves real coordination problems.

What Shabnam covered

Shabnam, the technical lead, walked through the real challenges: shared dependencies, consistent styling across apps, routing between micro frontends, and authentication state management. She also shared our roadmap for improving the architecture.

The trade-offs

Micro frontends solve organizational scaling problems. Independent teams can ship independently. But they introduce technical complexity: shared state management, bundle duplication, inconsistent UX if teams drift apart, and more infrastructure to maintain.

A monolithic frontend is simpler to build, test, and deploy -- until it isn't. If your team is small and your product is focused, a monolith is the right choice. Micro frontends are an investment that pays off when you have multiple teams that need to move at different speeds.

Watch the talk

The full presentation was published on Conffab. If you're considering micro frontends for your organization, it covers the practical realities that blog posts usually skip.