Overview
A CRM platform for B2B market research, data insights and analytics, assembled from three independently deployable applications — Admin, Client and Supplier. I built two of them: Admin, where campaigns and accounts are managed and configured, and Client, where external users work through campaign and analytics workflows. Underneath all three sits the shared component library I own.
Problem
Three products with heavily overlapping interface needs had to ship on their own cadence without the UI drifting apart — and without three teams rebuilding the same screens three times.
My role
- Built the Admin and Client applications within the three-app micro-frontend platform.
- Architected and maintain the shared, versioned UI component library consumed by all three micro-frontends.
- Established the patterns that let each application deploy modularly and independently.
- Wired UI workflows into backend intelligence services for an AI-powered lead-generation product.
Architecture
- FrontendAdmin and Client as separate React + Next.js applications, each deployed independently of the others.
- Shared UIA versioned component library — the interface contract every micro-frontend renders from.
- CompositionAdmin, Client and Supplier composed into one coherent CRM platform.
- ServicesUI workflows connected to backend intelligence services powering lead generation.
Technology
Interface
- React
- Next.js
- TypeScript
- TailwindCSS
Architecture
- Micro-frontend architecture
- Shared component library
- Modular, independent deployment
Engineering challenges
Independent deployment without UI drift
Each application shipped on its own schedule, so shared surfaces risked diverging in behaviour and style over time.
A library three apps depend on
Once every application consumes the same primitives, a careless change breaks all three — and common patterns were still being rebuilt per app.
Role-appropriate interfaces without forking
Admin, client and supplier users need different things from what is often the same underlying screen.
Driving AI services from the UI
Lead-generation intelligence lived in backend services the interface had to orchestrate predictably.
Solution
- S1
Independent deployment without UI drift
A single versioned component library became the contract between apps — interaction and visual patterns change in one place and propagate on upgrade, so coherence is a dependency bump rather than a manual sync.
- S2
A library three apps depend on
Consolidated those patterns into the library, versioned it and kept its surface deliberate, so consumers adopt changes on their own schedule. It cut duplicate code and reduced new-feature time by an estimated 40%.
- S3
Role-appropriate interfaces without forking
Composed those screens from shared primitives with role-specific arrangement, rather than maintaining parallel implementations.
- S4
Driving AI services from the UI
Modelled the UI workflows around those service calls so the product surface stayed responsive and observable as the data moved.
Performance
- Campaign-ready marketing pages for the platform reached a Lighthouse performance score of 98.
Product experience
- Navigation, data views and forms behave identically across all three applications because they render from the same library.
Results
- Independently deployable applications
- Less time to ship a new feature
- Lighthouse performance — marketing pages
Links
Client engagement at Jasper Colin — not publicly linkable.