Unplugged Badminton

Turning a WhatsApp group's sign-up chaos into a self-serve booking app

Personal project . Product design & AI-assisted build

Visit live website: https://gjsjessy.github.io/unplugged-badminton/

Live telegram bot: https://t.me/unplugged_badmintonbot

Product Overview

Unplugged Badminton is a weekly badminton group that runs, like most casual sports groups do, entirely inside a WhatsApp thread. Someone posts a session with a date, a court, a price per head and players reply to claim a spot.

It's simple until it isn't: there's no real way to tell who claimed a spot first, no waitlist once the court fills up, and no way to know you've been bumped up from the waitlist except by re-reading the chat.

As a member of the group and the person who usually ends up manually tracking who's in, I saw this as a product problem I was well placed to fix: a manual, error-prone process running on a channel that was never built for structured data.

My Role & Responsibility

In this project I was the Product Designer, and by prompting Claude - the "developer" executing the build myself.

As the designer, I drew on my own experience in the group to define the problem and set the goals:

Zero login friction: just a name and email, no account to create.
Fair and automatic: first-come-first-served enforced by the system, not by chat speed. Notified when a slot is ready for me.
Matched by level: supporting both open sessions and skill-gated ones.

Prompting Claude put me in the engineer's seat too - specifying, testing, and refining every version myself. I didn't write the code, but I owned whether it was right.

Initial Research

Because I'm part of the community this app serves, my research started as lived experience rather than formal interviews - but it was still grounded in real, repeated pain points I'd watched (and personally felt) across many weeks of sessions:

Headcounts were tracked by manually counting chat replies.
There was no formal waitlist - if a spot opened up, whoever happened to be scrolling at the right moment claimed it.
Skill level was never captured, so "friendly" and "competitive" players sometimes ended up in the same game.
Cancellations got buried in chat and were easy to miss entirely.

Distilled, that lived experience pointed to the same four gaps every time:

The Design & Building Process

From Ideation to a Brief

Before any prompting started, the four gaps above had to turn into an actual decision: fix the existing chat flow, build a lightweight spreadsheet tracker, or build a real app. Weighing that, together with the three goals above, is what became the brief I actually brought to Claude.

My Prompting Process

Every feature in this product went through the same loop, repeated until it was right rather than solved in one pass.

The Solution

Session Posting: Centralizing What Used to Live in Chat

One structured form for every session.
Instead of a free-text message players had to decode themselves, I designed a simple posting form that captures date, time, location, court, price per head, and how many players are needed. Every session ends up with the same shape, so there's nothing left for anyone to guess at.
Level tags built into the session itself.
I added a level field (Open to all, Beginner, Intermediate, Advanced, or Intermediate & Advanced) directly on the session rather than buried in a description. That way a player can tell at a glance whether a session is right for them, instead of finding out mid-game that they're outmatched or under-challenged.
A single board instead of a scrolling thread.
Every session now lives on one centralized board that updates in real time. The intent was to remove the "scroll up and hope I didn't miss it" habit entirely, so checking what's available becomes a five-second glance rather than a hunt through chat history.

Registration & Waitlist: Fair, Automatic, and Self-Explanatory

A lightweight registration, not an account.
Players register with just their name, email, optional phone number, and skill level, no account creation and no extra steps. I kept the form intentionally short, since the barrier to signing up for a casual weekly game should be close to zero.
Waitlisting that happens without anyone deciding it.
Once a session hits its pax count, every registration after that is automatically placed on a waitlist instead of a confirmed spot. This was the fix for the original problem: whoever replied fastest in chat used to win the spot, and now the system enforces order instead of speed.
Status that's visible, not assumed.
Every player can see exactly where they stand, whether that's Confirmed or Waitlist #2, and so can the organiser, on the same roster in real time. Nobody has to ask "am I in?" because the answer is already on the screen.

Skill-Level Tagging: Matching Players to the Right Game

A level set once, reused everywhere.
Players tag their own skill level a single time, and it travels with them into every session they join afterward. I designed it this way so returning players never have to re-enter information the system already knows about them.
Optional gating, organiser's choice.
Organisers can restrict a session to specific levels or leave it open to everyone. Giving them that control meant the app could support a casual pickup game and a more competitive one without needing two different systems.
Level visible right on the roster.
Each player's level tag shows up next to their name on the roster itself, so an organiser scanning the list can immediately tell whether the mix of players actually matches what the session was meant for.

Notifications: Automated confirmation & cancellation

Confirmation the moment you register.
Signing up triggers an instant email, either a straightforward confirmation or a clear waitlist position like "you're #2." Players know their status the second they act, not sometime later when someone happens to check the chat.
Automatic promotion when a spot opens.
When someone cancels, the next person on the waitlist is promoted automatically and gets a real "you're in!" email. This closes the exact gap that used to frustrate players most: getting bumped up with no way of actually finding out.
Zero manual work for the organiser.
None of this depends on an organiser remembering to update anyone. The notification logic runs on its own, turning a job that used to rely on someone's memory into something the system just handles.

Log in mechanism : Getting In Without a Password & Telegram Token Integration

Started with email & password login - changed due to early users feedback
The first version asked for an email and a password, the default most sign-up forms use. Real feedback from the group flagged it almost immediately as friction nobody wanted for what's ultimately a casual badminton chat. They also mentioned that some users might have concern that we store the password.
Replaced it with a one-time code.
Email is now used only for identification and notifications, and logging in sends a one-time code instead of checking a stored password.
Telegram users skip the step entirely.
Since Telegram already verifies who someone is, players signed in through Telegram log in seamlessly using their existing Telegram identity, no code, no password, no extra screen. Designing for that meant recognising the platform had already solved identity, so the app didn't need to solve it again.

Under the Hood: Two Pieces, One Spreadsheet as the Database

The platform shift changed what was possible.
The group moved from WhatsApp to Telegram partway through this project. Telegram's Bot API and Mini Apps meant sessions could post directly into the group, players could get notified without opening anything separate, and the sign-up form could open right inside the chat they were already in.
Two pieces, one source of truth.
The product runs as two pieces sharing a single Google Sheet as the database: a Google Apps Script backend, and a front end hosted as a static site on GitHub Pages, since Apps Script alone can't host a real Telegram Mini App experience.
Github: https://github.com/gjsjessy/unplugged-badminton
Every action is just a row in a sheet.
Every session and every registration writes straight into that shared spreadsheet as a new row, a "Sessions" table and a "Registrations" table, structured the same way any relational database would be, just visible and editable as an ordinary sheet. That was deliberate: no separate database to manage, and I could always see exactly what the app was doing underneath.

The First Built Evaluation

Using the app myself surfaced real usability issues that a spec alone wouldn't have caught:

Location was swallowing the card. Venue name and full address were sharing one field; split into a prominent place name plus a quiet, clamped address line with an "Open in Maps" link.
Names were being truncated. Player names > the actual point of a roster > were cut off mid-word; changed to wrap onto a second line instead.
Form design was not mobile friendly. The form dropdown, pop up , text field all looks like webapp normal form and dropdown. I give reference and recommendations, instruction to the AI to change it to meet the mobile app accessibility
Spacing, new sessions button that was displayed in a wrong priority and focus especially on mobile. Originally displayed in a full length button. Big in the imiddle. Part of the top header and really taking alot of space at the header. I struct and prompt the AI with my recommendations on where the button should sit.
Cancel button styling. A default browser border made the cancel action look heavier than intended; restyled to match the rest of the interface.

Usability Testing

The testing plan has been shared with the real Unplugged Badminton group, asking regular players to register, cancel, and (for a few volunteers) trigger a waitlist promotion, with feedback gathered directly from the group afterward. Results are still coming in.

One real piece of feedback has already led to a change, even before the full round of testing wrapped up: the original email-and-password sign-in was flagged as unnecessary friction for a casual group. That's what prompted the switch to a one-time email code instead of a password, and seamless sign-in for anyone already using Telegram - described above under "Log in mechanism : Getting In Without a Password & Telegram Token Integration"

A few other questions are still open, framed as hypotheses until the rest of the feedback comes in:

Registering more than one person at once Hypothesis to validate: players often sign up on behalf of a partner or friend in the same message ("me + 1"), so a single-registrant-only flow may push people back to informal chat sign-ups for group bookings. Testing should confirm whether a "register a plus-one" option is worth adding.
Returning players re-entering their details every time Hypothesis to validate: regular players will re-type the same name, email, and level for every session, which is friction a returning-user flow (remembering a player on the same device) could remove. Testing should confirm how much this friction actually bothers people versus how rarely they register.
How this connects back to the group chat Hypothesis to validate: since the app can't push messages into the group on its own, players may forget to check the link for status changes. Testing should confirm whether a share/deep-link button on the confirmation screen (so players can drop their own "I'm in!" back into the group) meaningfully increases how often people revisit the page.

My Key Takeaway and What's Next

This was one of my first real exercises in vibe coding, and before anything else, I want to say this: I'm genuinely happy that with AI, I could bring my own product vision to life without needing strong technical skills to pull it off. I'm also just happy that being part of something as simple as a weekly badminton group gave me the chance to experiment in the first place. These are the 3 main takeaways from this mini project;

Building a product with AI isn't skipping product design
There's a perception going around that AI can replace a product designer. And honestly, I can see where it comes from. I built a working web app without opening Figma once, without producing a single design file, and the interface still turned out decent. But this project confirmed something I already believed: product design was never just about producing UI screens. It's about making meaningful decisions at the product level. It sits close to product management, but it's different, because what you're deciding is what the AI builds, and how the product actually feels to use. What changed for me is that I can now bring my own design thinking to life without knowing how to code. I don't think this replaces software development either. You still need to understand, at least roughly, what the AI is building and why, otherwise you can't make good calls about it.
Being part of the community you're designing for is its own kind of research
A product doesn't need to start with a big idea. It can start from a small moment, when you sit with something annoying in your own week and actually name the problem. The first pain points here didn't come from formal interviews. They came from my own experience of signing up for games in a group chat, and that was enough to point at real, specific gaps. I'm glad I got to build something small out of a hobby, and glad that AI let me take this experiment all the way to something people can actually use.
Real feedback moves faster than a full test cycle
Because this was a small side project, I mostly just talked to potential users casually. Those short conversations taught me more about my design and product decisions than I expected. Not every useful piece of feedback needs a scheduled usability session. Sometimes it's enough to talk about your idea openly and let people react to it, and it doesn't always have to come from your main users. It can come from a partner, a friend, a colleague. The switch from passwords to a one time code came from exactly that: a single comment, before the formal testing round had even finished. A good reminder that shipping to real people starts the feedback loop immediately, not at the end of a test phase.

Next up: finishing the group's feedback round, and folding whatever comes back, plus-one registration, returning-player shortcuts, deep-linking back to chat, into the next iteration. What I'm most excited about, honestly, is seeing whether the community keeps using it. If they do, that's what lets me keep improving it with real usage instead of guesses.