SSP Micro-Frontend Platform

MTN Ghana’s digital services grew up as separate portals. Managing an account, buying a device, swapping a SIM and running a business account each lived on a different site, with its own codebase, its own interface and its own way of doing things.

In an architecture review the question was put plainly: why do customers need a different portal for every service? The answer we settled on was a single platform, composed of independently deployed micro-frontends, with a shared design system underneath. I lead the frontend engineering for the platform, and designed and introduced the design system that every application on it uses.

Highlights

• Replaced a portal-per-service model with one platform for MTN’s self-service products
• Independently deployed React applications composed with Webpack Module Federation
• A central design system, published as a versioned package, used by every application
• Layered design tokens and CSS custom properties for branding and light and dark themes
• Shared engineering standards, documentation and release workflow across teams

Why one platform

Separate portals made sense when each service launched, but together they cost everyone. Customers had to learn a different site for every task. Teams rebuilt the same buttons, forms and layouts again and again, and those copies slowly drifted apart. Every change to the brand or to shared behaviour had to be made several times over.

A single monolithic app would have fixed the experience but tied every team to one codebase and one release train. Micro-frontends gave us both: one product for the customer, and independent ownership and deployment for the teams building it.

How it’s built

A Shell application hosts the platform and provides the common frame. Each domain, including the SSP Portal, eCommerce, SIM Swap and Business Hub, is its own React application, owned by its own team and deployed on its own schedule. Webpack Module Federation composes them at runtime, so to the customer it is one product.

The rule that keeps it maintainable is simple: applications own their business logic, and the platform owns everything shared. That boundary is what lets teams move independently without the experience fragmenting again.

The design system

I designed and introduced MTN Ghana’s central design system to be the single source of truth for shared frontend work. It ships as an independently versioned package on GitHub Packages, and every application on the platform consumes it. It provides:

• Design tokens and theme management
• Reusable, accessible UI components
• Shared React hooks and utility functions
• A typed SVG icon library
• Global styling infrastructure

Theming is built on layered design tokens exposed as CSS custom properties. Components only reference semantic tokens, so light and dark themes, and future brands, are a matter of swapping values rather than rewriting components.

The package is built with tsup for clean tree shaking, is fully typed, and is designed to be shared safely under Module Federation, so applications don’t end up loading several copies of the same library.

Standards and tooling

Independent teams only stay consistent if the expectations are written down. I defined the project structure, coding conventions and architectural guidelines the applications are built against, and the build, test and release workflow behind the design system: GitHub Actions for CI, Changesets for versioning and changelogs, Vitest for tests and tsup for builds.

I also wrote the platform’s developer documentation, contribution guidelines, migration strategy and release process, so a new team can adopt the platform without needing someone to walk them through it.

My role

I lead the frontend engineering efforts and contributed to the technical direction for the platform: its development, code quality, how it evolves and when something is ready for production. A large part of the work is with product and engineering teams, making sure that many independently built applications still add up to one consistent product.

Outcome

Customers now have one place for MTN’s self-service products instead of a portal per service. Teams ship on their own schedules without rebuilding shared UI, duplicated work has dropped, features reach customers faster, and new applications start from a shared foundation instead of from scratch.