What it is
IPEX sells telecommunications services through wholesale partners, who resell them under their own name. Those partners need one place to run that business, and the B2B portal is it.
It covers a lot of ground: fixed lines, mobile services, SIP connectors, virtual fax, videoconferencing, PBX systems and call centres, and around them customer accounts, orders, billing and settlement, usage and profit statistics, regulatory reports and a helpdesk for tickets. The larger partners skip the interface entirely and connect their own ERP or CRM through the platform’s APIs.
That breadth is the whole design problem. Every module is somebody’s daily tool, and no module is anybody’s only one.
My part
I led a small frontend team building and maintaining the portal, in my first role with responsibility for other developers.
- One architecture, not nine. Built module by module without agreed patterns, a portal this wide turns into nine applications that happen to share a login. I introduced shared React patterns, state conventions and component structure, so a developer moving between billing and the helpdesk was reading the same codebase, not relearning one.
- Automated tests where they paid off. I added Cypress end-to-end tests for the flows partners depend on most, such as placing an order and opening a ticket. Fewer bugs reached production, and more importantly, the team stopped being afraid of the refactors it needed.
- Day-to-day delivery. New features, code reviews, and support for the modules already live with real partners on them.
What I took from it
Leading turned out to be less about technical decisions than about making them once, out loud, and then making them cheap to follow. Agreeing conventions early and backing them with automated tests mattered more than any framework choice, and I have started every project that way since.