App // Where the software meets the room

XP Network Mobile

Tournament brackets, live scoring and QR check-in

The original XP Network tournament platform: brackets, live scoring and a QR check-in system that had to work at the door of a real venue.

Year:
2023–2024
Role:
Frontend Software Engineer, early hire
Org:
XP Network
The XP Network mobile app on three phones: ticket redemption, the login screen, and the gadgets list led by Pong of Champions

One platform, two kinds of tournament

01

XP Network ran competitive events end to end: registration, brackets, live scoring, results, and the social layer holding it together. The unusual part was scope: not just esports, but tabletop and real-world tournaments too, in one system.

That is a harder product than it sounds. An esports bracket updates itself because the game reports the score. A beer pong bracket updates because a person standing in a bar tells it to. The same data model has to serve both, and the second one is where the assumptions break.

I joined early, on mobile, in React Native and Expo.

Check-in at the door

02

The feature I owned was QR code table check-in, the flow that authenticates a player and validates them onto a table when they arrive at an event.

It sounds small until you consider where it runs. Someone is at a venue door with a queue behind them, on venue wifi, holding a phone in one hand. The scan has to resolve fast, fail legibly, and never leave an organiser unsure whether a player is checked in. An ambiguous result is worse than a clear failure, because the ambiguous one gets waved through and reappears as a bracket dispute an hour later.

This is the seam where a tournament platform stops being software and becomes an operational tool. It is also the part that taught me the most.

Live means live

03

Scores had to move in real time: to the organiser, to the players, and to whatever screen the venue had pointed at the room. We ran it over MQTT, a publish-subscribe protocol built for exactly this: many subscribers, small frequent messages, unreliable networks.

Polling would have been simpler to write and wrong in the room. A scoreboard that refreshes every few seconds is not perceived as slightly stale; it is perceived as broken, because the crowd saw the cup land before the screen did.

Prototypes that went outside

04

The platform was also a base for companion gadgets tied to tabletop formats. I prototyped those integrations, including the Pong of Champions cup tracker built for a live beer pong tournament in Texas.

Those experiments were the fastest feedback we got. Running our own bracket logic and sync in a loud venue on shared wifi, in front of an audience, surfaced things no staging environment produces, because staging has good wifi and infinite patience.

What it set up

05

The mobile app validated the core of the platform: live tournaments, player engagement, and the bridge between a physical event and digital tracking. It is also the ground the later web app was built on when the company pivoted to the browser.

It is the most formative project in my career so far. It is where I learned to ship early, iterate against real events rather than opinions, and treat the room the software runs in as part of the specification.

The brief

01

XP Network ran competitive events end to end: registration, brackets, live scoring, results, and the social layer holding it together. The unusual part was scope — not just esports, but tabletop and real-world tournaments too, in one system.

An esports bracket updates itself because the game reports the score. A beer pong bracket updates because a person standing in a bar tells it to. The same data model has to serve both, and the second one is where the assumptions break.

Does it still work at the door of a real venue, on venue wifi, with a queue behind you?

Constraints

Framing

02

The feature I owned was QR code table check-in: the flow that authenticates a player and validates them onto a table when they arrive at an event.

It sounds small until you consider where it runs. Someone is at a venue door with a queue behind them, on venue wifi, holding a phone in one hand. The scan has to resolve fast, fail legibly, and never leave an organiser unsure whether a player is checked in.

// The room is part of the specification.

  1. ArriveA player reaches the door with a code
  2. ScanOne hand, venue wifi, a queue behind
  3. ResolveAuthenticated, or legibly refused
  4. SeatValidated onto a table
  5. ScoreResults move to every screen at once

What the room taught us

  • An ambiguous scan gets waved through and returns as a bracket dispute.
  • A scoreboard a few seconds stale is not stale, it is broken.
  • The crowd sees the cup land before the screen does, or you have failed.
  • Staging has good wifi and infinite patience. Venues have neither.
  • The fastest feedback we got was running it in a loud room in Texas.

Interface

03

The scan is the whole interface: it has to resolve fast, fail legibly, and leave nobody guessing. Everything else on the screen is in service of one person making one decision in a few seconds.

Principles

Build

04

React Native and Expo on the client, with scores moving over MQTT — a publish-subscribe protocol built for exactly this: many subscribers, small frequent messages, unreliable networks.

Polling would have been simpler to write and wrong in the room.

  1. Mobile appReact Native + Expo
  2. StateReduxLive scoresPaho MQTTRequestsAxios
  3. Platform backendTournaments, brackets, results

Checklist

Screens

Built with

  • React Native
  • Expo
  • TypeScript
  • Redux
  • Expo Router
  • Paho MQTT
  • Axios
  • Docker

More work