Tournated

Tournated is a white-label sports management platform. Federations and clubs run registration, scheduling, live scoring, and rankings in one product instead of stitching spreadsheets and chat threads. I worked across the GraphQL API and Next.js surfaces that make that lifecycle usable under real event load.

Sports organizations needed a single branded system for tournament operations. Fragmented tools meant slow events, broken handoffs between registration and scoring, and no clean way to present rankings under a federation brand.

Ops glue was eating organizer time. Registration, brackets, scoring, and rankings lived in separate places, so events were hard to run, hard to brand, and hard to trust when scores moved fast.

Spreadsheets, messaging apps, and disconnected tools don’t share a data model. Live updates were manual. White-label branding meant rebuilding or forking per federation. Nothing was designed for concurrent scoring traffic.

Federation admins, club organizers, referees/scorers during live events, and players checking schedules and rankings.

• –Multi-tenant white-label without forking the codebase per federation
• –Live scoring had to stay reliable when many matches update at once
• –Complex bracket and scheduling domain logic that non-engineers still need to operate
• –GraphQL payloads had to stay predictable as features grew

Full-stack engineer, NestJS/GraphQL API, Next.js product surface, real-time scoring paths

NestJS + GraphQL on PostgreSQL with Redis for hot paths; Next.js for organizer and player experiences. GraphQL subscriptions for live scoring updates. Tenancy and branding modeled so federations share one product surface with config-driven white-label, not separate apps.

• GraphQL API with subscriptions for live scoring

  Why: Clients need targeted updates during matches without polling every scoreboard.

  Rejected: Pure REST + short polling, simpler initially, but noisy and laggy under concurrent event traffic.

• Shared multi-tenant codebase with white-label config

  Why: Federations need brand identity without multiplying maintenance cost.

  Rejected: Per-federation forks, ships the first brand fast, then becomes unmaintainable.

• Postgres as system of record + Redis for hot realtime paths

  Why: Tournament state must be durable; live score reads need low latency.

  Rejected: Redis-only or document-only stores for core tournament state, weaker relational guarantees for brackets and rankings.

• –Reliable live scoring under concurrent event traffic
• –Multi-tenant white-label without forking the codebase
• –Complex bracket / scheduling domain logic
• –Keeping GraphQL performant as query surfaces grew

• –GraphQL flexibility vs. disciplined query design: without care, N+1 and over-fetching show up under load.
• –White-label config depth vs. product complexity: every federation-specific knob is a support cost.
• –Realtime freshness vs. infrastructure cost: subscriptions are worth it for scoring, not for every screen.

Shipped and iterated on the tournament lifecycle in production: registration through scheduling, live scoring, and rankings, with NestJS/GraphQL backends and Next.js UIs organizers and players actually use during events.

The product moved from core tournament ops toward a fuller federation platform, more of the lifecycle in one place, and white-label expectations rising as more brands came on.

I’d front-load clearer tenancy boundaries and GraphQL performance budgets earlier, and document scoring edge cases as product rules, not tribal knowledge, so the next engineer doesn’t rediscover them under a live event.

Organizers run events in one place. Federations get a branded product. Clubs stop losing hours to ops glue between tools that never shared state.

• Live product at play.tournated.com
• Registration → scoring → rankings in one flow
• White-label ready for federation brands
• API designed for concurrent live events

• –Sports ops is a domain problem first, the stack only matters after the lifecycle is honest.
• –Realtime is a product promise; if scores lag, trust collapses faster than any chart can fix.
• –White-label is an architecture decision, not a CSS theme.

• Next.js
• TypeScript
• NestJS
• GraphQL
• PostgreSQL
• Redis
• Apollo