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