ReadyRef

The whole flag football league in one app. Organizers schedule it, refs run the game live from their phone, and fans anywhere watch the score, stats, and recaps in real time.

Comment

Inspiration

ReadyRef started on a field, not in an editor. My wife and I coach the U16 co-ed team with Bluewater Flag Football, and also play in an adult co-ed league. I have a terrible memory paired with a deep love of process and creativity, so keeping player names, rules, and the state of the game straight was a constant scramble. I love spreading happiness, and a co-ed teen team is a great place to do it, but doing that while tracking downs and remembering fifteen names is genuinely hectic.

Then came the price shock. We relied on parent volunteers to keep a whiteboard updated, which works right up until nobody's free, and even when it was updated, the parents trying to follow along mostly couldn't see it. Kids, coaches, parents, and sometimes even the refs kept asking the same two questions:

Is it third or fourth down? How much time is left?

So I went looking for a scoreboard. The cheapest one I could find ran about $300, not a number a brand-new league can absorb. That reframed the whole problem: the thing standing between our league and a working scoreboard wasn't difficulty, it was money we didn't have. And everyone on that field already had a phone in their pocket.

What it does

ReadyRef puts the whole flag football league in one app.

  • Referees run the game live from a phone: clock, score, downs, flags, penalties.
  • Organizers create a league, generate a season schedule, and manage teams and rosters in minutes.
  • Fans watch a live scoreboard from anywhere, with real-time reactions, momentum, standings, and player leaderboards.
  • Every game leaves behind a shareable recap page, so Saturday morning becomes something worth posting.
  • Every league gets a public microsite so local parents can actually find it in a search engine.

How I built it

I started building with Codex and Android Studio, and later with Codex and Claude, using Android Studio as a means to test the native app.

It began as a simple down counter. Then a clock. Then it tracked girl plays, a rule in our co-ed adult league where every third down has to go to a girl or it's a penalty, which is almost impossible to hold in your head while a play is happening. From there I just started flowing: what if it could do this? then this, then that. Each answer opened another question.

Under the hood it's React + TypeScript wrapped in Capacitor, so one codebase ships as an Android app and as a web app. Firebase does the heavy lifting: Firestore for durable league and season records, Realtime Database for anything that has to move at the speed of a whistle, and Cloud Functions for everything the client must not be trusted to do.

Challenges I ran into

  • Live data is a UX problem before it's an infrastructure problem. If the ref taps "touchdown" and the number flickers, they stop trusting the app and reach for the paper scoresheet.
  • Trusting the client. An early version stored a subscription entitlement somewhere the user could write to. It worked perfectly, and it also meant anyone with a browser console could grant themselves the top tier. Moving it server-side changed how I read every schema after that.
  • Deploy targets are part of the architecture. A rules deploy silently did nothing once because it ran from the wrong directory. The rules I was reading locally were not the rules that were live.
  • Four different humans, one app. The organizer, the referee, the coach, and the fan each want a different product. Getting the home screen to answer one question per role, what do I do right now?, took several rewrites.
  • Building it solo. Backend, app, marketing site, billing, art, and support, on nights and weekends around an actual season.

Accomplishments that I'm proud of

  • A real league can run a real season on it: schedule, refereeing, standings, and all.
  • The $300 problem is gone. A scoreboard now costs a phone somebody already owns, and is viewable from any screen.
  • Fans finally have something. They were the biggest group on that sideline and the only one with no product at all.
  • The girl plays rule, the thing that started it, is tracked automatically with the tap of a button, so nobody has to argue about it mid-drive.
  • It ships to Android and the web from one codebase.

What I learned

The snowball effect of seeing something come to life is addictive, and I'm still hooked. There's something special about watching a thing you only imagined turn into something real that other people use.

Beyond that: never trust what the client can write; design for the smallest screen and actually measure it; and write down every trap the moment you hit it, so the second encounter costs minutes instead of a weekend.

What's next for ReadyRef

  • A rulebook AI assistant in the referee's pocket, so "is that a legal rush?" is one question away, with the citation attached.
  • A trophy case with earnable cosmetics so fans have an identity that outlives a single season.
  • Getting ReadyRef into the hands of leagues beyond ours.

ReadyRef exists because a league like ours shouldn't have to choose between a scoreboard and a season, and because once you've seen an idea come to life, you want to do it again.

Built With

Share this project:

Updates

posted an update —

ReadyRef is available now on Google Play!

A whole 23 hours before the deadline lol.

The Google Play approval process was smooth for me, but definitely the most stressful part of the build. It was something outside of my control.

From closed testing to Play Store listing, it took about 18 days. My timeline was 14 days for closed testing (standard), 3 days for production approval, and 1 day for final listing.

Log in or sign up for Devpost to join the conversation.

posted an update —

One of my favourite parts about developing one thing is how we end up fixing something else completely. With ReadyRef, I want users to be able to use any cheap remote as a controller. What I found out after ordering a remote is that the controls aren't just simple keyboard mappings. Instead, they're pixel-perfect swipes / gestures. I wrote a script to capture the input, regardless of it being a button or swipe, and map it to a button. This effectively made any cheap Bluetooth controller able to be used in the app.

Log in or sign up for Devpost to join the conversation.

Submission history