Before designing the interface, we defined the boundary conditions: slow and costly connectivity, fixed whitelists, no live aircraft iteration, high latency, and a guiding rule that every kilobyte mattered. Those decisions shaped both the technical system and the UX.

We selected a sports data provider around payload efficiency and update latency, kept the first release free of unnecessary CMS dependencies, and built the passenger interface around clarity, low interaction overhead, and resilience to unstable network conditions. A lightweight analytics layer was added from the beginning so usage could be measured without competing with live sports data.

The first release was a containerized Next.js application hosted on Azure and built specifically for the inflight environment. Its job was not to recreate a full sports portal. Its job was to deliver the most useful live match information with predictable network behavior, fixed endpoints, and minimal payload size.

To reduce deployment risk, we created a simulated test environment that reproduced key onboard constraints: network throttling, URL restrictions, initialization behavior, and the absence of live cabin iteration. That environment became the proving ground for launch.

After the Euro 2024 rollout, the system expanded from a tournament-specific feature into a broader sports platform. Coverage grew to additional football competitions, women’s and men’s leagues, winter sports, and events connected to the 2026 Winter Olympic Games.

As adoption increased, the analytics layer became a product tool rather than a reporting afterthought. It showed which content types passengers actually used, how they engaged with live versus static views, and where complexity could be removed without harming the experience.

Performance work continued after launch. Selected external scripts were moved into our own hosting environment to reduce requests, improve loading predictability, and give the team control over resource size and versioning. Later, Umbraco was added in headless mode, with multi-level caching across backend services and the client application so editorial flexibility would not compromise the lightweight nature of the app.

As the number of sports, leagues, and events increased, delivery process became as important as runtime performance. Infrastructure was defined with Terraform, and application and configuration updates moved through automated CI/CD pipelines.

The result was a live sports product that could keep evolving without turning into the kind of heavy, dependency-rich application that would fail under the same inflight constraints it was created to survive.