Air Race X

Context

The Red Bull Air Race was one of the most technically demanding motorsport competitions in the world — pilots flying real aerobatic aircraft through inflatable pylons at up to 370 km/h, at low altitude, timed to the millisecond. When Red Bull ended the series in 2019, the pilots had no official series to compete in.

In 2023, a group of those pilots decided to create their own. The concept was radical: instead of requiring all competitors to travel to a single location (which made the original series expensive and logistically complex), each pilot would fly their course at their home airport. The competition would happen virtually — same rules, same course, same time window — but geographically distributed.

The technology had to make that possible.

The Challenge

Making distributed competition work fairly is harder than it sounds. When everyone races in the same place, conditions are equal by default — same weather, same course, same judges watching. When pilots race from different countries, on different days, in different conditions, the competition becomes meaningless unless you can account for all the variables that make one run faster or slower than another.

The core problems to solve:

• Flight data capture and submission — each pilot needed a standardized way to record their run and submit it to the platform
• Data validation — how do you verify that a submitted file represents a real flight, not a manipulated one?
• Fairness algorithms — wind speed, direction, and GPS position all affect flight time; how do you normalize results across different conditions?
• Real-time ranking — as pilots submitted runs during the competition window, standings needed to update and be visible to teams and spectators

This was also my first international project — working in English with a multi-disciplinary team across multiple countries.

Approach

The client introduced the project requirements in terms of what needed to happen operationally: pilots register, fly, submit data, get scored, see rankings. My job was to turn that into a working system.

I proposed a 6-week prototyping phase before committing to a final architecture. This was deliberate — I hadn’t worked with flight data before, and I wanted to understand the format and constraints of the data before designing the system around assumptions.

During those 6 weeks:

• Worked with the technical team to understand what data the onboard recording hardware produced
• Prototyped the submission pipeline: file upload → parsing → validation → storage
• Built the first version of the scoring algorithm and tested it against sample flights from previous competitions
• Validated the fairness adjustments with pilots who could tell us whether the results “felt right”

The prototype phase was worth it. The file format turned out to be more complex than the spec suggested, and the fairness algorithm went through three significant revisions before the pilots signed off on it.

Technical Decisions

Scoring and fairness algorithms

The core challenge was that a pilot flying into a headwind is slower than the same pilot flying the same course with a tailwind. A naive time comparison would penalize pilots who flew in poor conditions.

The solution involved:

• Pulling weather data (wind speed, wind direction) from a public meteorological API at the GPS coordinates of each pilot’s airfield, at the time of their flight
• Applying a handicap calculation that adjusted recorded time based on the wind component along the course heading
• Normalizing for altitude and air density (relevant at higher-elevation airfields)

The algorithm was validated iteratively against historical competition results to calibrate the weights.

Data validation

To prevent manipulation, submitted flight files were validated on multiple levels:

• File format integrity check (structure and checksums)
• GPS track continuity (no teleportation, no implausible accelerations)
• Cross-reference between recorded onboard data and external telemetry where available
• Time-window validation (the flight had to occur within the competition window)

Invalid files were flagged for manual review by the race officials, not automatically rejected — the system surfaced the anomaly, humans made the call.

Real-time ranking

As pilots submitted valid runs throughout the competition window (October 8–12), standings updated live. The platform recalculated rankings after each validated submission, applying the fairness adjustments, and published the updated leaderboard.

I kept the ranking logic server-side and served results as plain JSON. The frontend polled for updates every 30 seconds during the competition window. No WebSockets needed — the update frequency didn’t justify the complexity.

Results

The first Air Race X championship ran from October 8–15, 2023.

• 8 pilots competed in the first edition, flying from their home airfields across multiple countries
• All pilots completed their runs within the 5-day competition window using the dedicated recording hardware
• The platform validated every submission without manual intervention for the data integrity checks
• Final results were calculated, rankings confirmed, and published at a live event in Tokyo-Shibuya on October 15

The results are published at airracex.com, including video from the Tokyo broadcast.

Lessons

Prototype before you architect when the domain is new. I had never worked with flight data, meteorological APIs, or sports scoring systems before this project. The 6-week prototyping phase was not extra time — it was the time that prevented me from building the wrong thing.

“Fair” is a judgment, not a formula. The fairness algorithm took three revisions. Not because the math was wrong, but because “fair” in a competitive context is something the competitors have to agree on. The pilots’ feedback on what felt right was as important as the meteorological data.

Working internationally changed how I communicate. This was my first project conducted entirely in English with a team I never met in person. I learned to write more precisely, to ask questions earlier, and to document decisions more carefully than I would on a local project where I could walk into the room.