Why League Night is offline-first

Most disc golf courses don’t have reliable cell service. League Night is designed so the entire night can run without the internet—because anything less breaks at the worst possible time, leaving directors scrambling back to pen and paper.

Context / Problem

One of the first non-negotiable decisions was that League Night had to work offline. Not “mostly offline” or “offline with degraded features.” Completely offline.

That immediately ruled out a lot of common architectural patterns and made everything else harder—but it forced the software to align with reality instead of assumptions.

Decision / Direction

League nights are held at public parks, often with spotty or nonexistent signal, with directors juggling sign-ins, payouts, questions, and late arrivals under time pressure. If the software fails, the league doesn’t pause; the director goes back to pen and paper.

Any tool that requires connectivity becomes optional at best and a liability at worst. So the decision is to design for full offline operation.

Tradeoffs / Constraints

Building offline-first changes everything:

• No assuming a reachable server
• No reliance on real-time validation
• No pushing complexity “to the backend”
• Conflicts, retries, and partial state must be handled

It’s harder, but it demands discipline: clear data models, explicit state transitions, and resilient workflows. Those constraints make the system more predictable.

Why this works

The entire administrative flow—check-in, grouping, payouts, ace pot tracking—must run locally. Syncing happens later, when the director is home, the connection is stable, and time pressure is gone. League night is not the time to see “Looks like the server is unavailable.”

Offline-first adds complexity for the builder, not the user. That’s a trade worth making. The moment the software asks the director to “just wait a second while it loads,” it has already failed its job.