What this is: a working draft of what it would take to grow MySFL beyond our current 12 franchises, using everything the app already does today as the baseline. Part 1 is a factual summary of what's live right now. Part 2 is a first-pass, opinionated strawman of what might need to change — treat it as a starting point to argue with, not a finished plan.
How to use this page: click the 💬 comment button under any section to read or add a comment on that specific point. Comments post instantly and are visible to both of us. We'll revisit this together, fold everything in, and publish a revised draft.
Each of the 12 managers picks an 18-player squad every round via the Submit Team tab, ahead of a round deadline. Players score SFL points from their real NRL performance (tries, goals, tackles, etc.), pulled automatically from Champion Data via our NRL stats scraper. Submissions auto-finalise at the deadline with no manual step — rollovers and eligibility checks run automatically, and interim/live scores update while matches are in progress.
Managers are paired head-to-head each round; whoever's squad scores more SFL points wins the fixture. The ladder tracks wins, losses, points for/against across the season, with a live "in-progress" view that updates as real matches happen, not just after a round is finalised.
Alongside the main ladder, two secondary competitions run in parallel: the Bani-Fai 7s knockout tournament (its own team selection, fixtures and elimination bracket) and the Championship Belt (a defend-or-lose title that changes hands based on round results). Both have their own admin setup and auto-processing.
One admin (currently Gerrad) manages the whole competition: player data issues, round finalisation overrides, the NRL/Reserve Grade stats scrapers, franchise management, and scoring corrections. Most of the weekly grind — finalising rounds, backfilling scores, updating the ladder — now runs automatically via scheduled jobs, with manual tools available as a fallback.
Automated emails cover scores digests, submission confirmations, and admin alerts on data issues — each with its own on/off switch, and managers can opt out individually. Staging and production are kept clearly separated so test emails never reach real managers by mistake.
React frontend on Vercel, Supabase backend (Postgres + Auth + Edge Functions + scheduled jobs), fully separate staging and production environments with their own databases. Production data is synced down to staging weekly so testing happens against realistic data without risking the live season.
Today the app is built around exactly one competition of 12 franchises. Scaling likely means the data model needs to support many independent leagues running at once — each with its own managers, fixtures, ladder and settings — rather than everything being implicitly "the one league." That's a real structural change, not just a UI one: most tables and RPCs currently assume a single season/competition context.
Right now every setup step (adding a franchise, configuring a round, setting up Bani-Fai) happens by hand through admin tools built for one league. A scaled version probably needs a "create a new league" flow a commissioner can run themselves — invite managers, set squad size and scoring rules, pick a season — without an engineer in the loop each time.
One global admin doesn't scale past a handful of leagues. Each league probably needs its own commissioner role — scoped to their league only — with the "super admin" tools (scraper management, platform-wide settings) staying restricted to a small platform-owner group.
Going beyond 12 participants raises real UX questions: does a single league grow past 12, or do we support many 12-team leagues instead? Either way, we'd need a proper signup/invite flow, rather than an admin manually creating each franchise record by hand as happens today.
The NRL stats scraper and scoring pipeline currently run for one league's worth of players and rounds. With many leagues potentially reusing the same underlying NRL data, scraped stats and computed scores probably need to become shared platform data that multiple leagues read from, rather than being recomputed per league.
Today this is a free hobby project for 12 mates. If it grows to more leagues and more people, someone pays for the infra one way or another — worth deciding early whether this stays free-for-friends-only, moves to a small entry fee per league, or something else, since it affects a lot of downstream decisions (payments, refunds, support expectations).
More leagues means more scheduled jobs, more emails, more concurrent traffic at deadline time, and likely outgrowing Supabase's free tier. Worth an early, honest look at what a jump in usage does to cost and reliability before it becomes an urgent problem instead of a planned one.