Let Me Share the Story Behind My First Vibe Coding Project
Updated: Sep 24
What if I just built a simple app for this myself?
Yeah, that was the first thought that hit me, and it happened nowhere near my laptop. Just a regular afternoon, me sitting on a chair during my lunch break. Just a random thought that suddently push me to make a real product from vibe coding skill that I have been learning.
A little background first. I love playing badminton, purely for fun. I play weekly with a group of friends. A while back, I joined an Indonesian community here in Singapore called IPA (Indonesian Professional Association), and since I love badminton, even though I'm nowhere near an expert, I joined one of their sub-groups, Unplugged Badminton. I hadn't actually joined one of their sessions yet at that point, but I'd been watching and thinking about how the group ran things.
The sign-up system was exactly what you'd expect from a casual sports group: everything ran through WhatsApp/telegram group. Someone posts the slot, and everyone copies the same message and pastes their name underneath it, every single week. Pretty much every other badminton session I've come across in Singapore runs the same way. It works, until the chat gets long, and then it's genuinely hard to even scroll back and see who's in. If more people show up than the pax required, there's a waiting list too, but it's not really a system, just whoever happens to be paying attention. And if someone cancels, updating that list is entirely manual. Nobody gets told a spot opened up.
As a product designer, I had a wild idea: what if I just built a simple app for this myself?
My coding skills are pretty rusty, almost nonexistent, I’d say. Even though I learned a little HTML and CSS years ago, I haven’t really used them since. If I had this idea a year ago, I genuinely don’t think I would have been able to pull it off. But with AI, I actually could. It made it possible for me to turn an idea into something functional, even without strong coding skills.
This became my self-taught version of "vibe coding." Instead of taking a course to learn AI-assisted building, I picked a real problem from my own life and learned by shipping something. This is my first own web app. No formal course, just a real use case and a lot of back-and-forth with Claude.
Let's go through my process. The loop was simple:
I brought the idea → Claude wrote the script → Claude walked me through how to deploy and ship it → I tested it and tried to break it → I came back with UI/UX feedback → repeat.
Round one: starting small
I first asked for something spreadsheet-shaped: "like Excel, but auto-updating." One place for sessions, one place for sign-ups, first-come-first-served registration, and an automatically moving waitlist.
Before writing anything, Claude asked clarifying questions. How should people identify themselves when registering? Who can cancel? Who can manage sessions? What does "notify the waitlist" even mean if the tool cannot send messages into a chat?
Answering those questions was real product design work, even before any code existed. The implementation could wait; I first had to decide what the product was supposed to do.
Round two: from spreadsheet to a real app
The spreadsheet version reached its ceiling because it could not push real notifications. So I asked for the real thing: an app with sessions, registrations, waitlists, skill levels, and actual notifications.
I learned that the app was really two pieces sharing one Google Sheet as the database: a Google Apps Script backend and a front end hosted as a static site on GitHub Pages.
Claude walked me through deploying each part. I pasted the backend into the Apps Script editor, then explicitly deployed a new version. Saving the script alone does not update the live link. That's basically a staging-versus-production lesson, and I recognised it immediately from my own field. For the front end, I committed the file to GitHub, which redeploys itself automatically.
The whole setup was surprisingly practical: not a giant stack, just a small system assembled around the problem it needed to solve. The split was driven by a product decision. I wanted the app to open inside Telegram as a proper Mini App, because that is where the group actually is. I did not want to force everyone into a separate browser tab.
But Apps Script cannot host that experience directly. It serves pages inside a sandboxed frame that Telegram's own SDK cannot reach. The front end therefore had to live somewhere Telegram could reach directly, which is the real reason it ended up on GitHub Pages. A hosting decision turned out to be a direct consequence of a product decision I actually cared about.
Round three: my actual job once there was something to test
Once there was something real to use, my role changed. I was no longer just describing what I wanted. I was no longer just churning my product idea, describe the vision from my mind. I was testing, noticing friction, and pushing back.
Here are five things (out of 100s) I caught by actually using the app myself:
Editing a session was buried behind a "⋯" menu. I flagged that a hidden action reads as unavailable, not merely tucked away. Editing needed to be a visible button on the session card.
The date, time, and level pickers felt broken, and not just on mobile. Desktop too. I test on my phone and inside the Telegram desktop app, which is a narrow window driven by a mouse rather than a touchscreen. That edge case meant the pickers needed to switch style based on how narrow the window is, not just whether the device is "a phone."
Tapping a form field on iPhone zoomed the whole page in. It turned out that form fields need at least a 16px font or iOS Safari zooms on focus. A small technical fix, but a big perceived-quality difference.
Session cards needed matching heights when sitting side by side. Long rosters should scroll inside the card instead of stretching it. On a phone, where there is one card per row, the card should hug its content and cap the roster with a "show all" toggle.
Not every edit deserves an email. Changing the time, place, court, or price should email everyone with the old and new values. Changing only the skill-level tag should not spam anyone. Deciding which changes are "loud" versus "silent" was a UX call, not a technical one.
One source of truth
There was also a systems-thinking lesson. At one point, the front end briefly existed as two nearly identical copies: one served from Apps Script and one on GitHub Pages. They drifted out of sync and caused a confusing partial outage.
The fix was merging them into one file that detects at runtime which environment it is running in. That felt like the same instinct as keeping one source of truth in a design system instead of letting two teams maintain "the same" component separately. Duplication is easy at the start. The cost appears later, when the copies quietly become different products.
There was real testing behind this too: hundreds of automated checks on the backend logic, plus browser tests at real device sizes. That mattered to me because I wanted confidence that a fix for one thing was not quietly breaking another.
What I actually built
I still did not write a line of code. But that does not mean I did not build the product.
Every decision that shaped what the app actually is still had to come from someone paying attention to the people using it: who can cancel, what counts as a notification, whether a hidden menu reads as unavailable, which changes deserve an email, and what should happen when a roster gets too long.
Claude executed quickly and well. The product judgment was still mine.
Read the fuller design write-up, including the research, before/afters, and usability testing, here: Unplugged Badminton
Comments