Every project starts the same way. A half-formed idea, a problem that needs solving, and a blank screen staring back at you.
Most builders skip straight to building. They open Cursor, start typing, and then two weeks later they're knee-deep in something that doesn't quite match what they had in mind. Scope creep. Rework. Wasted time.
I stopped doing that. Now I use Claude to scope the whole thing before I touch a single file.
Not planning for the sake of planning. Actual scoping. The kind that tells you what you're building, what you're not building, and what order to build it in.
The Problem With Vague Ideas
Vague ideas feel exciting. "I want to build a tool that helps freelancers track their leads." Okay. But what does that actually mean?
Does it mean a CRM? A spreadsheet with automation? A Slack bot that reminds you to follow up? A simple form and a database? All of those could be valid. But if you don't know which one you're building, you'll end up building pieces of all of them.
The job before the job is to kill the vagueness. Turn the fuzzy thing into a concrete thing with edges.
Claude is really good at this, but only if you know how to push it.
Start With a Brain Dump, Not a Brief
I don't try to come into Claude with a clean, organized idea. That's not how ideas work. I do a brain dump.
I open a new conversation and I just talk at it. Everything I know about the problem. Who it's for. What pain it solves. What I've already tried or thought about. What I'm unsure of. What I definitely don't want it to do.
Messy is fine. The goal is to get it all out.
Then I ask Claude to reflect it back to me as a structured problem statement. Not a solution yet. Just: here's the problem, here's who has it, here's what success looks like.
That step alone cuts half the confusion. Seeing your own idea reflected back in clear language tells you fast whether you actually understand what you're trying to build.
Use Claude to Ask You the Questions You're Avoiding
Here's where most people go wrong with AI-assisted scoping. They ask Claude to give them answers. But the better move is to ask Claude to give you questions.
After the brain dump, I ask something like: "What are the 10 questions I need to answer before I can properly scope this project? Focus on questions I might be avoiding or haven't thought about yet."
Claude will surface stuff like:
- Who owns the data and how is it stored?
- Is this a one-user tool or does it need multi-user support?
- What happens when someone's input is wrong or incomplete?
- Does this need to work offline or is it always-connected?
- What's the simplest version that's still actually useful?
These are the questions that blow up projects when you ignore them and discover them mid-build. Better to face them now.
I answer each one. Then I ask Claude to use my answers to draft a scope document.
The Scope Document Format That Works
I ask Claude to produce a scope document with these sections:
- What this is. One paragraph. Plain English.
- What this is not. Explicitly out of scope. This is the most important section.
- Core features for v1. The minimum that makes it real and usable.
- Features deferred to v2+. The stuff that's tempting but not essential.
- Technical assumptions. Stack, storage, auth, integrations, all stated upfront.
- Open questions. Anything still unresolved that needs a decision before building starts.
That last section is important. If there are still open questions after this session, I know where the landmines are. I can resolve them before I write code, not after.
Turning Scope Into a Build Order
Once the scope doc is solid, I ask Claude to sequence the build. "Given this scope, what's the logical order to build these features? Start with what unblocks everything else."
This gives me a rough sprint order. Not a Gantt chart. Not a project plan with deadlines. Just a sequence: build this first because it's the foundation, then this because it depends on that, then this last because it's polish.
That sequence becomes my working list inside Cursor. I'm not deciding what to do next. I already decided. I just execute.
What This Actually Saves You
Time, obviously. But more specifically, it saves you from the worst kind of rework: the kind where you've built something real and then realized the foundation was wrong.
It also saves you from scope creep mid-build. When you're in Cursor at 11pm and you get the idea to add one more feature, you have a document that explicitly says whether that's in or out. The answer is already there. You don't have to relitigate the whole project in your head while you're tired.
One session. One doc. Then you build.
The exact prompts, the session structure, and the one-liner trick for keeping context across Cursor sessions are all inside Inner Circle. That's where the actual workflow lives.
Keep building
- Claude Code: Zero to Feature in One Session from the prompt library
- Claude Code Hook: Auto-lint on Save from the prompt library
- How I Gave My Business a Brain It Can Actually Talk Back
- The full Vaylo prompt library, new drops weekly
