Behind MotoTiming: our real-time app case study

We are pleased to share a new, in-depth case study about how MotoTiming was designed and developed as a real-time motorsport companion across iOS, Android and the web.

The case study goes behind the screens to explain the engineering decisions that let MotoTiming turn rapidly changing race data into a clear, dependable experience for fans.

More than a live timing screen

MotoTiming brings together live timing, event schedules, starting grids, results, rider information, lap charts, race analysis and configurable alerts. Making those features feel like one product meant integrating several services with very different behaviours.

The finished platform uses a dedicated Node.js ingestion service to collect live data, MySQL to normalise and cache it, a Next.js API to provide a controlled boundary, and an Expo/React Native application for the native experience.

That architecture means every device does not need to contact an upstream timing provider independently. MotoTiming can absorb short outages, correct unusual responses and manage race-day traffic centrally while keeping the app fast.

API integrations built for race weekends

The article explores how the platform handles:

• second-by-second timing data with schedule-aware polling;
• schedules, results and championship information with tailored cache lifetimes;
• circuit and rider imagery stored locally for speed and resilience;
• processed lap charts, rider comparisons and race stories;
• native and browser notifications with duplicate-send protection;
• calendar integration and privacy-conscious analytics.

It also explains why stale data can sometimes be more useful than an error. For historical results, schedules and imagery, MotoTiming can continue serving the most recent stored response while an external service recovers.

Building subscriptions fairly

A major part of the native build was integrating in-app purchases through RevenueCat and the Apple and Google billing systems.

Rather than spreading product checks throughout the interface, MotoTiming uses a single Pro entitlement. The app loads store-provided pricing, handles purchases and cancellations, restores previous transactions and reacts when a customer's entitlement changes.

The case study also covers the migration from a paid download to a free app with subscriptions. Existing iOS customers are recognised using original App Store purchase metadata, giving genuine previous purchasers continued access without weakening the subscription rules for new users.

Testing a live sport app between races

Many of the most important app states only exist briefly during a real event. Waiting for the next race is not a practical testing strategy, so MotoTiming can capture real timing payloads and replay them later through the same database and API path used in production.

That makes it possible to test lap and position changes, pit status, crashes, session transitions, winner alerts, malformed data, restarts and realistic polling behaviour on demand. Subscription states can also be forced during development before the real transaction flow is checked with store sandboxes and physical devices.

Read the complete case study

The full article includes the architecture, API strategy, purchase and restore process, native build workflow, testing approach, difficult trade-offs, technology stack and lessons learned during development.

Read “MotoTiming: Building a Real-Time Motorsport Companion App” on Backends.co.uk

MotoTiming continues to evolve, but the aim remains simple: make every race weekend easier to follow while the engineering underneath quietly handles data that changes every second.