The short version
After building around a problem I saw at school, I started applying the same instinct to another environment I know extremely well: a volleyball club. TeamSet is designed around the awkward reality of clubs—overlapping teams, changing roles, shared events, and people who are sometimes both player and coach.
Inside the project
Selected screens and details.
A closer look at the product in its current form.
Why I built it
Club life was already showing me the requirements.
Playing, coaching, coordinating youth teams, and previously acting as player-coach meant I saw both sides of a club. A normal week involves attendance, event changes, parents, coaches, jersey numbers, team memberships, and people with several roles at once.
Most tools simplify that reality until the club has to work around the software. TeamSet starts with the real structure instead.
Product model
One person can belong to several teams—and hold several roles.
TeamSet separates a global user account from club membership, team membership, and per-team roles. Someone can be a player in one team, a trainer in another, and belong to more than one club. Shared events create one participant record even when several teams attend.
- Player and Trainer roles can coexist for the same person.
- Events, RSVPs, participant lists, and team information share one model.
- Offline reading is supported; only low-risk attendance changes are queued offline.
Where it is now
The product works; distribution is the remaining step.
The repository contains a Flutter app, Fastify API, MySQL data model, Next.js public site, real-time updates, notifications, and deployment/operations documentation. As of August 2026, the web and API are deployed and an Android release candidate has been signed and device-tested. Store publication and iOS distribution still require owner-side steps.
That distinction matters: TeamSet is much further than a concept, but it is not presented here as a broadly launched product.
What I learned
The exceptions are where the product becomes honest.
The most valuable design work has been modeling the exceptions: recurring events that change once, trainers visiting another team, a user changing email without losing history, and a club archiving something without corrupting future attendance. The data model is where the product becomes honest.