Insurance · May 2023 – Oct 2024
Quote Management System
A single frontend codebase serving multiple insurance product lines was becoming a bottleneck: teams working on different quote modules kept blocking each other's releases.
- Company
- Fyn Tune Solution Pvt Ltd
- Role
- Software Engineer (React.js)
- Period
- May 2023 – Oct 2024
What I actually owned.
Designed and built the frontend architecture; owned the micro-frontend module boundaries, form validation layer, and performance work.
Technology used.
| Frontend | React.jsTypeScriptTailwind CSS |
|---|---|
| Architecture | Micro-frontends |
| Integration | Multiple backend REST APIs |
How it fits together.
Components
- Shell app
- Quote module A
- Quote module B
- Quote module C
- Shared REST API layer
How they connect
- $ Shell app → Quote module A (independently deployed)
- $ Shell app → Quote module B (independently deployed)
- $ Shell app → Quote module C (independently deployed)
- $ Each module → Shared REST API layer
A shell app composes independently developed and deployed quote modules, so one product line can ship without waiting on another's release train.
Decisions & tradeoffs.
Micro-frontend architecture over a single monolithic React app
Multiple teams needed to develop and deploy quote modules independently without a shared release bottleneck.
Code-splitting and lazy loading across module boundaries
Processing 50,000+ quotes a week meant frontend performance under real load was not optional.
Metrics that matter.
50,000+ / week
Quote volume
Micro-frontend
Architecture
Code-splitting + lazy loading
Performance work
What actually went wrong, and how it got fixed.
Dynamic, product-line-specific form validation across many insurance quote types.
Built a reusable validation layer so each module could express its own quote rules without duplicating form plumbing.
Keeping the app fast while composing several independently deployed modules.
Code-split by module and lazy-loaded non-critical paths, then measured and improved load efficiency.