How I used vibe-coding to validate a years-old idea — and what it showed me about modern product tools available to PMs today.

Tools: Lovable  ·  Timeline: 1 day

TLDR; The Hook

What if, instead of opening a social media app and accidentally doom-scrolling for 20 minutes, you had a quick alternative — something fun, low-stakes, and done in under a minute?

That’s the idea behind this project: a tap-as-many-spots-as-you-can game where targets get faster as the clock ticks down. Simple to learn, repeatable, and capped at 60 seconds. Using Lovable, the idea went from concept to published game in a single day.

Context & Problem

THE GAP

Social media is engineered for engagement — and that’s the problem. I’ve been trying to reduce my screen time, and I noticed I often reach for my phone out of habit, not intention. I just wanted a “Brain Break” between tasks, and social media is no longer the way to do that.

TARGET USER

Myself — someone who enjoys simple games and wants an alternative to passive social media consumption. This is classic dogfooding: build for the person you know best.

WHY NOW?

I’d had this game concept in my head for years but always assumed it would take days of development to execute. Vibe-coding tools changed that assumption. This project was also a chance to personally validate how fast modern AI-assisted development has become.

Goals & Success Metrics

This project has a specific goal. It’s nothing Earth shattering.

GOAL: Build a Game.

Ship a playable, published game by end of day. This was the primary target, and it was intentionally binary: done or not done.

Bonus — HYPOTHETICAL PRODUCT KPIS

If this were a real product, I’d track these engagement metrics to determine whether the game itself was working:

• Conversion: page visits vs. “Start Game” clicks
• Engagement depth: session time longer than 60 seconds (indicating replays or exploration)
• Retention signals: repeat visitors and score-sharing rate

Framing both goals upfront kept me honest about what I was actually building — a prototype, not a product launch. Outlining KPIs (while not critical) did help in identifying what was important in the product itself. More on that later.

Process & Decision-Making

SCOPING THE MVP

My initial vision was ambitious: multiple levels, false targets mixed in, increasing difficulty tiers. I had been thinking about this game for years. But as I started writing out the initial prompt, I hit a natural gut-check.

If you need more than three sentences to describe how a game works, it’s too complicated. Vibe-coding successfully relies on keeping things simple. Agents are still very linear, so keeping prompts tight and direct is best.

I stripped it back to the bare minimum. I used the classic arcade game as my mental model — simple rules, escalating speed, immediate feedback. Everything else got cut.

RESEARCH (HONEST TAKE)

I did zero user research. I didn’t validate demand, check if similar games existed, or identify a market. For a real product, that would be a red flag. For a one-day prototype meant to test a tool and prove an idea was buildable — it was the right call. Being honest about what kind of project this is matters.

TOOL SELECTION

There are several vibe-coding IDEs available right now — Lovable, Base44, Replit, Cursor, Claude Code, and others. I chose Lovable specifically because of timing: they were running #SheBuilds, a free-to-use hackathon on International Women’s Day , which lowered the cost of experimentation to zero. Good enough reason to pick a tool when you’re prototyping.

Challenges & How I Solved Them

CHALLENGE 1: LEARNING A BRAND NEW TOOL

I had never used Lovable or vibe-coded before, so I had no mental model for the workflow. My first move was to find a micro-course before touching anything. I came across Little Parrot: Build Your First App with Lovable that covered the basics. Front-loading the learning paid off. The course took an hour, and I moved faster in the actual build because I wasn’t figuring out the tool at the same time as the product.

CHALLENGE 2: DEBUGGING WITHOUT TOUCHING THE CODE

My instinct when something breaks is to go into the code. That’s not how vibe-coding works. In the early iterations, spots kept spawning after the game ended and I didn’t know why. I had to shift my approach: describe the problem in chat, use Lovable’s “plan” mode to reason through it, and stay focused on one issue at a time. The agent wanted to solve things immediately — I had to resist letting it spiral into multiple changes at once and get confused.

CHALLENGE 3: KNOWING WHEN TO STOP

Scope creep is real, even on one-day projects. It happened in this project, too. I added a pause mode and a share button that weren’t in the original plan. I even started experimenting with colour-coded targets for added complexity. But I didn’t end up adding it because of an external factor: Lovable began rate-limiting usage toward the end of the hackathon day. Sometimes external constraints are the best product manager. 😎

Outcome & Learnings

DID IT MEET THE GOAL?

Yes. I shipped a playable, published game in one day. I shared it with friends and family — and they played it. For a zero-research, one-day prototype, that’s a meaningful signal.

Give it a try yourself! Follow the link -> SPOTS: Test Your Reflexes

WHAT I’D DO DIFFERENTLY

I wouldn’t use Lovable for my next project. Making UI changes through a chat interface felt slow when I just wanted to click and adjust directly. I want to try another tool and compare the experience firsthand.

BIGGEST TAKEAWAY

We’re in a genuinely new era of prototyping. I didn’t need to learn React, configure hosting, or fiddle with UI components. What would have taken days took hours. When I need to validate an idea quickly, vibe-coding is now my default starting point — not a fallback.

Skills Demonstrated

• MVP Definition
• Rapid Prototyping
• Tradeoff Thinking
• Tool Judgment
• Shipping Discipline
• Experimentation Mindset