Client background
A3N Digital is a software and IT consultancy based in Lusaka, Zambia, led by CEO Azar S.. Operating in a market where access to deep technical talent is geographically constrained, A3N Digital had built a business model around delivering sophisticated software solutions to Zambian enterprises by partnering with offshore engineering teams for development execution while maintaining client relationships and project management locally.
One of A3N Digital's enterprise clients — an organisation operating across Zambia — needed a custom internal video conferencing solution. The requirement was for a private, hosted platform that could support internal meetings and collaboration across the organisation without dependency on commercial video conferencing services. This requirement was driven by security considerations: the client operated in a sector where sensitive internal communications needed to be handled on self-hosted infrastructure rather than on commercial platforms where data residency and access controls were governed by the platform provider's terms.
Custom video conferencing is technically demanding. WebRTC — the underlying technology that enables browser-based peer-to-peer audio/video — has significant implementation complexity, particularly around cross-browser compatibility, signalling server design, and the media server infrastructure required to handle group calls above a small number of participants. A3N Digital needed a development partner with genuine WebRTC expertise, not a team that would attempt to learn the technology during the build.
The challenge
The technical complexity of building a production-grade video conferencing platform from scratch is frequently underestimated. WebRTC's peer-to-peer model works well for one-to-one calls but requires a Selective Forwarding Unit (SFU) or Multipoint Control Unit (MCU) architecture for group calls — the media server infrastructure that receives streams from multiple participants and routes them efficiently to other participants. Building or correctly configuring this infrastructure is a specialised skill, and doing it incorrectly produces a platform that degrades badly under real usage.
Beyond the core video infrastructure, the platform needed features that matched what users expected from enterprise collaboration tools: scheduled meetings with calendar integration, persistent meeting rooms, screen sharing, recording capability, and an admin console for user management. Delivering these features on a custom platform while maintaining the security properties the client required — no third-party infrastructure, no external data flows — required careful architectural planning.
The engagement also had a stakeholder complexity dimension: A3N Digital was the delivery partner, not the end client. This meant Squash Apps needed to work effectively with A3N Digital's leadership while understanding the end client's requirements well enough to make good technical decisions. Azar S. needed to be able to represent the Squash Apps team's work to his client with full confidence — which required both technical quality and clear, proactive communication about the build progress and any issues that arose.
How we engaged
Squash Apps was found by A3N Digital through a search engine evaluation process. The pitch and technical approach presented by Squash Apps was the differentiating factor: Azar S. selected Squash Apps because "we thought we were the best out of the lot" — a competitive assessment that reflected the quality and specificity of Squash Apps' technical proposal for the video conferencing architecture.
The team composition was substantial for the scope: ten software engineers (frontend and backend), two QA engineers, two development leads (one frontend, one backend), and two PMs. This team size reflected the genuine complexity of the deliverable: a production-grade video conferencing platform requires parallel workstreams across media server infrastructure, signalling, frontend application, and integration development.
The development methodology was agile sprint cycles with regular planning sessions and demonstrations. Azar S. was directly involved in sprint planning and reviews: the sprint planning meetings were used to communicate the development questions and technical decisions that needed the client's input, and the sprint reviews gave A3N Digital a testable increment of the platform at the end of every two weeks.
A specific cultural dynamic that Azar highlighted in his review was the experience of Squash Apps feeling like an internal team rather than an external vendor: "I felt as if they were our own team though they worked out of a different continent." On an engagement where A3N Digital was representing the work to a demanding enterprise client, this quality of integration was essential.
What we built
The core deliverable was a self-hosted video conferencing platform accessible through a web browser without requiring any software installation by end users. The frontend was a React application supporting all modern browsers, with WebRTC handling the audio and video streams and a React-based UI delivering meeting room management, participant controls, chat, and screen sharing.
The media server infrastructure used Mediasoup — an open-source WebRTC SFU — deployed on dedicated AWS EC2 instances sized for the expected concurrent meeting load. The SFU architecture was chosen over a simpler peer-to-peer approach because it scales to group calls of 20+ participants without the bandwidth explosion that peer-to-peer creates when every participant sends their stream to every other participant.
The signalling server — the component that coordinates WebRTC connection establishment between participants — was built on Node.js with Socket.io for the WebSocket transport. Signalling was separated from the media server on dedicated infrastructure, allowing each component to be scaled independently.
Meeting scheduling was implemented as a calendar-integrated feature: meetings could be scheduled in advance, invitations sent via email with a joining link, and meeting rooms persisted with a fixed URL so that recurring meetings could use the same room without new setup. An admin console gave IT administrators the ability to manage users, view meeting logs, and configure platform settings without developer intervention.
Recording capability used a server-side recording approach — recording was handled by the media server rather than client-side, ensuring consistent quality regardless of participant hardware — with recordings stored in encrypted S3-compatible object storage and accessible through the admin console.
Technical approach
The architecture separated three infrastructure layers: the signalling layer (Node.js/Socket.io), the media processing layer (Mediasoup SFU on EC2), and the application layer (React frontend, Node.js API). This separation allowed independent scaling: during a period of high simultaneous meeting activity, the media servers could be scaled without touching the signalling infrastructure or the application API. It also made fault isolation cleaner — a problem with the media processing layer would not cascade to the signalling or application layers, maintaining the meeting management UI even if a media server needed to be recycled.
WebRTC's STUN and TURN server configuration — the mechanism that allows WebRTC to establish connections through corporate firewalls and NAT — was handled by deploying a dedicated TURN server on AWS alongside the media infrastructure. This was an important correctness detail: a video conferencing platform that works on clean network connections but fails for users behind corporate firewalls is not production-ready. In an enterprise environment, where security-conscious network administrators often block direct peer-to-peer UDP traffic, TURN relay capability is not optional — it is a fundamental requirement for reliable connectivity.
End-to-end encryption was implemented for one-to-one calls using WebRTC's built-in SRTP (Secure Real-Time Transport Protocol). For group calls routed through the SFU, media was encrypted between participants and the SFU using DTLS, with the SFU operating in a trusted security boundary within the client's own infrastructure — satisfying the client's data security requirements without the complexity and performance overhead of end-to-end encryption at the SFU layer.
The recording infrastructure was designed with both quality and storage efficiency in mind. Server-side recording via the Mediasoup RTP recording feature captured the composite stream at a consistent quality level, independent of participant hardware quality. Recordings were stored in encrypted object storage with configurable retention policies, and a background transcoding job generated lower-resolution variants for bandwidth-efficient playback on mobile devices.
Results
A3N Digital successfully delivered the video conferencing platform to their enterprise client on the agreed timeline. The client's internal communications infrastructure was migrated to the custom platform, replacing the dependency on commercial services and meeting the data security requirements that had driven the custom build in the first place. The migration was completed with no disruption to the organisation's meeting schedule — a testament to the quality of the parallel-running testing phase that had been built into the delivery plan.
The platform's performance in production matched the design specifications: group calls with up to 20 simultaneous participants ran smoothly without the bandwidth degradation that a peer-to-peer architecture would have produced, and the server-side recording feature captured high-quality meeting recordings that the client could archive and reference as part of their internal governance processes.
Azar S.'s assessment of the delivery quality: "The delivery was flawless and the team was very communicative. They made sure we knew of any issues upfront and managed the development cycle well." The proactive communication about potential issues — raising concerns early rather than hoping they would resolve themselves — was specifically called out as a characteristic that distinguished the engagement from previous vendor experiences. This transparency, combined with technical depth in a genuinely specialised domain (custom WebRTC development is not a commodity skill), made the collaboration work well across the geographic and time zone distance between Lusaka and India.
For organisations considering custom enterprise video conferencing development — whether for data sovereignty, security compliance, or deep integration with internal systems — the A3N Digital engagement illustrates what a purpose-built platform can deliver that commercial services cannot: complete control over data residency, integration with internal user directories, and a roadmap governed entirely by the organisation's own requirements rather than a commercial platform's product decisions. The engagement continued beyond the initial video conferencing build, reflecting the confidence A3N Digital developed in the Squash Apps team through the quality of the first project.