The brief looked like ten-plus screens: customer lists, document archives, profile management, admin views. Built screen by screen, that becomes ten-plus sets of one-off table code and ten-plus interpretations of the same design system. So I inverted it — the deliverable was a component library first, and every section became an assembly of parts that already existed.

Roughly fifteen components carried the whole portal: sortable data tables, a slide-in sidenav, tabbed button groups, dropdown filters, modals, pagination, a phone input with country handling. Each was built once, against the design system, responsive by default — so a fix to the table improved every section using it, and consistency stopped being a review conversation.

The backend was on its own schedule, so the frontend built against mock data shaped like the agreed responses. It kept both teams moving in parallel and forced the components to be honest about states — empty, loading, error, one row, two hundred rows — because the mock could produce all of them on demand, long before a real endpoint could.

Two audiences share the codebase: staff administering accounts and customers using their own. Same library, same interaction grammar, different permissions and density — which meant the admin side inherited the polish of the customer-facing side for free, instead of ending up as the usual neglected back office.