The biggest time sink in any build isn't the code. It's realizing halfway through that your data model is wrong, or your logic doesn't account for something obvious, or you built the right thing in the wrong order.
I used to do that constantly. Start coding, hit a wall, refactor, lose momentum, repeat.
Now I don't touch Cursor until Claude and I have talked through the whole thing. Not vaguely. Specifically. And it's changed how fast I can ship.
The Problem With Just Jumping In
Vibe coding is real. You get an idea, you open Cursor, you start prompting, and two hours later you have something that half-works but is built on assumptions you never actually verified.
The code runs. But the structure is shaky. You know it. And now you have to decide whether to push through or tear it down.
That's a tax you pay for skipping the planning step. It's not always fatal, but it adds up across every project.
What I Do Instead
Before I open any code editor, I open a Claude conversation and I treat it like a technical co-founder who's going to poke holes in my idea.
I describe what I'm building. Not vaguely, not with buzzwords. I explain the problem, who it's for, what the core loop is, and what I think the main pieces are.
Then I ask Claude to tell me what I'm missing.
Not "what do you think" — that's too open. I ask specific questions:
- What edge cases am I not accounting for?
- What's the simplest data model that handles this?
- What order should I build this in to avoid blockers?
- What's the riskiest assumption in my plan?
These aren't fancy prompts. They're just the questions a good engineer would ask before writing anything.
The Data Model Conversation
This one alone is worth the 20 minutes.
I describe the entities in my system, how they relate, and what operations I need to run on them. Claude will usually catch something immediately. A missing foreign key. A many-to-many I glossed over. A field that's going to create problems when I try to query it.
I've had Claude stop me from building a whole feature the wrong way just by asking: "How will you query that at scale? Walk me through the read path."
Turns out I hadn't thought about the read path. I'd only thought about writing data. Classic mistake. Twenty seconds to catch it in conversation. Hours to fix it after the fact.
The Build Order Conversation
This one matters more than most people think.
When you're building solo, sequence is everything. Build the wrong thing first and you're constantly blocked, constantly going back, constantly context-switching between layers that aren't ready.
I'll lay out everything I think needs to exist in the app and ask Claude to suggest a build order based on dependencies. What needs to exist before something else can work? What can I stub out and come back to? What's the fastest path to something I can actually test?
It's not magic. But having it laid out clearly, with reasoning, means I don't have to figure that out while I'm also writing code. My brain stays in one mode at a time.
The Assumptions Audit
My favorite part of the pre-build conversation is asking Claude to surface my assumptions.
I'll say something like: "Here's my plan. What am I assuming that might not be true? What would break this if I'm wrong?"
Claude is good at this. Not perfect. But it will flag things like: you're assuming users will do X, but what if they do Y? You're assuming this API returns data in this format, have you checked? You're assuming this can run synchronously, but what happens if it takes 10 seconds?
Some of it I already knew. Some of it I hadn't thought about. Either way, I'd rather know before I'm three days in.
Turning the Plan Into a Prompt Stack
Once the planning conversation is done, I do one more thing before touching Cursor.
I ask Claude to summarize the build plan in a format I can use as context in future prompts. A structured breakdown: the goal, the data model, the build order, the known edge cases, the constraints.
That summary becomes my anchor. I paste it into Cursor when I start a new session. I paste it into Claude when I need to work through a specific piece. Everything stays grounded in the same plan instead of drifting.
This is the part most people skip because it feels like overhead. It's not. It's the thing that keeps your build coherent when you come back to it after a day away or when a feature gets more complicated than you expected.
The full prompt sequence, including how I structure the context summary and what I listen for in each response, is inside Inner Circle. If you're building solo and want to stop losing hours to mid-build confusion, that's where to start.
Keep building
- Plan, Then Execute from the prompt library
- Read Before Write from the prompt library
- How I Run My Entire Business by Talking to It
- The full Vaylo prompt library, new drops weekly
