How We Built GarageLeague

A spreadsheet is a fine tool for a static schedule. It falls apart the moment something changes mid-season, because a spreadsheet has no way to notify anyone — someone has to manually message the league, and that message competes with everything else happening in a group chat. Reschedules, in particular, were the recurring breaking point organizers kept describing to us.

Before any screens got designed, we sat in on actual weeknight league operations — watching how organizers actually managed a live schedule change, not how they described doing it after the fact. That gap between the described process and the real one is usually where the most important design decisions live.

What we saw confirmed the core problem but also surfaced a second one: standings updates were just as manual as scheduling, and just as easy to get wrong when someone forgot to update the spreadsheet after a game.

Rather than designing a generic sports app, we built the information architecture around an organizer's real weekly rhythm: set up the season once, handle the reschedule that will inevitably happen, post standings after games without extra manual steps. Every screen exists to serve one of those three moments, not a hypothetical feature list.

Organizers needed a fast way to manage a season from a laptop; players needed schedule and standings in their pocket on game night. We built the marketing site and the React Native app in parallel against a shared backend, so both experiences stayed consistent instead of drifting apart the way separately built web and mobile products often do.

We ran a full pilot season with an actual grassroots league before opening the app more broadly. That pilot surfaced scheduling edge cases — weather cancellations, forfeits, double-headers — that never would have shown up in a demo environment, and every one of them fed back into the product before launch.

Schedules, standings, and rosters moved into one place instead of being split across a spreadsheet and a group chat. Reschedules now update the app instantly instead of relying on someone remembering to message everyone. The whole system was validated through a live, full-length pilot season with a real league before wider rollout — not just internal testing.

Shadow the real workflow before designing a single screen — the actual failure point is rarely the one people describe first when you ask them directly. And pilot with real users doing real, high-stakes activity (a real season, not a sandbox) before calling anything finished; that's where the edge cases that actually matter show up.