You have a bucket and a rough idea. Good. Now we make the idea smaller.

This lesson feels like the boring one. It is not. Almost every vibe coding project that fails, fails here — not because the idea was bad, but because the person building it never asked how much they could actually carry. They started a project that needed six weekends when they had one, and they abandoned it on weekend two.

Constraints are what make something finishable. And finishable beats ambitious every single time, because finishable turns into a thing that exists, and ambitious turns into a folder you never open again.

The five questions that save you

There are five questions to answer before you write a single prompt. Claude Code will interview you through them in a minute. Before that, read them so you know what you are answering.

1. How much time do you have? Not “how much time you wish you had.” How much time, realistically, in the next two weeks. If the answer is “two hours a week” that is fine. If the answer is “every evening” that is also fine. The answer shapes the idea, not the other way around. A product built in two hours a week is much smaller than a product built every evening.

2. Is anyone else going to use this? If yes, how many, and do you know them? A tool for yourself has different rules from a showcase for strangers has different rules from a product for ten friends. You already picked a bucket — this question confirms it with a number.

3. Does it need to keep working after you finish it? Some things are event-shaped: a landing page for a birthday, a showcase for a specific exhibition, a tool for a one-off project. They exist and then they stop mattering. Other things are ongoing: a tool you will use every week, a product other people will rely on, a portfolio you will update for years. The ongoing ones need thought about maintenance, updates, and the day one of the external tools it relies on changes or goes away. The event-shaped ones are allowed to be scrappy — they do not need to survive the month.

4. Is it allowed to cost money? Hosting on Vercel is free for personal projects. A domain is a few dollars a year (we cover this in the Ship phase). Claude Code runs on a Claude Pro subscription — check claude.ai for the current price. That is the baseline. If the project needs more — an email service, a database you have to pay for, an API — it adds to the monthly number. Decide your ceiling before you start. “Zero above what I am already paying” is a valid ceiling and should shape what you build.

5. What do you already have? Words you have written. Photos you have taken. A logo. A colour palette. A voice. A brand. A list of users waiting. A group chat of friends who want something. Anything you do not have to invent from scratch. Most first projects fail because the builder tries to make everything at once — including the content, the design, the brand, and the audience. Whatever you already have is what goes in the project first.

The interview

Open Claude Code in the same folder you used for the Three Buckets lesson (or a new empty one — either is fine). Say or type:

I am defining a project to build with you. I have picked a bucket (tool / showcase / product) and my rough idea is: [one sentence]. Before I write a brief, interview me about my constraints. Ask me these five questions, one at a time, in this order. Do not skip ahead. Do not editorialise until all five are answered. 1) How many hours a week do I realistically have for this over the next two weeks? 2) How many people other than me will use this, and do I know them? 3) Does this need to keep working after I finish it, or is it an event-shaped project that stops mattering after a moment? 4) What is the maximum I am willing to spend on this per month beyond what I already pay for Claude Pro? 5) What do I already have that I can use — writing, images, brand, voice, audience, a group chat — anything? When you have all five answers, tell me two things. First, whether my rough idea is realistic inside those constraints. Second, what I should cut before we even begin, because it will not fit.

Answer honestly. Not aspirationally. The answers to these questions are the ones that stop you abandoning the project two weekends in.

The reality filter

When Claude reads back your answers and tells you what is realistic, one of three things will happen.

Best case — the idea fits. Your constraints support the project as described. Claude says “this works, you should be able to do this in the time you have with the resources you have.” You carry the idea forward unchanged.

More common case — the idea is bigger than your constraints. Claude says “this is three weekends of work and you have one. Here is what to cut so it fits.” Listen. Cut. This is the moment where the real project appears — the smaller, sharper version. Not less ambitious; just smarter about what you can finish.

Rare but possible case — your constraints allow more than the idea needs. You have more time, more resources, more audience than this particular idea uses. Claude will tell you. Do not use that as a reason to add features. Use it as a reason to do the existing thing better — nicer typography, real content, more polish.

When Claude suggests cuts, the impulse is to defend every feature. Resist it. Say yes to the cuts. Every feature you cut now is a weekend you get back for the polish phase. You can add cut features later if the project is working and you have the time; you cannot add time back if you started with too much to do.

A short detour on “scope creep”

There is a pattern every builder hits: the project slowly grows features and complexity as you work on it, until it is unfinishable. Vibe coding makes this worse, not better. It is too easy to say “while we are here, add a login screen” or “what if users could export to CSV” — the AI happily builds it, the project grows, and suddenly your one-weekend idea is a six-month commitment.

The cure is to write down the scope before you start and refuse to expand it during the build. Your constraints are the scope. The idea your constraints allow — not the bigger idea you wish you could build — is the project.

Later in the Shape phase you will create a project memory file that Claude reads at the start of every session. When you get there, put this rule in it: if a new feature would take more than one sitting to build, it is out of scope for v1. No exceptions. Note it somewhere and come back after v1 is shipped. Claude will respect that rule for the whole project.

When you are done

You should now have:

  1. Honest numbers for time, audience, lifespan, budget, existing material.
  2. A version of your idea that fits those numbers — possibly smaller than the one you arrived with.
  3. A list of things you are explicitly cutting, so you can come back to them after v1 ships.

That is enough to write the actual brief, which is the next lesson. The brief is one paragraph. It will be the only paragraph that matters for the rest of the build, because it is the one you will hand to Claude Code as the project’s source of truth.

Mission checkpoint

Second chapter of Mission 1: Your Brief. You now know what you are building and what is off the table. The brief is the last piece.