Fairchild World Cup
A complete user-facing tournament application: responsive interface, scoring logic, live application state, dashboards, and a real data model — shipped, deployed, and iterated on the basis of how people actually used it.
01Overview
A tournament application built for a real competition with real participants. It handles the whole product surface — entry, scoring, standings, and dashboards — on a responsive interface designed for people checking it on a phone during an event rather than at a desk afterwards.
02Problem
Tournaments run on spreadsheets and group chats. Standings go stale the moment someone forgets to update them, scoring disputes have no authoritative record, and every participant asks the organiser the same question. The need is not sophisticated — it is a single live source of truth that participants can check themselves.
03David's role
- Sole designer and developer: data model, scoring logic, application state, interface, and deployment.
- Designed the responsive experience mobile-first, on the assumption of in-venue phone use.
- Shipped to production and iterated the product against real participant usage.
04Architecture
A full-stack web application with a data model covering participants, fixtures, and results; scoring logic deriving standings from recorded results; application state keeping views consistent; and dashboard views presenting standings and progress. Deployed to a managed platform with continuous deployment.
05How it works
- 01Model
- 02Record
- 03Score
- 04Present
- 05Iterate
- 01
Model
Participants, fixtures, and results are modelled as the tournament's underlying data.
- 02
Record
Results are entered as the competition progresses.
- 03
Score
Scoring logic derives standings and progression from recorded results rather than from a maintained tally.
- 04
Present
Dashboards show current standings and tournament state to every participant.
- 05
Iterate
The product was refined in response to how participants actually used it during the event.
06AI & technology
- Built through AI-directed development — architecture, implementation, and iteration driven with AI tooling as the primary development method
07Integrations
- Deployed on a managed hosting platform with continuous deployment from source control
08Human control & governance
- Results entry is controlled rather than open, so standings have a single authoritative source.
- Standings are derived from recorded results rather than manually maintained, so the record and the display cannot disagree.
09Key design decisions
The decision, the alternative it was chosen over, and why.
- 01
Decision
Derive standings from recorded results rather than storing a running tally.
Instead of
Maintaining standings as their own updatable records.
Why
A stored tally and its underlying results drift apart the first time an entry is corrected, and then nobody knows which is right. Deriving means a correction propagates automatically and the displayed standings are always a function of the actual record.
- 02
Decision
Design mobile-first for in-venue use.
Instead of
A desktop-first layout adapted down to small screens.
Why
Nobody checks tournament standings at a desk. Every real use is someone pulling out a phone between rounds, so the small screen is the primary design target and the desktop view is the adaptation.
- 03
Decision
Ship a real product to real users rather than building a portfolio demo.
Instead of
A more technically elaborate application without actual participants.
Why
Real users produce requirements that cannot be imagined — edge cases in scoring, confusion in navigation, things needed mid-event. Shipping to an actual competition is what turned it into product work with feedback rather than an exercise.
10Tradeoffs
- Scoped to one tournament format; it is not a general tournament platform and does not try to be.
- Deployed on a managed platform for speed and zero operational overhead, accepting that hosting choice as a dependency.
- Optimised for the participant view; organiser tooling is deliberately minimal.
11Outcome
A complete, deployed, user-facing product with real participants — the full arc from data model to production and iteration, owned end to end. It is included here because shipping something people actually used, and refining it on that basis, demonstrates product judgment that architecture documents cannot.
12Evidence
- Live deployment
- Publicly deployed and linked from David's resume as a portfolio application.
- Product scope
- Responsive interface, scoring logic, application state, data model, dashboards, deployment, and post-launch iteration.