Micro frontends: hype or game-changer? How one team cut costs, sped releases, and built scalable apps without chaos.

Hello everyone! My name is Nikita, I am a frontend lead at Exante, and today I want to share our experience implementing a micro frontend architecture. I will tell you how we came to it, what problems it solved, what advantages and drawbacks we discovered, and finally, when micro frontends are actually worth using, and whether they bring more value to developers or to the business.

What Are Micro Frontends and Why Do They Matter?

Micro frontends are an architectural approach in which the frontend of a large application is divided into independent modules — separate micro frontend applications.

Each of these applications is developed independently and follows its own release cycle. They can live in the same repository, but more often they are hosted separately.

The main goal of micro frontends is to divide responsibility, speed up time-to-market, and allow different teams to work and release in parallel.

Our experience implementing microfrontends

The RUN Project

Let me tell you about our project. We have an internal application called RUN, which is used by various departments across our brokerage business.

RUN combines multiple functional areas — back office, CRM, monitoring, role and permission management, reporting, branding, and much more.

We also provide RUN to our external clients as a white-label solution, allowing them to manage their brokerage operations and customize the interface to their needs.

And yes — RUN is, in fact, a large collection of micro frontend applications.

Why We Needed a Micro Frontend Architecture

Initially, we had an entire “zoo” of internal projects for different departments. They were built with different technologies — Angular, jQuery, Vue.js, desktop apps, and Django admin panels.

This variety caused several major problems:

Technology fragmentation. Each project required its own infrastructure and developers with specific skills, which made maintenance expensive.
Lack of shared responsibility. Each team focused on its own product, without a unified vision or shared solutions. Synchronization between teams was difficult, leading to redundant work.
Copy-pasted logic. Without a shared design system, interfaces looked inconsistent and uncoordinated.
Multiple entry points. Each app required separate authentication.

All of this has increased development and maintenance costs.

The business needed a new solution: a single entry point with unified login. Moreover, the application had to be modular, since Exante also provides turnkey white-label solutions.

That’s how the new React-based application with single sign-on was born, where we began implementing core functionality from scratch.

Our frontend team consisted of just three or four developers.

Before we began coding, we created a design system and extracted it into a separate UI kit. But rewriting everything from scratch would have taken years.

So the business asked: Can we integrate the old web apps into the new system as they are, without waiting for the new ones to be built? The only requirement was that both old and new apps must remain independent in terms of releases.

This led us to a setup where multiple micro frontends — even those built with different technologies — could coexist inside one host application.

Legacy apps had their own design systems, but as a temporary solution, this worked for the business. Over time, all apps migrated to React with a unified design and theming support.

Today, our frontend team has grown to ten people. We have rewritten nearly everything, and maintaining legacy apps is no longer necessary.

How It Works Now

Here is how our current setup looks:

A host application (container) that integrates all micro frontend apps.
A UI kit published as a private npm package in our own Nexus registry.
Shared configuration packages for ESLint, Prettier, and TypeScript to keep a consistent code style across projects and make switching between them seamless.
Vite for building everything — both production and development builds are lightning fast. Tree-shaking reduces bundle size, and independent dependencies are not a problem for us.
A single CI/CD configuration template that is easy to maintain.

The host app includes the layout (menu, header, routing, authentication, and user settings). Each route renders the corresponding micro frontend, loaded dynamically from our branding system configuration. The available menu items are determined by user roles and permissions.

Each MFE app is rendered simply: we attach its render function to the global Window object. Every micro frontend is published independently and can even run standalone on its own host.

In the host application, everything is also quite straightforward. We render a component for a specific route and call the useModuleInit hook with the key of the corresponding project.

Inside the host app, we use a React 19 feature — ModuleInit from react-dom, which allows loading external modules natively. Previously, we used to add scripts manually through the Helmet plugin, but that was clunky. Now it’s elegant and simple.

Each micro frontend script loads once, caches after the first request, and is not reloaded when navigating between routes.

We deliberately avoided complex setups like Module Federation or Single-SPA. ModuleInit suits us perfectly without adding unnecessary dependencies or configurations. We do not use a shared store between micro frontends — and intentionally so. Shared writable state adds coupling and reduces flexibility.

If a shared store exists, it should only flow one way: from the host to the micro frontend.

We use CustomEvent for inter-module communication, while other states are either stored in the backend or local storage. Feature flags also live on the backend.

For external clients, we can assemble any combination of apps and features straight “out of the box” — no coding required.

What Micro Frontends Gave Us

Implementing this approach brought us several benefits:

Faster development. By integrating legacy apps as micro frontends, we delivered a unified system in a few months instead of years.
Modern tech stack. We standardized on React, unified our code style, and established a single UI kit. Developers can now easily move between projects, and the business no longer depends on diverse tech skills.
Shared context. The team now owns the product as a whole, reducing fragmentation and duplicated effort.
Independent releases. Each small app is easy to understand, new developers can onboard faster, and fixes can go live immediately without waiting for others.
Simplified CI/CD. We now have a single template for all projects.
Flexibility and scalability. We can assemble or remove apps like LEGO blocks. Setting up a new app takes just a day.
Resilience. If one app crashes, the rest continue working. Rolling back is simple and isolated.

In short, we reduced both development and maintenance costs.

What to Keep in Mind

If your business decides to adopt a micro frontend architecture, make sure to prepare for the following:

Documentation. Create thorough setup guides for developers, QA, and support teams: how to configure, integrate, and deploy new apps.
UI kit. Build a consistent design system to avoid repetitive UI work.
Shared configuration and tooling. Unified linting and TypeScript rules save time and make developer rotation effortless.
Knowledge sharing. Encourage teams to communicate; tech leads and product managers can act as connectors.
Increased DevOps workload. Since micro frontends rely on network requests, ensure proper CORS and caching settings.
Leadership involvement. A strong tech lead is essential to maintain order; without one, chaos and costly code divergence are inevitable.
Dependency awareness. Each app pulls its own dependencies, increasing bundle size — tree-shaking helps mitigate this.
Shared backend service. Centralise configuration storage to manage applications without additional releases.

How to Know If You Really Need Micro Frontends

You probably need them if:

Your project requires minimal time-to-market.
Independent releases are crucial.
You have a large team struggling with refactoring and conflicts in a monolithic app.
You have many isolated features without a shared state.
You’re dealing with legacy systems and need a single entry point — micro frontends allow gradual migration.

You probably don’t need them if:

You’re building a small product, startup, or MVP.
Your features are tightly coupled and require constant interaction.
Performance and bundle size are critical (though solvable, they add complexity).
Your DevOps or infrastructure is underdeveloped, or your team lacks sufficient expertise.

Conclusion

I don’t consider myself a micro frontend evangelist or a monolith purist.

There’s no point in rewriting everything into micro frontends just because it’s trendy. You must evaluate your context and choose what’s best for your product.

Our architecture was entirely driven by business needs:

Transition to a single-entry-point application.
Temporary integration of legacy apps.
Independence and isolation of modules to assemble any configuration.

If you’re uncertain, review the reasons to adopt micro frontends. If none of them clearly apply, it’s better to stick with a monolith by default.

Ultimately, micro frontends are a tool. One that benefits the business first, and developers second.

Micro Frontends: A Developer Fad or a Real Business Benefit?