League OS

Overview

Local football runs on goodwill and group chats. Results are typed into WhatsApp, tables live in someone's notebook, and a player's history disappears the moment they change clubs. League OS gives that world the infrastructure professional leagues take for granted, without asking organisers to learn new habits.

I own the product end to end: the specifications, the API, the database, the mobile app and the WhatsApp integration.

The problem

Existing score apps are built for watching elite football, not running grassroots football. They have no idea who owns a league, who manages a club, or which player belongs where. And any tool that asks a busy organiser to sit at a laptop after every match will lose to WhatsApp.

The solution

Three independent tiers

The model is built around three actors who each own their own accounts: the organisation or competition owner, the club, and the player. They link to each other rather than living inside each other, so a player's profile and record survive a transfer, and a club can play in more than one competition.

User-first accounts

Anyone can sign up and starts as a fan. Creating a league upgrades the account to a creator, with one league per owner at launch. Guest sessions let people browse before signing up; admins get two-factor authentication with a recovery phrase and a documented reset runbook.

Run it from WhatsApp

Through the WhatsApp Cloud API, a league owner can post a result, query standings or broadcast to fans with a message. A command parser turns those messages into the same actions the app performs, so WhatsApp and the app always agree about the state of a league.

The engines

A standings service recomputes tables whenever results change. Match graphics are requested through a queued pipeline and tracked until they are ready to download. A live-ops admin surface handles matchdays, events and transfers, with rate limiting and latency logging on every write.

Architecture

1. Interfaces

   • Mobile app (Expo)
   • WhatsApp for creators & fans
   • Admin live-ops
2. API

   • Auth & sessions
   • League / club / player
   • Fixtures & results
   • Transfers
   • Uploads
3. Engines

   • WhatsApp command parser
   • Standings recompute
   • Graphics requests
   • Content cache
4. Data

   • PostgreSQL (Supabase)
   • Redis
   • Media uploads
   • Versioned SQL migrations

Engineering challenges

Changing the model without losing the product

Midway through, the product direction changed: the global live-score tab was paused and the focus moved to local league management, benchmarked against a three-tier model. That meant redesigning account creation, profile ownership and cross-linking between tiers while keeping the score presentation people already liked. Every step went through a product discussion, an execution matrix and a frozen backend contract before code changed.

Hardening before launch

A release-hardening pass added abuse protection on admin writes, observability on live-ops latency and errors, and database-backed tests for the awkward paths: event updates, transfer status transitions and graphics download access. The full regression passed 80 of 80 tests across 12 suites.

Migrations as a history

The schema grew through small, named migrations: competition drafts, published fixtures, friendly matches, captain flags, self-registration links, shared admins, TOTP. Each is a decision you can read in order.

Outcome

League OS has a working backend, a mobile app and a WhatsApp integration, organised around a three-tier model that matches how grassroots football actually works.

Lessons learned

• Meet people where they already are. For local football, that's WhatsApp.
• Model ownership before features. Who owns a league, a club, a player decides almost everything else.
• Freeze the contract before the code. A written API contract kept mobile and backend moving in parallel.