Before You Build Anything, Do This

There's a pattern that plays out constantly in vibe coding communities, and if you've spent any time in this space, you've probably lived it yourself.

Someone gets excited about an idea. They open their vibe coding tool. They start typing. Maybe they've been thinking about this thing for days — they know what they want, they're fired up — so they just start describing it. The AI responds. Something gets generated. They react to it. The AI adjusts. They add something. The AI adds more. Prompt by prompt, the thing takes shape.

This plays out in two ways, and neither is great. The first is the obvious one: things break. Something works, then something else doesn't, then fixing that breaks the first thing, and two hours later you're staring at a mess you're not sure how to get out of. The second is sneakier: things technically work, but the result is a patchwork. Features that were added in whatever order they occurred to you, logic that contradicts itself in places, a project that functions but was never really designed — just assembled. It holds together until it doesn't, and building on top of it gets harder every time.

This is sometimes called cowboy coding. Prompt slinging. Shotgun prompting. The names all point at the same thing: you opened the tool and started firing before you knew what you were aiming at.

Most people assume the fix is a better prompt. It isn't. The fix happens before you ever open your coding tool — and it has nothing to do with technical skill.

Here's what I've come to believe after a year of building this way: when the technical barrier drops, the thing that rises to the top is the quality of your ideas. How clearly you see the problem. How well you understand the people you're solving it for. How honestly you've defined what success looks like. AI can generate ideas — but they'll be generic ones without your context, your instincts, and your understanding of the problem. The ideas worth building come from you. That part is yours — and it turns out, it's the most valuable part of the whole process.

I build primarily in Claude Code, so that's the lens here — but the principles work the same way whether you're in Replit, Lovable, or anything else. The tool doesn't change the thinking.

The 70/30 Secret Nobody Talks About

Here's something I didn't expect when I started vibe coding: most of my time isn't spent coding anything.

I'd estimate that roughly 70% of my time on any given project is planning — thinking through what I'm actually building, why it needs to work the way it does, and what "done" actually looks like. The remaining 30% is actually inside the tool. The coding part is almost the smallest piece of the whole process.

That surprised me at first. You're using an AI to write code — shouldn't that be most of the time?

Not if you're doing it right.

When you give a vibe coding tool a clear, well-scoped plan, it executes fast and accurately. When you give it a vague, half-formed idea, you spend endless cycles trying to steer it back toward something that resembles what you wanted. The planning you skip at the beginning doesn't disappear — it just shows up later as confusion, rework, and the creeping feeling that you're building the wrong thing.

An ounce of prevention, as they say.

Introducing the Vibe Build Blueprint

The Vibe Build Blueprint is the planning workflow I run before Claude writes a single line of code. It's eight steps. Most of them are fast. All of them matter.

It comes from a year of my own building and breaking things — but also from time spent in communities like r/vibecoding, a Reddit forum where serious vibe coders share what's working. Fair warning: a lot of it is deeply technical. But patterns emerge if you read enough of it, and the most consistent ones are about planning, not code. I've done that reading so you don't have to.

One of the clearest patterns that keeps showing up across that community is a mental model called the Architect/Executor split — and it's become the foundation of how I think about every build.

The Architect is where you think. You define what you're building, why it needs to exist, and how it should work before anything gets created.

The Executor is where you build. You take a clear plan and hand it to the AI to implement.

Most people skip straight to Executor. That's where things go sideways.

One thing the Architect always holds in mind: the difference between your broader vision and your current scope. The broader vision is the full picture of what this could eventually become. The current scope is the specific slice you're building right now. Both matter, and keeping them distinct is what keeps the AI calibrated. Without the vision, it thinks too small. Without a tight current scope, it tries to build the moon when you just needed a flashlight. The habit to build: whenever you start a session, give your tool both — where this is ultimately going, and what you want to focus on today.

Here's the full picture:

You might look at that and think: that's a lot of steps for something I was hoping to start this afternoon. Fair. But steps one through four can happen in a single focused conversation before you ever open Claude Code — use a separate Claude chat for this part. Steps five and six happen inside Claude Code before any building starts. Step seven is the actual build. Step eight is five minutes at the end.

The speed at which Claude Code executes when handed a clear plan more than makes up for the time you spend here. You're not slowing down — you're loading the slingshot before you fire.

Before You Start: Install Superpowers

If you're building in Claude Code, there's one thing worth doing before you run a single step of this workflow: install Superpowers.

Superpowers is a free, open-source plugin for Claude Code that adds structure the app doesn't have by default. Without it, Claude Code will happily start writing code the moment you describe something. With it, the tool pauses first — asks clarifying questions, builds a plan, gets your sign-off — before anything gets built. Think of it as bumper lanes at a bowling alley. You're still the one throwing the ball. It just helps make sure it goes somewhere useful.

Installation is about as simple as it gets — just ask Claude Code to install Superpowers for you. It will handle everything. Once it's in place it runs quietly in the background and activates automatically when you need it.

You'll see Superpowers come up again in Step 5, where it does some of its most useful work. But install it now, before anything else — it shapes the experience from the very first session.

Step 1: Define the Problem (Not the Solution)

Most people start vibe coding by describing what they want to build. The better question is why.

Before you write anything down or open any tool, sit with this: what problem am I actually solving, and who has it?

This sounds obvious, but it's easy to skip. You might have a clear picture of what the app looks like — the features, the interface, the thing it does — without being entirely clear on the underlying problem it solves. That matters, because the problem is what keeps you oriented when decisions get hard. When the AI takes something in an unexpected direction, the problem statement is what lets you say "no, that's not it — here's what we're actually trying to do."

Keep it simple. One or two sentences. "I'm building a tool that helps [who] do [what] that [relieves this pain]." That's enough. You don't need a business plan. You just need a clear point to return to.

Step 2: Write the One-Pager

This is the most important document you'll create for any vibe coding project. It doesn't need to be long — one page, maybe less. The goal is to force yourself to make decisions before you're in the middle of building.

Here's the template. Copy it, paste it into a blank document or a new Claude chat, and fill it in before you do anything else:

Project name: 
One-sentence description:

Problem
- What problem does this solve?
- Who has this problem (primary user)?

Goals — what success looks like
- G1:
- G2:

Success metric(s): (example: "user can complete X in under Y steps")

Non-goals — explicitly out of scope for now
- NG1:
- NG2:

Core user flows — plain language
- Flow A: user wants to ____. Steps: 1) ____ 2) ____ 3) ____
- Flow B:

Definition of done — acceptance checks
- When I do ____, I see ____.
- When I do ____, I see ____.
- When I do ____, I see ____.

Open questions
- Q1:
- Q2:

A few things worth calling out. The non-goals section is where you defend against scope creep — write down what's deliberately out of this version so you can stay focused. The definition of done section is where you commit to what "working" actually means. These acceptance checks become your test criteria later, and they're what keep you from convincing yourself that something is done when it isn't quite.

This document is your north star. Every time the build drifts, you come back to it.

Step 3: Map the User Journey

With a one-pager in hand, walk through what someone actually does when they use your thing.

Not a list of features — a narrative. Start from: someone arrives at the page for the first time. What do they see? What do they do first? What happens next? Follow it all the way to the moment the thing does what it's supposed to do. Then follow it through a few edge cases. What if they make a mistake? What if they're missing information?

This exercise surfaces decisions you didn't know you needed to make. It also gives the AI something far more useful than a feature list — it gives it a sequence of events to build toward. Prompting Claude Code from a user journey produces dramatically more coherent results than prompting it from a wish list.

Plain language. Bullet points. No diagrams required. You just need a path.

Step 4: Scope Ruthlessly

This is the step where you fight your own ambition — and it's worth fighting hard.

The first version of anything should be the smallest version that would actually be useful. Not the version with every feature. Not the version you'd eventually want. The version where the core thing works.

If you've filled out your one-pager and mapped your user journey, you probably already have more ideas than you need for version one. Good. Write those ideas down — that's your vision backlog. But cut this build to the minimum that would still constitute a real, working thing.

Scope creep is one of the most common ways vibe coding projects go sideways — and it's not the AI's fault when it happens. We keep adding to the ask before the foundation is stable. One thing at a time. You can always build more.

Step 5: Run the Architect Pass

Here's where it gets interesting — and where Superpowers starts to earn its place in the workflow.

At this point you have a clear problem, a one-pager, a user journey, and a scoped feature set. Now, before you ask Claude Code to build anything, you ask it to plan.

In Claude Code, this is called Plan mode. You describe what you want to build, and instead of writing code, the AI produces a step-by-step plan — what it will create, what sequence it will follow, where the risks are. It asks clarifying questions. It surfaces things you haven't thought of. No files touched, no code written — just thinking on paper.

This is also where Superpowers earns its place. If you installed it before you started (see above), it's already working with you here — its brainstorming and plan-writing features formalize exactly this step, reinforcing the principle of "no changes until the plan is reviewed." What Superpowers doesn't replace is the upstream thinking you did in steps one through four. It helps you plan better once you have clear intent — but the clarity has to come from you first. That's what the Vibe Build Blueprint gives you. The two work together: one handles the thinking, the other handles the discipline.

To run the Architect pass, use this prompt as your starting point. Paste your completed one-pager in at the bottom:

ARCHITECT PASS PROMPT

You are in planning mode. Do NOT write any code and do NOT edit any files.

My goal is to get a step-by-step implementation plan before we build anything.

Based on the project one-pager below, please provide:

A) Any clarifying questions you need answered before planning 
B) Your proposed approach in plain language 
C) A sequence of what you'll build — in order, with each piece described in plain terms 
D) Any risks or things that could go wrong, and how to avoid them 
E) A checklist I can use to verify the build is working

Do not proceed to building until I have reviewed and approved this plan.

Project one-pager: [PASTE YOUR COMPLETED ONE-PAGER HERE]

During the Architect pass, your job is to read and react. Does this match what you had in mind? Is the sequence logical? Are there pieces that seem off? Push back, ask questions, and iterate until the plan feels right. This conversation is basically free. Rework is not.

Step 6: Review and Approve the Plan

Don't skip this.

Once the Architect pass produces a plan, read it. The whole thing. You don't need to understand the code that will eventually be written, but you do need to understand the logic of the plan. Does it solve the problem you defined? Does it follow the user journey you mapped? Does it stay within the scope you set?

If yes — approve it and move on.

If no — go back to the Architect and adjust before anything gets built. Fixing a plan takes five minutes. Fixing a build that went in the wrong direction takes hours.

This is one of the most important things you do as a non-techie vibe coder. You are the verification layer. The AI is fast and capable, but it doesn't know your problem the way you do. The plan review is where your domain knowledge matters most.

Step 7: Build

Now you build.

With an approved plan in hand, Claude Code moves into execution. Things start happening fast — files get created, code gets written, features take shape. This is the satisfying part.

Your job during execution is to stay in the loop without micromanaging. Test what gets built. Click around, try to break things, notice what's missing. When something looks wrong, describe what you expected versus what you're seeing. The more specific your feedback, the better the correction.

A few things to keep on your radar:

Don't expand scope mid-build. If a good idea comes up while you're building, write it down for later. Adding to the plan halfway through is one of the most reliable ways to introduce chaos.

Test between rounds. Every time something new gets built, verify it before asking for the next piece. Small test loops keep problems small.

And if something breaks badly and you don't know what happened — just ask. "What went wrong and what do we need to do to fix it?" has saved more builds than any amount of expertise.

Step 8: The Wrap-Up

This is the step most people skip, and the one that causes the most pain on day two.

To understand why it matters, you need a quick mental model for how Claude Code actually holds onto information — because it's not as automatic as you might hope, and the gaps are real.

The context window — your session's whiteboard

Claude Code's working memory for any given session is called the context window. Think of it like a whiteboard: everything you've discussed, every file it's looked at, every decision you've made together is written there. The problem is the whiteboard has a finite amount of space. Long sessions fill it up.

When it gets full, Claude Code does something called compacting — it automatically summarizes the earlier parts of the conversation to make room to keep going. This keeps your session alive, but summarizing is lossy. Specific details — the exact reasoning behind a decision, the "we decided not to do it that way because..." moments — are the first things to blur or disappear. The broad strokes survive. The nuance often doesn't.

Session Memory — the background note-taker

Claude Code also has a feature called Session Memory that works quietly in the background. As you work, it writes summaries of what happened and stores them. When you start a new session the next day, it pulls those summaries in so Claude isn't starting completely cold. This is genuinely useful and getting better over time.

But there's an important caveat: those summaries are loaded as background knowledge — things that might be relevant — not as active instructions that Claude is definitely following. For a non-techie building across multiple sessions over days or weeks, that distinction matters. Automated summaries are reasonably good at capturing what happened. They're less reliable at capturing why you made a decision, what you're worried about in the build, or exactly what you want to tackle next.

CLAUDE.md — your project's permanent memory

This is your most reliable tool for continuity, and it's worth understanding properly because you'll use it on every project.

CLAUDE.md is a simple text file that lives inside your project folder. Claude Code reads it automatically at the start of every single session — before you type anything — and treats everything in it as standing instructions. It survives compacting. It survives session resets. It survives closing your laptop for a week. Whatever you put in CLAUDE.md is always there when you come back.

Before you start building any new project, do this first:

Ask Claude Code to create a CLAUDE.md file for you. It will scan your project and set it up automatically — you don't have to write anything from scratch or create any folders manually. One-time setup, thirty seconds.

A quick note if you have Superpowers installed: Superpowers creates and manages its own plan files for tracking tasks and build progress — but that's separate from CLAUDE.md. Think of Superpowers' plan files as your build log, and CLAUDE.md as your project's permanent memory. They do different jobs and both are worth having.

Once CLAUDE.md exists, think of it as the living document for your project. It starts with the basics Claude Code generates — your project structure, conventions, key notes — and you add to it over time. Including, most importantly, your session handoff notes.

The wrap-up ritual

Here's the honest picture: Claude Code is handling more continuity automatically than it used to, and Superpowers adds another layer by tracking task-level progress through checkboxes in your build plan. Between the two, the technical state of your project — what's built, what's next in the sequence — is reasonably preserved.

What neither system reliably captures is the human layer: the decisions you made and why, the things that felt fragile, the "don't touch this without thinking carefully" notes, the specific next step you had in your head when you closed your laptop. That's the gap the wrap-up closes.

Five minutes before you end any session, ask Claude Code this:

"Before we close out, give me a short summary of what we built today, what decisions we made and why, anything that's fragile or shouldn't be touched without care, and the single most important next step."

Then take that summary and ask Claude to paste it into the bottom of your CLAUDE.md file using this template:

SESSION HANDOFF NOTE

Date: 
Session goal:

What changed today:
- Change 1:
- Change 2:

Where we are in the plan:
- Completed:
- Next step (be specific — not "keep building" but "add the submit button to the contact form"):

Decisions made and why:
- Decision: / Why:

Things to be careful with:

Next session start prompt:
"Read the session handoff note at the bottom of CLAUDE.md. Confirm the next step. Do not start building until you've told me what we're doing and I've said go."

Copy that last line — the next session start prompt — and actually use it to open your next session. It takes ten seconds and it means Claude Code starts the session oriented and ready, instead of you spending the first twenty minutes reconstructing where you left off.

The combination of CLAUDE.md, Session Memory, and Superpowers' plan tracking isn't redundant — each one is covering a different blind spot. Together, they turn a series of isolated sessions into a coherent build process that actually goes somewhere.

The Blueprint in Practice

Put it all together and the Vibe Build Blueprint looks like this:

Before you open Claude Code: Run steps one through four in a separate planning chat. Define the problem, fill out the one-pager, map the user journey, commit to your scope. Arrive at your coding session with a document in hand, not a vague idea in your head.

First time in a new project: Ask Claude Code to create a CLAUDE.md file for you. One-time setup, thirty seconds, pays dividends for the life of the project.

Before any building starts: Run the Architect pass, review the plan, approve it.

Then build, test, and wrap up.

The whole planning arc for a simple project can take less than an hour. The clarity it buys you is worth five times that. What you're doing is making yourself the architect of the thing before you become its builder. You're the one who knows what this needs to do and why. The AI is extraordinarily capable, but it needs direction — good direction, clear direction. That's your job. And it turns out it's the most important job in the process.

The people who get frustrated with vibe coding are usually the ones who hand the AI a wish and hope for a product. The people who get results are the ones who hand it a plan.

So before you open Claude Code on your next project — open a blank page first.