The frontend I worked in:

~124,000 lines of code across ~660 source files

57 routes spanning the whole platform

172 API endpoints behind 14 data-layer modules

One workflow chain: a style becomes a costing, then a budget, a time-and-action calendar, a commercial document, and finally a shipment

At this size, individual talent isn't the bottleneck. Structure is.

I organized the code by business domain (HCM, PLM, SCM, Budget, Accounting and so on), and the navigation config mirrors the same structure.

Why: ERP users think in workflows, not pages. When code boundaries match business boundaries, a change to shipping documents rarely touches payroll, and a new engineer can find the right folder by knowing the business.

Every request goes through a single base query that attaches authentication and tenant context. On top of it sit RTK Query API modules with tag-based cache invalidation.

Why: In an ERP, one edit ripples outward. Change an invoice and the list, the summary, and the reports are all stale. Hand-written refetching is where stale-data bugs come from. With tags, "what does this mutation refresh?" becomes a declaration instead of a hunt through components. Moving to this model cut redundant API calls by roughly 45%.

Inputs, modals, data tables, dropdowns and toasts are shared components. The input alone is used in 170+ files, and the modal in 130+.

Why: In software people use eight hours a day, consistency is a feature. It's also a review multiplier: when 130 screens share one modal, reviewers check business logic instead of re-checking dialog behavior.

Fabric consumption logic (KG, yard and meter calculations, inch/cm conversion, GSM, wastage, per-dozen multipliers) lives in pure functions, separate from the UI.

Why: These numbers drive cost and pricing. A pure function can be tested with a table of inputs, and the same rule can serve the BOM, costing and edit modals without drifting.

ERP screens are forms, and the forms are huge. Multi-section forms keep local state per section and sync to the parent through a debounced hook with a deep-equality guard. I used that pattern in 29 places.

Why: If every keystroke updates parent state, the whole form tree re-renders, and the cost grows with each section you add. Debouncing plus the equality check keeps typing responsive no matter how large the form gets.

Permissions follow the business hierarchy. Switching a module off resets everything beneath it, and switching it on enables its children. Each route also sits inside its own error boundary.

Why: In an ERP, access rules are product logic: HR sees payroll, merchandisers see costing. And a crash in one report should degrade to a fallback for that screen, not a white page for the whole workspace.

Employees, attendance and company data all support CSV/XLSX import.

Why: ERP adoption often dies at data onboarding. If moving twelve months of records in is painful, the rest of the platform doesn't matter.

The first version was a single React application: all routes in one routing table and one shared store. That was the right call at ten screens. At eight modules it meant every module paid for every other module, through longer builds, heavier loads and coupled releases.

I led the migration to a micro-frontend architecture with Module Federation, so modules could be built, deployed and loaded independently. Alongside it, I moved heavy computation off the main thread with Web Workers, cutting Interaction to Next Paint from about 1.2 s to under 80 ms.

The hard part of micro-frontends isn't the tooling. It's deciding what is shared (UI primitives, the auth contract, the API layer) and what each module owns. Get that wrong and you've built a distributed monolith.

1. Introduce route-level code splitting from the start. It's cheap early and expensive to retrofit.

2. Be deliberate about what gets persisted in the browser, rather than persisting every slice by default.

1. Frontend architecture at scale: state and data-layer design, micro-frontends, and performance work tied to measurable numbers.

2. Domain fluency: I've built ERP modules across garments and textile, fintech, e-commerce, healthcare and adtech, including inventory, HRM, accounting, purchase, commercial, production and planning.

3. Full-stack depth: Node.js, Express, Prisma and PostgreSQL, with growing Go experience. That lets me design API contracts with backend engineers instead of consuming them.

4. Mentoring: Shared primitives and consistent patterns are how I raise the floor for junior developers, more effectively than code review alone.

5. Business impact: I care most about replacing manual, error-prone processes with software people trust.

Scaling an ERP is mostly about deciding, early and deliberately, what is shared and what is owned. Everything above is that one decision, applied repeatedly.

I'm looking for my next role in large-scale, collaborative engineering. If you're building complex business platforms, I'd love to talk. My portfolio is at mhasansagor.me.

#ERP #FrontendArchitecture #MicroFrontends #React #ReduxToolkit #SystemDesign #SoftwareEngineering