"One platform for everyone at the tournament — arbiters, players, and spectators"
Overview #
The Problem #
Anyone who has organized a chess tournament knows the chaos behind the scenes. Arbiters bounce between Excel files for player lists, Google drive for documents, and legacy desktop programs for pairings. Results get entered twice. Files go missing. Someone always has the wrong version of the spreadsheet.
TournamentEssentials was born out of frustration with exactly this. The goal was to build something that actually fits how tournaments work — where multiple arbiters need to enter results at the same time, where players want to check pairings on their phone, and where organizers shouldn’t need to be IT experts to run a clean event.
What I built #
A web platform that covers the full tournament lifecycle: registration and approvals, round-by-round pairing generation, live result entry across multiple arbiters simultaneously, real-time standings and pairings for players and spectators, and print-ready materials for everything from namecards to pairing posters.
The backend is written in Go with a clean architecture and a complete REST API. The player-facing public web is built in AnalogJS, and the organizer dashboard in Angular. Both are actively in development.
Where it stands now #
The backend is complete and after some inevitable tweaks will be production ready. The public web is functional with tournament discovery, live pairings, and player registration. The organizer dashboard is the current focus.
Coming up:
- Full organizer dashboard — tournament creation, registration management, pairing control
- Automated pairing with the JavaFo engine (Swiss and Round Robin)
- PDF generation for all print materials
- Mobile app for on-site arbiters
- Big-screen presentation view for venues
- Integration with local companies to provide print and digital advertising material for the tournaments
- Tournament Website creator integration
- Live chess games integration
Interesting Challenges #
A permission system that reflects how tournaments actually work #
Different staff members need very different levels of access. A sector arbiter should only be able to enter results for their assigned boards — not touch other parts of the tournament. A print manager shouldn’t be able to mess with pairings.
Instead of rigid preset roles, I built a flexible permission system where each staff member’s access is defined by what actions they can take, on which sections, and on which board range. It’s more work to set up, but it means the platform can accommodate how any real tournament is organized — without shoehorning it into a rigid role structure.
Learning Go through a real project #
This was my first serious project in Go, and it pushed me much further than tutorials ever could. Clean architecture, structured error handling, dependency injection, building a REST API from scratch without the safety net of an opinionated framework — Go made me be deliberate about every decision in a way I hadn’t been before.
Technologies Used #
Backend #
- Go with Gin: REST API built with a clean 4-layer architecture
- PostgreSQL: Primary database
- JWT authentication: HTTP-only cookie-based auth with refresh token rotation
Frontend #
- AnalogJS: Public-facing web app for players and spectators, Organizer and staff dashboard
- TailwindCSS: Styling across both apps
Tools & Services #
- JaVaFo and bbpPairings: FIDE-compliant pairing engines
- Docker: Deployment
- Figma and Claude Design: UI/UX design
- Swagger: API documentation