Building a Lightweight Inflight Livescore App Beyond the Initial Scope

Many teams describe their apps as lightweight and fast. In reality, it’s often difficult to evaluate what those claims mean beyond benchmark scores or lab conditions.

The real test begins when an application must operate in a constrained environment — such as onboard an aircraft.

Inflight connectivity presents unique limitations. Bandwidth may fall below 1 Mb/s, while data transfer remains both technically restricted and costly. In this context, every request and every kilobyte has a measurable impact.

This was the challenge presented to us some time ago:

“We want passengers to be able to follow Euro 2024 while onboard.”

In this case, “follow” extended beyond simply viewing match scores. The client envisioned passengers being able to:

• view live-updated statistics,
• read real-time match commentary,
• review line-ups and disciplinary events,
• and track key match dynamics with minimal delay.

All of this needed to function with very low data usage and consistent performance under unstable network conditions.

In this article, we outline our approach, the architectural decisions made early in the project, and how those choices shaped the final solution.

‍

(Good) planning is the foundation

If the previous constraints weren’t enough, one more key non-functional requirement emerged. For the app to work onboard, all URLs it requested had to be whitelisted in the aircraft systems in advance. Moreover, once the app was running, these URLs could not change.

Unlike typical web applications, we couldn’t simply:

• prepare the whitelist,
• upload it to the aircraft, and
• test the app “live.”

Whitelisting was deployed on the planes long before the application went live in production. When the app launched, everything simply had to work—no live testing beforehand, no room for iteration.

This meant one thing: we had a single chance to get it right.
One of the biggest challenges became: how do you faithfully emulate the inflight environment during pre-production?

‍

Starting from constraints

From the outset, we prioritized constraints over features. Before any UI components were designed, we defined the boundary conditions that would shape the project:

• slow and costly inflight connectivity,
• the requirement to whitelist all URLs in advance,
• the inability to perform live onboard testing,
• and a guiding principle: every kilobyte matters.

These limitations influenced not only the technical architecture but also the product and design decisions. Alongside the engineering work, we developed the app’s UX and interface, focusing on clarity, low interaction overhead, resilience to latency, and minimal data transfer.

Technically, rather than beginning with a feature-heavy application layer, we first selected a data provider capable of delivering timely sports data with low latency and efficient payload sizes. We also chose to omit a CMS layer in the initial release, simplifying the system and reducing network dependencies.

We recognized early that reliable usage data would be essential for evaluating product decisions. To address this, we implemented a lightweight analytics layer designed specifically for inflight constraints. It enabled us to measure engagement with different content types and interface elements while maintaining a negligible impact on performance and bandwidth.

Although advanced reporting was not part of the initial requirements, the analytics design allowed for future expansion, including the potential for live dashboards, without restructuring the event collection model.

Another challenge was the lack of direct onboard testing prior to deployment. To mitigate this risk, we created a simulated test environment replicating key inflight conditions such as network throttling, URL restrictions, and initialization behaviors. This allowed us to validate realistic usage scenarios before rollout.

By the start of Euro 2024, the first version of the Live Sports Ticker was deployed as a containerized Next.js application hosted on Azure, built specifically for the inflight environment.

Operational metrics during the tournament indicated:

• More than 50,000 passengers used the application,
• Over 1 million recorded interactions during the initial phase,
• Event updates delivered with only a few seconds of delay under constrained bandwidth conditions.

Lightweight, responsive, and stable — characteristics essential for software operating onboard aircraft.

‍

A success that became a starting point, not a finish line

The Euro 2024 rollout marked an important milestone for the project. The Live Sports Ticker received the Best for Onboard Entertainment award at the Onboard Hospitality Awards 2025, recognizing both the technical execution and the passenger experience.

Rather than treating this as a conclusion, we viewed it as a validation of the decisions made during the initial design and architecture phases. It also signaled the potential for broader application beyond a single tournament.

Following the rollout, the solution evolved from an event-specific product into a more general sports platform designed for inflight environments.

Subsequent iterations expanded coverage to additional football competitions — including both men’s and women’s leagues — as well as other sports:

• Biathlon
• Ski Jumping
• Cross-Country Skiing
• Nordic Combined
• Snowboarding
• and events related to the 2026 Winter Olympic Games

Each expansion introduced greater data volumes, higher update frequencies, and increased network demands — precisely the constraints that had guided the system’s design from the beginning.

Analytics as a foundation for further development

As user adoption increased and additional sports were introduced, it became clear that further development could not rely on assumptions alone. In an inflight environment — where bandwidth is limited and data transfer carries measurable cost — understanding actual usage patterns was essential.

For this reason, we implemented a custom analytics layer designed specifically for onboard constraints. It enabled us to:

• track interactions with key interface elements (scores, statistics, commentary),
• identify which sports and leagues attracted the most attention,
• compare engagement with live versus static content,
• and observe behavioral patterns during live events.

A critical requirement was ensuring that analytics had no adverse impact on performance. Events were aggregated, reduced to essential signals, and transmitted in a controlled manner to avoid competing with live sports data for network resources.

This approach provided meaningful insight into real passenger behavior. The collected data highlighted which features delivered consistent value and which introduced complexity without measurable engagement. These findings informed subsequent product decisions, performance optimizations, and the removal of unnecessary dependencies.

‍

Performance as a process, not a one-time task

Following the initial rollout, performance analysis based on production data identified additional optimization opportunities. One of the primary constraints was the loading time of external scripts and libraries, which relied on third-party infrastructure outside our direct control.

To address this, we made a deliberate architectural adjustment: selected scripts were migrated from external providers to our own hosting environment. This change enabled us to:

• reduce application loading times,
• decrease the number of external network requests,
• improve performance predictability under inflight conditions,
• and retain full control over resource size and versioning.

These adjustments, while technically modest, produced measurable improvements. In an environment where latency, bandwidth, and payload size are critical factors, the result was a faster and more stable application experience.

Deployment speed

Over time, it became evident that application performance was only one dimension requiring optimization. As the number of supported sports, leagues, and events expanded, the speed of introducing changes and the efficiency of content management became equally important.

To address this, we integrated Umbraco CMS in headless mode. A key requirement was ensuring that the addition of a CMS layer did not compromise the application’s lightweight characteristics. By implementing multi-level caching strategies — across both backend services and the client application — the performance impact remained negligible.

At the same time, the operational advantages were substantial. Content updates could be performed more quickly, while configuration and data management became simpler and less prone to errors. This enabled faster responses to new events and client requirements without requiring development involvement for routine changes.

In parallel, we focused on maintaining predictability and scalability at the infrastructure level. The environment was defined using Infrastructure as Code (Terraform), allowing reproducible deployments, version control, and structured change management. This approach was complemented by automated CI/CD pipelines, ensuring that application and configuration updates were deployed in a consistent and reliable manner.

The result was not only a performant application but also a stable and efficient delivery process, supporting continued evolution of the Live Sports Ticker without compromising reliability or quality.

Summary

The Live Sports Ticker project illustrates how technical constraints can effectively guide product and architectural decisions. Limited and costly connectivity, the absence of live onboard testing, strict whitelisting requirements, and the need to minimize data transfer shaped the solution from the earliest design stages through implementation and deployment.

The resulting product:

• operates reliably in a highly constrained environment,
• scales with expanding business and content requirements,
• maintains performance despite increasing functionality,
• and provides client teams with flexible content management capabilities.

Projects developed under demanding technical conditions require close alignment between engineering, product strategy, and user experience design. This case demonstrates the value of treating constraints not as limitations, but as design inputs that drive clarity, efficiency, and resilience.

‍

‍

‍