If you haven't vibecoded already, build a game.
Wrote a LinkedIn post about it, but here's how I built one. (clueday.com now)
The Premise
AI has changed a lot about building products. “The traditional design thinking process is dead.” “Anybody can build.” “Prompt engineering is the future.” “We will have billion-dollar solopreneurs.” Irrespective of where you fall on the spectrum of the AI-hype cycle, vibe coding has definitely made it easier to build 0→1 high-fidelity prototypes that can be launched at the click of a button.
I wanted to learn more about popular tools like Lovable and decided to build something I could actually enjoy. Games are one of the simpler things to create because you already have a vision for how they should work. You have an intuition, and preferences built over time of playing a range of similar games in that genre.
Another reason why commencing with a game as your first vibe coding project makes sense is that it is low stakes. If you’re solving for a problem people have, you start getting grand ideas (which is not wrong, but practically not all ideas will be or are meant to be executed). “I can make this a startup,” and “Oh, I need to do more user research,” and “I need to make sure this does not have adverse effects” cycle gets taxing fast. But a game, comparatively, is not under that same bucket of problems you’re trying to solve and hence simpler.
Building Process
I also write this to showcase how the process of building has changed. In traditional design thinking, you would use the double diamond approach: explore the problem space, narrow it down to one “how might we” statement, expand again to brainstorm solutions, and narrow back down (with external feedback) to the solution.
In this situation, I started off directly with the final solution I had a vision for and then worked my way almost backwards to understanding what pain points people were facing and what problems I was really solving. There was no singular how might we statement, or round robin of brainstorming. Even so, its way more iterative and definitely faster (does not make for easier documentation).
There is a RISK I want to highlight. For a game, you’re not really thinking about a problem space as much as about delight and engagement. If I was solving for a problem like connecting people with hospitals’ emergency rooms and started with a solution, working ‘backwards’ could trap me in my own assumptions. I’d get stuck in my first mindset, and without a big push to overcome inertia I’d remain at a local minimum instead of reaching the global maximum of optimal solutions.
Just another reason to vibe code a game first.
Ideation
My first step was brainstorming with ChatGPT about what to build. I knew I wanted a product that could help me improve at Scrabble (lot of ‘healthy competition’ in my family). I also knew that I like playing Sudoku while on the Subway, that there was a big craze around Wordle during the pandemic, and that Crosswords are timeless.
I decided to go with Option 6 (Signal, clue-based word guessing game) for no other reason than I would learn a plethora of new words for Scrabble.
Vibe-Coding
Lovable is an AI-powered no-code builder where you can build a complete, deployed full-stack web application from a chat prompt, without writing code. I used Lovable’s Pro Plan. I had 110 credits on Lovable at the beginning of the build (I’ve ended on 40 credits and don’t know if that’s a good thing or a bad thing).
I usually work on the prompt with ChatGPT as well to define users, journey, UI, but in the scenario I wanted to experiment and not give too many constraints so I directly pulled the content from ChatGPT. I also gave the references of the games above.
Design 3 screens, landing page, game page, and results page for a game called “Signal” (Minimal Clue Deduction), matching the UI from the screens above.
Core idea: Guess a concept using the fewest clues.
Clues revealed one by one: (something like 20 questions) “It’s a tool” “Used in kitchens” “Can be sharp” → Answer: Knife
This was the first Result.
I can tell you how bad the gameplay mechanism was but it won’t do it justice.
Manually clicking submit.
Manually clicking each clue to unveil it.
Random two green boxes highlighted in the results page (and so much more)
If this was my first ever Lovable creation I would have pulled my hair out in frustration and left the platform. So I understand why there are a lot of skeptics. Thankfully I have done this a couple times (once before to build emos, and to make a pitch for adding GPT functionality to TechLadies) that I knew this was going to be a trip.
Prompting (with User Feedback)
It’s a lot of prompting and therefore a lot of iterations. For example, the way I play Scrabble I go for those bigger 6, 7, 8 letter words. I knew the words the person should guess needs to have at least that many letters. So that was one prompt. Similarly here is a breakdown of all the prompts over the course of a day.
The prompts above were not all standalones that I thought by myself. While building I started sharing the live Lovable link with people, and got multiple rounds of feedback:
“Why is there only one round to play in a day?” I realized having more could keep people on the platform if they could explore difficult puzzles, so I added a chronicles section.
“It’s allowing words that aren’t actually English.” I put a prompt and Lovable chose to go with the FreeDictionary API. It handled the integration on its own.
“I want statistics.” I wanted to ask why, but then I added the feature because there’s no backlog and therefore no prioritization (yet).
PS: Since this was written two weeks back, I decided the statistics weren’t adding to the experience yet and hidden them from view.
I also went ahead and added a hard mode, so people who are voracious can try this with 7-8 letter words, while the baseline default is 6-letter words.
I connected Lovable with my GitHub so that in the future I could have access to the code if I lose access to Lovable, it’s my way of having a backup.
Branding and Domain
The name Signal was always a placeholder. I needed to figure out naming, plus see if I could get more inspiration for associated features. I named it ClueDay (literally no brainpower was used here) because you get daily set of clues to guess the word.
I aimed to showcase that there’s going to be clues, and that’s how I ended up with the magnifying glass.
I really like the logo of Steve Job’s NeXT computers, with its 4 letters in almost a grid-like shape.
I’m a big fan of Predictably Irrational by Dan Ariely, the book is in orange and blue so that’s how the logo’s color palette was born.
PS: Two weeks of user testing has revealed the Wordle colors are way too ingrained, and no one reads instructions. A problem for future Tanya.
I really didn’t do any iteration because I had the vision before I even started designing it in Figma. I also really like Notion, which is why there is this shadow effect to it.
I connected it to my domain and ClueDay was born on April 4, 2026.
Reflections
I said it was low stakes but very quickly I started thinking about retention, about whether the clues were good enough, about traffic numbers and analytics. So vibe-coding a game might not be the best solution to overthinking after all.
Future Improvements (Now I Have a Backlog)
Clue generation: There is a static table for the next 365 days with the words and generated clues. I did tell Lovable to start with a difficult clue and make it easier as more letters are revealed, but it clearly does not know the difference between a vague clue and a direct clue.
Mobile experience: You have to scroll to access the on-screen keyboard, which is not fun at all. I still haven’t figured it out, so any feedback would help.
PS: Two weeks glad to say this is solved!
User sign-ups and reminders: I know most sites allow sign ups so you get a reminder and track your progress, but I didn’t want to handle personal data. Probably if there’s enough traffic (linking ClueDay again if you’ve made it till here without clicking it wink wink).
Scrabble-first: Since it originally started for my Scrabble problem, I want to ensure each guess has X, J, Q, K, Z letters but it would become easier to guess the words, so there’s a trade-off decision to be made.
Overall I’m very satisfied with how it looks, feels and flows. In conclusion, a few things for AI-driven 0 → 1 product development.
Multiple prototypes: For something with real stakes (people's time, money, trust), the current process is slow and broken. Build 5 different prototypes, with varied concepts and hypotheses and bring them to the users for testing.
Cheap user feedback: The cost of being wrong is lower than before, and each piece of feedback is easy to act on (add an archive, plug in a dictionary API, show stats). Get your product in front of people within days, not weeks and iterate fast.
Intuition/Taste/Clarity needs time: You cannot be a novice in a field and expect to have a strong product intuition. It’s built over time. Doing it for a game you have spent years playing is easy. Put in the hours to build it for the field in which you’re solving the problem.
PS: This was written two weeks back, and its crazy to think how much I have improved the website since then. Will write a follow up covering, stay tuned.
what prompted me to go all-in and buy clueday.com,
how I optimized for Search Engine,
connected a backend so people could submit their own words and clues, and more!
If you want to solve user problems, build something people need.
If you also want them to have fun, build something people want.