Building a Hospital ERP Frontend with a 9-Developer Team

The starting point

Buch International Hospital needed a modern ERP frontend covering patient management, billing, and inventory — replacing a legacy system the staff had outgrown. I joined as frontend team lead with three developers; by the end we were nine. Scaling the team turned out to be a harder engineering problem than the UI itself.

Architecture before headcount

Adding developers to a codebase without conventions multiplies chaos rather than output. Before we grew past four people, we locked three things:

• A component library with clear ownership. Healthcare workflows reuse the same primitives constantly — data grids, patient cards, form sections with validation. Building these once in a shared ui layer, with Material-UI as the base, cut feature development time by roughly 30%.
• Feature folders with explicit boundaries. Patient management, billing, and inventory each owned their components, hooks, and API adapters. A developer could own a module end-to-end without stepping on another team's diffs.
• State rules everyone could recite. Server data lived in Redux Toolkit with RTK Query patterns; form state stayed local; global UI state was a thin slice. Arguments about "where does this state go" disappeared because the answer was written down.

Code review as the scaling mechanism

With nine developers of mixed seniority, review was where quality was actually enforced. We kept PRs small, required a checklist (responsive behavior, loading states, error states, permissions), and rotated reviewers so knowledge spread instead of pooling. The discipline felt slow in week one and saved us by month three — onboarding a new developer meant pointing at fifty well-reviewed PRs that showed the house style.

Healthcare-specific constraints

Hospital software has failure modes that marketing sites do not:

• Data correctness over cleverness. A billing total that renders wrong is not a UI bug, it is an incident. We validated aggressively at the boundary and rendered explicit error states rather than optimistic guesses.
• Workflows over pages. Staff think in admission flows and discharge flows, not routes. Mapping UI structure to their mental model cut training time for hospital staff measurably — efficiency improved about 35% after rollout.
• Performance on modest hardware. Hospital terminals are not developer laptops. Virtualized tables and careful re-render control were necessities, not optimizations.

What I would repeat

Locking architecture before scaling headcount; investing in the shared component layer early; treating code review as the primary teaching channel. The project delivered its 12-month roadmap on schedule with a team that had tripled in size — and the patterns are the same ones I describe in how I structure React components for teams of 10+.

The full project breakdown with results is in the case studies, and if you are scaling a frontend team right now, my services page describes how I take on exactly this kind of engagement.