A low-latency operating layer for live pickleball.

Challenge

Running a pickleball tournament or league does not forgive sluggish software. Organizers juggle brackets, seeding, schedules, live scores, and broadcast graphics in real time, and the tools they reach for — usually spreadsheets and generic scoreboard apps — leave too much room for desynchronization and ambiguous state.

A scorer, a schedule, and a broadcast overlay all reading from different sources is how game day falls apart. The job was to make one source of truth that every surface trusts.

We framed CourtCommand as an operations problem first and a product problem second. It had to be fast, multi-tenant, and synchronized across every surface, with a backend that could be trusted before a single screen was designed.

That meant building the engine first: tournaments, leagues, seasons, brackets, live scoring, and scheduling as a hardened API, with the broadcast overlay treated as a first-class consumer of the same real-time data rather than a bolt-on.

Solution

The backend is a Go 1.24 service (Chi v5 router) over PostgreSQL 17, with type-safe queries generated by sqlc and migrations embedded via Goose. Redis 7 handles pub/sub, sessions, and rate limiting, and six WebSocket channels push live state to every connected client. It landed as 170+ endpoints across eight implementation phases, 29 migrations, and 62 automated tests before the UI work began.

CourtCommand is two products in one codebase: the management platform (tournaments, leagues, brackets, live scoring, scheduling, and player/team/organization management) and a standalone broadcast-overlay suite with themeable graphics that read live from the same engine and sell bundled or on their own.

Results

CourtCommand reads as purpose-built operating infrastructure for live pickleball, not a scoreboard skin. With the real-time core complete and the public platform live, the product is shaped by the demands of an actual game-day room.