A team that started at 5 and grew to 15 in six months. Not because the project changed - because the client saw what the right people could do.

Serverless architecture in production at scale is a different discipline from serverless in a side project or a proof of concept.

The design assumptions are different. Stateless function execution changes how you think about performance optimisation, database interactions and caching strategy. The failure modes are less familiar. And in 2024, when this project began, the established best practices that make those decisions easier were still being written by the teams doing the work rather than found in documentation.

The client's IVR system had to handle thousands of concurrent voice sessions without degradation, across a user base of 3.3 million people in Norway. SIP and WebRTC integration added a layer of complexity that sits well outside the standard backend engineering profile. SIP manages session initiation and termination for voice calls. WebRTC handles the real-time communication layer. Getting both to operate reliably inside a serverless architecture, integrated with existing telecommunications infrastructure, required engineers who had worked at this intersection before.

The time zone challenge was structural rather than incidental. A five-hour gap between the development team and the client's Norway-based engineers means that misaligned communication rhythms compound daily. Requirements that should have been clarified in a morning standup wait until afternoon. Decisions that could have been made in ten minutes take twenty-four hours if the collaboration structure does not account for the gap from the start.

The engagement started with a focused team of five. Not because the full scope was unclear, but because the right approach to a project with this many technical unknowns was to establish the architecture and collaboration rhythm before scaling the people building it.

Talex assembled that initial team around a technical leader with deep SIP and WebRTC experience. That decision shaped everything that followed. Technical leadership on a project this specialised is not a coordination role. It is the function that prevents architectural decisions from being made by engineers who are competent but have not encountered this specific failure mode before. The client received that profile because the vetting process assessed domain depth, not just stack familiarity.

All team members worked embedded with the client's Norway-based engineers throughout the engagement. Talex established a detailed SLA at the project start, defining communication standards, technical expectations and risk management protocols across the time zone gap. Regular process audits ran throughout the fifteen months to ensure the collaboration structure held as the team grew and the project scope evolved.

Six months into the engagement, the client's confidence in the team had grown enough to expand it from five to fifteen. That growth happened because the initial team had demonstrated the quality and communication standard that warranted it, not because the project had been scoped incorrectly at the start.