Skip to content
RAHUL/

Affiliate Admin & Campaign Management Portal

The admin surface of the micro-frontend CRM, plus the component library the platform is built on.

Frontend Developer
React · Next.js · TypeScript · TailwindCSS

Overview

The administrative application in the same three-app platform — management and configuration for campaigns and accounts. Alongside building it, I own the shared component library that Admin, Client and Supplier all render from.

Problem

A platform assembled from three independently built applications still has to feel like one product. That coherence has to come from somewhere without forcing the apps back into a single deployable.

My Role

  • Built the Admin application within the three-app micro-frontend platform.
  • Architected and maintain the shared reusable UI component library consumed by all three micro-frontends.
  • Established the patterns that let each application deploy modularly and independently.

Architecture

React + Next.js Admin application, deployed independently of the Client and Supplier apps.

Component library owned here and versioned out to the other micro-frontends as the interface contract.

Three separately built applications composed into one coherent CRM platform.

Technology

  • React
  • Next.js
  • TypeScript
  • TailwindCSS
  • Micro-frontend architecture
  • Shared component library
  • Modular, independent deployment

Engineering Challenges

One coherent platform from three codebases

Admin, Client and Supplier are built and shipped independently, which normally means three slowly diverging interfaces.

A library three teams depend on

Once every application consumes the same primitives, a careless change breaks all three.

Role-appropriate interfaces without forking

Admin, client and supplier users need different things from what is often the same underlying screen.

Solution

One coherent platform from three codebases

A shared component library carries the interface language between them, so coherence is a dependency upgrade rather than a manual sync.

A library three teams depend on

Versioned the library and kept its surface deliberate, so consumers adopt changes on their own schedule.

Role-appropriate interfaces without forking

Composed those screens from shared primitives with role-specific arrangement, rather than maintaining parallel implementations.

Results

3
Micro-frontends sharing one UI library
~40%
Faster feature delivery via shared components