01 · THE ROUTINE
One game. Lots of moving parts.
Every weekend brought the same work: find out who can play, account for preferred positions and ability, negotiate teams, share the line-up and revisit it when availability changed. The goal was not to automate judgement away. It was to make the process faster, clearer and easier to trust.
02 · THE PRODUCT MODEL
Balance assistance with organiser control.
FairPlay combines player profiles, availability, fixtures and team building. The balancing logic creates a useful starting point, while the organiser can still review and adjust the result.
Show how the teams were shaped.
Player information and team totals make the result easier to discuss.
Keep a person in the loop.
Generated teams support the organiser’s decision; they do not become an unquestionable answer.
Separate drafts from published teams.
Players can update availability without unintentionally changing the line-up everyone sees.
Design around Saturday morning.
The product follows the actual rhythm of a local group rather than a generic sports dashboard.
03 · REPORTED PILOT
From half an hour to a few minutes.
Time spent preparing teams. This is a reported pilot observation, not an independently measured or controlled study.
Early feedback also described fewer disagreements and more balanced matches. Those qualitative observations are useful signals, but the product remains an early-stage pilot rather than a mature commercial service.
04 · AI AS A MAKING PARTNER
Move from design files to working software.
AI supported exploration, prototyping and implementation across balancing logic, authentication, database work and deployment. Human review remained central: defining the problem, making interaction decisions, testing the product with the group and deciding what to change.
The interface artwork above is an editorial illustration using fictional player markers. The working product is live and continues to evolve.