-
-
Isolated Demo Mode loads four fictional competition workflows without affecting the operator’s real sessions.
-
Qualifying combines overall and women’s rankings, advancement, Byes, DQ handling, and live obstacle tallies.
-
Three Way Racing synchronizes six opening heats, eight final-round heats, Advancers, results, and obstacle tallies.
-
Group Stages tracks matchups, records, winners, wildcards, results, and obstacle tallies in one synchronized view.
-
A complete R32 bracket with automatic winner advancement, run control, Summit Climb scoring, and exports.
-
Standard Mode uses separate, clean storage, so fictional Demo Mode data never affects real operator projects.
Inspiration
Live-to-tape television competition shows often depend on scoring spreadsheets, separate bracket documents, and manual cross-checking while results are changing in real time. I built Leaderboard Master from direct experience managing competition brackets and leaderboards as a television producer. The goal is to give the control-room producer one dependable source of truth instead of having to reconcile fragmented documents in a fast paced environment.
What it does
Leaderboard Master is a macOS desktop application for configuring and running complex obstacle-course events. It supports:
- Qualifying leaderboards with configurable advancement modes
- Multi-round, three-person heat racing with previous-round Advancers, Byes, and manual entrants
- Round-robin group stages with records, standings, and wildcard advancement
- R32-through-Final elimination brackets with automatic winner propagation
- Fastest/farthest scoring, Summit Climb distance scoring, and consistent custom tag handling
- Athlete imports, persistent local sessions, and portable session files
- Clean PDF and CSV outputs for production handoffs
- An isolated Demo Mode with fictional sample competitions
The application is designed as a producer-facing control-room console rather than a public scoreboard. Scoring, advancement, matchups, course configuration, persistence, and exports remain synchronized inside one workflow.
OpenAI Build Week work
Leaderboard Master existed before OpenAI Build Week as an earlier competition-management application. During the July 13–21 submission period, I used GPT-5.6 and Codex to meaningfully extend it into a much more configurable production platform.
The Build Week work includes configurable multi-round heat racing, previous-round Advancer generation with auto seeding, and Bye and manual-entrant workflows. In addition, a consolidated qualifying configuration, expanded scoring and result-state handling, and 'Clean Heats' views and exports. Finally, Summit Climb fastest/farthest scoring, group and bracket workflow improvements, configuration safeguards, persistence isolation, and deterministic fictional Demo Mode playback.
The judge repository contains a detailed Build Week change record identifying the dated pre-Build-Week checkpoint and the extensions completed afterward. The original private development history and Codex session evidence are retained separately so confidential material reflecting real production workflows is not exposed through Git history.
How I built it
The application uses JavaScript, HTML, and CSS inside Electron. Node.js handles desktop integration, persistent local storage, native menus, session import and export, and document-preview workflows.
I used GPT-5.6 as a reasoning partner to translate complicated competition rules into explicit data models, ranking behavior, and user workflows. Codex inspected the existing codebase, planned and implemented changes, refactored shared logic, traced edge cases across dashboards and exports, built deterministic Demo Mode behavior, and performed focused verification. I remained responsible for the competition logic, product decisions, interface behavior, and final acceptance of each change.
Challenges
The hardest challenge was directing AI-assisted development with production-level precision. Leaderboard Master already contained tightly connected scoring, advancement, persistence, bracket, and export pipelines. A seemingly narrow change could unintentionally alter another competition format or break behavior elsewhere in the application.
I had to become extremely deliberate with both GPT-5.6 and Codex. I used GPT-5.6 Sol with extra-high reasoning to turn each requirement into a detailed implementation prompt, then edited those prompts to define the exact scope, permitted files, explicit non-goals, existing behavior that must remain untouched, and targeted verification steps. Negative instructions such as “do not modify shared scoring,” “apply the correction identically in: Standard Mode and Demo Mode,” and “preserve all existing persistence paths” became just as important as describing the requested feature.
When a pass introduced behavior I had not requested or caused a regression in another workflow, I traced the interaction, narrowed the prompt, and separated the work into smaller passes. The central lesson was that effective AI-assisted engineering is not simply asking for a feature. It requires specifying what must change, what must not change, how the edit fits the existing data flow, and how to prove that surrounding workflows still behave correctly. That discipline was essential for safely extending a large application with complex layers like Leaderboard Master.
What I am proud of
Leaderboard Master is a working, coherent producer-facing application rather than a collection of disconnected spreadsheets. Several implementation passes required changes across thousands of lines in an already interconnected codebase. The finished application carries each result consistently from user entry through scoring, rankings, advancement, future-round entrant generation, matchups, bracket propagation, saved state, and PDF or CSV handoffs for producing teams.
The most difficult completed systems include configurable Qualifying advancement, multi-round Three Way Racing with Advancers, Byes and manual entrants, round-robin Group Stages with standings and wildcards, and a complete R32-through-Final bracket. These are the unglamorous but essential systems that keep a competition television production synchronized, giving producers reliable live standings for host commentary, story development, and editorial decisions as results change.
What's next
The next phase is adding more complete competition formats and expanding how much each existing dashboard can be configured for different productions. Group Stages will support variable field and group sizes, more flexible matchup schedules, event divisions, advancement counts, and wildcard paths. Three Way Racing will expand into a multi-stage tournament mode that can carry heat winners and cross-heat qualifiers through successive rounds to a championship final.
I also plan to add new elimination and qualification formats, more configurable seeding and manual-draw workflows, division-specific advancement paths, and stronger connections between sessions so results from one stage can generate the next without rebuilding fields manually. Continued work will improve scoring validation, live producer views, exports, recovery tools, and operator guidance so the application can support an entire competition lifecycle from initial setup through the final result.
Built With
- codex
- css
- electron
- gpt-5.6
- html
- javascript
- node.js
Log in or sign up for Devpost to join the conversation.