Commercial · 2025 — 2026
Consultancy CRM & Visa Platform
Micro-frontend platform running visa pipelines for an international consultancy
Commercial product · private codebase
Overview
A monorepo-based platform of interconnected portals — CRM, visa processing and workforce operations — each deployed independently but sharing design system, auth and data contracts. I led frontend development end to end: solution design, implementation and continuous delivery across releases.
The Problem
The consultancy ran visa pipelines across spreadsheets, email threads and disconnected tools. Every application touched multiple roles and external partners, with compliance requirements that demanded a full audit trail — and no system provided one.
The Solution
A micro-frontend system where each business domain (CRM, visa operations, workforce) lives in its own independently deployable app, unified by a shared component library and typed API layer. Every pipeline action is tracked, auditable and visible in real time to every role that needs it.
Architecture
- Monorepo with domain-scoped apps and a shared UI/util layer, so teams ship portals independently without drift.
- Typed API contracts shared across apps to keep cross-portal data flow consistent.
- WebSocket layer for real-time pipeline updates and in-app chat, synchronized across portals.
- Lead-ingestion pipeline: public website → CRM with cross-repo data flow and lead-to-candidate conversion.
Key Features
- Multi-role visa pipelines with strict stage gating and partner hand-offs
- Activity tracking and audit flows on every pipeline mutation
- Real-time updates and chat via WebSockets
- Centralized finance tracking for visa workflows
- Role-based access across separately deployed portals
Challenges
Keeping independently deployed apps coherent
Separate portals meant separate release cycles. Shared packages for UI, auth and API types — versioned inside the monorepo — kept every portal on the same contract without blocking each other's deploys.
Compliance without friction
Audit requirements could easily have made the UI bureaucratic. Tracking was pushed into the data layer so audit records are produced as a side effect of normal actions, not extra steps for operators.
Requirements that evolved weekly
I sat in weekly client SRS discussions and translated them into iterative delivery — scoping what ships this release versus what needs design, keeping trust on both sides.
Performance
- Centralized workflows removed manual hand-offs and measurably accelerated case throughput.
- Domain-level code splitting keeps each portal's bundle scoped to its own workflows.
Lessons Learned
Micro-frontends pay off only with disciplined shared contracts — the architecture is a social agreement as much as a technical one.
Sitting in requirement discussions directly makes you a better engineer: half of good architecture is knowing which requirements are actually stable.
Next case study
RestroX