Table of contents
Open Table of contents
The numbers, before anything else
Our club night runs once a week, three hours a session. Anywhere from 24 to 32 players show up, and we have 4 courts to put them on.
Badminton doubles puts four players on a court at once. Four courts, full doubles, means 16 people playing at any given moment. On a quiet week with 24 players, that’s 8 standing around. On a full week with 32, it’s 16 — as many people waiting as playing.
That ratio is the whole problem. It’s not that courts are scarce in some abstract sense; it’s that roughly half the room is idle at any moment, and somebody has to decide, fairly and continuously, who that half is.
What tracking it by hand actually involves
Before there was an app for this, there was a person — an organiser, a notebook or a phone’s notes app, and four separate mental queues to keep straight.
Each court needs its own line of who’s next. A game finishes, and the organiser has to know, instantly, whose turn it is for that specific court, not just “someone waiting.” People rotate in and out as they arrive late or leave early. Some want to play with specific partners. Someone’s been waiting through two full games and is starting to wonder if they’ve been forgotten, while someone else only just walked in.
None of that is hard in isolation. It’s hard because it’s happening on four courts at once, continuously, for three hours, while the organiser is also trying to actually play.
Where a clipboard breaks down
The honest failure mode isn’t that manual tracking is impossible — people ran sessions this way for years. It’s that it doesn’t scale cleanly past a certain ratio of players to courts, and it costs the organiser their own night to keep it fair.
A typical moment: a game ends on court two, someone shouts it’s over, and the organiser has to update court two’s queue while still holding court one, three and four in their head, correctly, from memory. Do that every few minutes for three hours and small errors creep in — someone gets skipped, someone plays twice in a row, someone just leaves because the wait felt arbitrary. None of that is anyone being careless. It’s a queueing problem being run on a format — memory and a notebook — that was never built to hold four independent, constantly-changing lists at once.
That’s the gap 1up Court Queue was built to close. Not to make badminton more complicated, but to take the four-queues-at-once problem off one person’s memory and put it somewhere it can’t drift: a screen that tracks who’s on, who’s next, and for which court, so the organiser can actually play their own session instead of running it from the sideline all night.
The part that’s actually interesting
What I find genuinely interesting, looking back, is that the trigger wasn’t a technical itch — it was just running out of attention. Four queues is about where a person’s working memory stops being reliable under interruption, and 24 to 32 players over three hours is more than enough interruption to find that limit.
That’s a more honest origin story than “I wanted to build an app.” I wanted to stop losing track mid-rotation, and software turned out to be the right tool for a problem that was really about memory, not about badminton at all.
Try it yourself
The build side of this — why it’s a single offline HTML file with no server behind it — is covered on the 1up Court Queue project page. This post is just the part before the code: the session that made the problem obvious in the first place.