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

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.
- ArriveA player reaches the door with a code
- ScanOne hand, venue wifi, a queue behind
- ResolveAuthenticated, or legibly refused
- SeatValidated onto a table
- 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.
- Mobile appReact Native + Expo
- StateReduxLive scoresPaho MQTTRequestsAxios
- Platform backendTournaments, brackets, results
Checklist
Screens
Built with
- React Native
- Expo
- TypeScript
- Redux
- Expo Router
- Paho MQTT
- Axios
- Docker

