Client background
The client is a US-based sports technology company that built a data-driven platform combining real-time sports analytics, predictive gaming features, and a community layer for fans of major league sports. The platform serves a dedicated base of sports enthusiasts who engage heavily around game days and live events — which creates a very particular engineering challenge: traffic is not steady, it is enormously spiky, with massive surges around game time followed by prolonged quiet periods.
Their product had carved out a meaningful position in the sports fan engagement space by combining data nobody else was surfacing in a fan-friendly format. By the time they engaged Squash Apps, the product had proven its core thesis but was struggling to execute on the roadmap that would take it from "interesting niche product" to "category-defining platform." The backlog was growing, the mobile app needed a significant rebuild, and the infrastructure had been designed for a fraction of the peak traffic the product was now seeing.
The broader context matters: the sports technology sector had been growing rapidly, with fan engagement platforms, sports betting integrations, and fantasy sports applications all competing for the same audience. Users who had become accustomed to the responsiveness of established sports apps — ESPN, the official league apps, major fantasy platforms — brought high expectations to every product in the category. Competing in that environment required not just good features but flawless real-time performance, mobile-first design, and the kind of reliability that keeps users coming back week after week through an entire season. The client recognised that without a step-change in their engineering capacity and infrastructure, the product's growth would stall precisely when it had the most momentum.
The challenge
Sports technology products live and die by their performance during the moments that matter most: the live game. A 30-second lag in score updates, a mobile app that crashes when users are trying to check predictions at halftime, or a leaderboard that freezes under load — these aren't inconveniences, they're product-killing events that drive users to competitors in real time and generate social media complaints that undermine the product's reputation.
The client's original infrastructure had been built for a much smaller user base. As the product grew, they had patched and extended it, but the underlying architecture was showing strain. The backend was struggling to keep up during peak moments, the mobile app had accumulated significant technical debt that was making it slow and unreliable, and the team was spending too much time fighting fires rather than building.
The founding team's instinct was to hire more engineers, but they had burned time trying to do this locally with limited success. US-based mobile engineers with the right sports tech background are expensive and in high demand, and the company wasn't yet at the stage where it could compete on salary alone. They needed senior engineers quickly, reliably, and at a cost structure that made sense for a growth-stage company.
Additionally, the product roadmap included several features that would require significant new technical capability: personalized predictions using ML models, a social layer with real-time commenting and reactions during games, and deep integrations with multiple sports data providers with different API formats and reliability characteristics. The team needed more than extra headcount — they needed architectural guidance on how to build these features in a way that would scale.
How we engaged
Squash Apps was brought in at the start of a new sports season, which created a hard deadline: the platform needed to be in a significantly better state before the first major game day of the season, approximately ten weeks from the engagement start date.
The first two weeks were focused entirely on assessment and triage. Srijith and a senior backend architect from Squash Apps spent four days working alongside the client's engineers reviewing the architecture, profiling the API under simulated load, and identifying the three most critical failure points. The findings were documented in a technical memo shared with the founders: the database query patterns for the leaderboard feature were O(n) at scale and would cause timeouts beyond a certain user count; the mobile app was making redundant API calls that were wasting bandwidth and increasing server load; and the WebSocket implementation for live score updates was not handling reconnection gracefully on mobile networks.
The pod that assembled for the engagement included two senior Node.js backend engineers, two React Native mobile specialists, one React web engineer, and a QA engineer focused on load testing and automated regression coverage. All engineers were integrated into the client's existing Jira workflow, joined the Slack workspace, and participated in the same sprint ceremonies as the in-house team.
What we built
The first major deliverable was the performance overhaul. We rewrote the leaderboard query logic to use a pre-computed materialized view pattern — the leaderboard was recalculated on a background job triggered by game events, eliminating the expensive real-time calculation. This reduced leaderboard load time under peak conditions from 4–8 seconds to under 200ms. We also implemented a Redis caching layer for frequently-requested data (standings, recent game results, player stats), which dramatically reduced database load during the game-day surge windows.
The mobile app rebuild was the second major workstream. We refactored the React Native codebase to eliminate redundant API calls, implement proper offline caching for core data, and upgrade the navigation architecture to React Navigation v6. The most user-visible improvement was the live game screen: we rewrote the WebSocket connection management to handle mobile network interruptions gracefully, meaning the live score updates would resume automatically when connectivity was restored rather than requiring a manual app restart.
The social layer was built from scratch as a new feature: real-time commentary, emoji reactions, and prediction sharing during live games. This was built on a separate WebSocket infrastructure using Socket.io, deliberately isolated from the core sports data infrastructure so that a spike in social activity couldn't impact the reliability of the live score updates.
Beyond the technical work, we established the weekly release cadence the client had been trying to achieve. By implementing a proper branching strategy, automated testing gates, and a staged rollout process, the team was able to ship improvements every Tuesday — feature work, performance improvements, and bug fixes — on a predictable schedule that the product and marketing teams could plan around.
Technical approach
The platform is built on Node.js with Express for the API layer, MongoDB for the primary data store, and Redis for caching and real-time pub/sub. The web frontend is React, the mobile app is React Native, and the entire stack runs on AWS — EC2 for application servers, ElastiCache for Redis, DocumentDB for MongoDB-compatible managed storage, and CloudFront for asset delivery.
The most technically interesting work was the real-time architecture. Sports data arrives from multiple providers in different formats and at different latencies. We built a data ingestion layer that normalised incoming events from different providers into a canonical format, applied conflict resolution logic when providers reported the same event differently, and emitted normalised events on an internal message bus. Downstream consumers — the leaderboard engine, the prediction resolver, the notification service — subscribed to this bus independently, making it easy to add new real-time features without touching the ingestion layer.
We also implemented a fan-out architecture for the live commentary feature: a single game event needed to push updates to potentially tens of thousands of concurrent WebSocket connections. Rather than broadcasting directly from the API server, we used a Redis pub/sub channel as the intermediary, allowing multiple API server instances to participate in the broadcast without any one instance becoming a bottleneck.
Results
The results across the first full season with the new infrastructure were significant. Peak downtime — which had been a recurring problem in the previous season — was eliminated: the platform ran without incident through seven major game days including a playoff run that drove record traffic. The weekly release cadence was established and maintained for the duration of the engagement.
User engagement metrics improved meaningfully: average session time increased as the live game experience became faster and more reliable, and the new social features drove a measurable increase in return visits on game days from users who had previously only checked in once. The mobile app's App Store rating improved by half a star following the React Native rebuild.
The infrastructure improvements also unlocked commercial opportunities that had previously been blocked by reliability concerns. Sponsorship integrations — a key revenue stream for sports engagement platforms — require guaranteed uptime and predictable performance windows that the previous architecture couldn't deliver. With the new infrastructure in place, the client was able to pursue and close partnership deals that had been on hold pending technical confidence.
Perhaps most importantly, the client entered the following season with a platform they were confident in, a team that could execute reliably, and a technical foundation that could support the next phase of product ambition rather than limiting it. The engagement demonstrated what a focused, well-integrated software development team can deliver for a growth-stage sports technology company: not just more engineers, but the right architecture, the right processes, and the right culture to make consistent delivery sustainable across an entire season and beyond.