The PM's guide to vibe-coding your own product

Hey Impactful PM! It’s Areesha :)

First, thank you. You're one of the 171 people who stuck around through our very awkward "we've been gone 18 months" emails. That's a small number and we're weirdly proud of it. You're the actual core of this thing now.

So let's earn it. Starting today, and every week from here.

Today's post is the one we wish someone had handed us two years ago: how to take an idea in your head and turn it into a working product, by yourself, using AI. No engineers. No budget. One weekend.

This is the single highest-leverage skill an aspiring PM can build right now. Not because you'll become an engineer (you won't), but because "I built this" beats "I have an idea for this" in every interview, every portfolio, and every conversation you'll ever have about product.

Let’s get into it →

FIRST, THE THING NOBODY TELLS YOU

There's a phrase floating around: "vibe coding." Andrej Karpathy coined it in early 2025, and it describes AI-assisted building where you just describe what you want in natural language and let the AI figure out the code.

It works. It also breaks fast, and here's why: when you tell an AI "build me a login page," it has to make dozens of decisions you never specified. Which authentication method? What happens on a failed attempt? Where does the session live? It guesses. Then you spend four hours undoing its guesses.

The fix is the thing 2026 figured out and 2025 didn't: write the spec first. The industry now calls this spec-driven development, and it's become the default approach for serious AI-assisted building. Define your requirements, edge cases, and constraints up front, and the AI has a target instead of a guess.

Which is very good news for you specifically. Because writing a clear spec is not an engineering skill.

It's a PM skill. It's the PM skill.

THE FIVE STEPS (SAME FOR WEB, MOBILE, OR DESKTOP)

Every AI-built product follows the same shape, whatever you're building:

1. Ideate, find a problem worth solving

2. Spec, write a PRD detailed enough that a stranger could build it

3. Prototype, get a clickable version fast

4. Build, turn the prototype into something that actually works

5. Ship, put it somewhere real people can use it

Most people rush 1 and 2 to get to the fun part. That's exactly backwards. Steps 1 and 2 are where 80% of your outcome is decided.

Let's walk through each one. And we'll build something real along the way.

OUR EXAMPLE: THE INTERVIEW STORY BANK

Let's not build a to-do app. Let's build something you'd actually use.

Here's a problem most of you have right now: you're prepping for PM interviews. You've got maybe 8-10 good stories from your work life: the time you pushed back on a stakeholder, the time your launch flopped and you learned something. But when the interviewer asks "tell me about a time you handled conflicting priorities," your brain goes completely blank and you tell the wrong story badly.

So: an Interview Story Bank. A small app where you write your stories once in STAR format, tag them by the competency they prove (prioritization, stakeholder management, dealing with failure), and then search them by competency when you're prepping.

Simple enough to build in a weekend. Useful enough that you'll actually keep it. Perfect.

STEP 1: IDEATE (30 MINUTES, NOT 3 DAYS)

You already have ideas. What you need is to pick one that's small enough to finish.

The filter we use. Three questions:

• Do I personally have this problem? (If no, you'll abandon it by Sunday.)

• Can I describe the whole thing in two sentences? (If no, it's too big for a first build.)

• Would I still use it if it were slightly ugly? (If no, it's a nice-to-have, not a problem.)

How to use AI here: don't ask it for ideas. Ask it to poke holes in yours. Try this:

"I want to build [your idea]. Act as a skeptical product
manager. Ask me the 10 hardest questions about who this is
for, whether they'd actually use it, and what's already
solving this problem today. Don't be encouraging."

That last sentence matters. AI's default mode is enthusiastic agreement, which is useless here. Explicitly ask for the hard version.

STEP 2: WRITE THE PRD (THIS IS THE WHOLE GAME)

Read this bit twice. If your PRD is vague, no AI on earth will save you. If it's precise, even a mediocre tool will produce something decent.

Your PRD needs to answer, concretely:

• Problem statement: who hurts, and how, in one paragraph. No jargon.

• The user: one specific person, not a demographic. "A BA with 2 years of experience applying to APM roles" beats "job seekers."

• User flows: click by click. What does the user see first? What do they tap? What happens next?

• The data: what exactly gets stored? For our Story Bank: story title, situation, task, action, result, tags, date created.

• Edge cases: what if there are zero stories? What if a story has no tags? What if someone writes 500 of them?

• Explicitly out of scope: this is the one everyone skips and it's the most valuable. Write down what you are NOT building. "No login. No sharing. No mobile app. Single user, browser only." This is how you stop the AI from wandering off building a social network.

• Look and feel: three adjectives and one reference. "Clean, calm, text-first. Like Notion but simpler."

How to use AI here. The technique that actually works:

Don't ask AI to write your PRD from a one-line prompt. You'll get generic mush. Instead, make it interview you:

"You're helping me write a PRD for a small web app. I'll
describe my idea, then I want you to interview me one
question at a time until you have enough detail that a
developer who has never spoken to me could build it
correctly. Ask about user flows, data, edge cases, and
anything I've left ambiguous. Don't write the PRD until
you've finished asking. Start now."

One question at a time is the key instruction. It forces you to actually think instead of skimming a wall of questions. Expect 15-25 questions. Expect to discover your idea was fuzzier than you thought. That's the point, and it's much cheaper to discover it now than three hours into building.

Then: "Now write the PRD, with a section listing everything explicitly out of scope."

Save this file. It's now the most valuable asset in your project. You'll paste it into every tool you touch from here.

STEP 3: PROTOTYPE (GET SOMETHING CLICKABLE)

Now the fun part. Here's where the tool landscape actually stands in 2026. One myth worth killing first:

Myth: you use one tool to wireframe, another for UI, another to deploy.
Reality: these platforms each do the whole job. You pick one and go end to end. Chaining them together just creates work.

The honest state of the main options:

• Lovable: the best starting point if you don't code. Produces the most polished output, least intimidating chat interface, one-click deploy. Comparisons consistently note it's the strongest pick for non-developers.

• Replit: the most feature-rich and powerful of the bunch. Built-in hosting, database, and key-value store all in one workspace. Asks more of you upfront but gets further. Best if you need real full-stack behavior.

• Bolt: similar output quality to Lovable, and you can see the code as it builds, which is genuinely good for learning. Weaker integrations ecosystem though.

• v0 (from Vercel): produces excellent UI, arguably the best in this group, and the smoothest deploy flow. But there's no backend layer at all: no database, no auth. It's a frontend tool. If you're not a developer, this one will frustrate you fast.

Our pick for the Story Bank: Lovable. It's a small single-user app with a simple data model, which is exactly its sweet spot.

How to prompt it: paste your entire PRD as the first message. Not a summary. The whole thing. Then add:

"Build this as a single-page web app. Start with only the
core flow: create a story, tag it, list all stories. Do not
add features that aren't in this PRD. Show me that working
before we add anything else."

That last line is your protection against scope creep. AI tools love to helpfully add a dashboard you didn't ask for.

STEP 4: BUILD (WHERE THE 70% BECOMES 100%)

Here's an honest thing you should hear from us rather than learn the hard way: vibe coding gets you roughly 70% of the way to a working app very fast. The last 30% is where it gets hard, bugs that reappear when you fix other bugs, and the general problem that fixing what you can't read is difficult.

You will hit this. It's normal. Two moves that help:

1. Iterate in small, specific asks. Not "make it better." Instead: "When I click Save with an empty title field, nothing happens and no error shows. Add an inline error message under the title field." One problem, one description, one expected outcome.

2. Know when to graduate. When the in-browser tool starts going in circles, the well-worn path is: export your project to GitHub, then continue in Cursor or Claude Code. This is a genuinely common workflow in 2026, build the scaffold and UI in Lovable, then move to a proper AI coding tool for the fiddly logic. Both Lovable and Bolt generate portable, standard code, so this export is clean. (Replit is more coupled to its own infrastructure, so moving off it costs more.)

Also, please: don't put anything sensitive in these apps. Not real customer data, not anything you'd be upset to leak. Security is one of the genuinely weak spots of AI-generated code, and "vibe coding is fun until you leak your database credentials" is a real sentence people have had to say. For a personal Story Bank, fine. For anything with other people's data, get a real engineer to look at it.

STEP 5: SHIP IT

Deployment used to be the scary part. It mostly isn't anymore. Lovable, Replit, and v0 all publish with roughly one click, and Replit includes hosting in the workspace.

But shipping isn't just deploying. Do these three things:

1. Give it to three real people. Not for compliments, watch where they get confused. That's your next PRD update.

2. Write down what you learned. What did you cut? What broke? What surprised you? This is the raw material for your portfolio and your interview stories. (Meta: put it in the Story Bank.)

3. Put the link somewhere public. Your LinkedIn, your resume, your portfolio. "I built and shipped this" is a different sentence than "I'm interested in product."

THE PART THAT ACTUALLY MATTERS

Here's why we opened this relaunch with this post.

There's a version of "learning product management" that's all reading, frameworks, case studies, someone's threaded advice. It feels productive. It rarely changes anything.

Then there's the version where you have a working thing with a URL, and you can say: here's the problem I found, here's what I chose not to build and why, here's what broke and what I did about it.

The second one is what an interviewer is actually listening for. And in 2026, for the first time, the gap between those two versions is one weekend and zero rupees.

So build the small, dumb, useful thing. It compounds.