Most people who try to vibe code do not get stuck on the vibe coding. They get stuck before they start. Their first problem is not “how do I build this?” — it is “what should I build?”

This is not a lack of imagination. It is the opposite. People who are drawn to vibe coding usually have dozens of half-formed ideas: a newsletter, a tool for their friends, a weird art piece, a small business idea, a portfolio, a game they wish existed. The ideas are not the problem. Choosing is the problem.

This lesson is a filter. By the end of it you will have picked the thing you actually want to build first. Not the best idea. Not the most ambitious one. The right one for now.

Three buckets

Every buildable idea fits into one of three shapes. Before you pick what to make, pick which kind of thing you want to make.

Bucket 1 — A tool that helps you. Private or semi-private software that makes your own life easier. A workout tracker for the exact way you train. A book-to-read list that does what your notes app cannot. A weekly check-in page for your own mental health. A calculator for something specific to your work. The audience is one person: you.

Bucket 2 — Something you want to show off. Public creative work. A portfolio. A single-page project that is the whole point. A digital zine. An interactive art piece. A writing site with a personality. A landing page for an idea that is half manifesto. The audience is strangers and the goal is that they remember it.

Bucket 3 — A thing that should exist. A small product. An app other people could use. A tool you would tell a friend to try. A newsletter-plus-website. A book club tracker for your local group. A booking page for your hairdresser sister. A workshop signup form. The audience is a few people solving a real problem, and you are the one who notices the problem is real.

That is it. Tool, showcase, product. A tool that helps you, a thing that makes you look good, a thing that makes the world a little better. Every project you could build is one of those three.

Why the bucket matters more than the idea

The bucket changes everything about how you build.

A tool has one user with perfect context — you know exactly what you want, you do not need to explain anything, and bad design is tolerable because you will understand it anyway. Tools are fast to build and do not have to be pretty. They never need a landing page.

A showcase lives or dies on how it looks. The code can be tiny. The logic can be simple. What matters is whether a stranger feels something when the page loads. You spend most of your time on typography, layout, imagery, tone. The engineering is the easy part; the taste is the hard part.

A product has actual users who are not you. That means it needs things tools and showcases do not: onboarding, error messages that make sense to strangers, a way for people to recover when something breaks, some kind of data that persists. Products are the most interesting to build and by far the most work. First products should be small.

If you pick a bucket and then build like you are in a different bucket, the result feels off. A tool built like a product has too many features and too many settings. A showcase built like a tool is ugly. A product built like a showcase collapses the first time a stranger uses it. Pick the bucket, commit to its rules, and the rest of the path gets easier.

The interview

Open Claude Code. If you do not have it yet, get it from Claude Code — it is the app we will use through the whole path.

Start a session in an empty folder (Claude needs a home to think in — any empty directory will do). Hit the microphone icon if you are on desktop and just talk, or type this exactly:

I am about to pick a project to build with you. Before I pick the project, I want to pick the bucket. Interview me. Ask me one question at a time, and do not tell me your theory until I have answered all of them. Questions: What is something that would make your own daily life a little better if it existed? What is a thing you would want to show a stranger and have them remember? What is a small problem you have seen that nobody is fixing? Ask them in order. Wait for my answer before moving on. When all three are answered, tell me which bucket each idea falls into, and ask me which of the three I am most drawn to today.

Answer the questions honestly. Do not edit yourself. The weird answers — the ones that feel too personal or too trivial — are usually the ones worth building.

When Claude asks which bucket you are most drawn to, pick one. Not the bucket you think is most impressive. The one you actually want. If you hesitate between two, pick the scarier of the two. Fear is a good compass here — the scary one is usually the real answer.

The rule of yes to scary

When you are choosing between ideas you feel neutral about and ideas that make you slightly nervous, always pick the nervous ones. The tool that feels too personal. The showcase that is too earnest. The product that is too small. Those are the ones that will teach you something and that you will actually finish. The safe, neutral ideas bore you halfway through and you abandon them — not because they were bad, but because there was nothing at stake.

Vibe coding removes the technical barrier. Claude writes the code. Claude handles the framework. Claude deploys the thing. What is left is you and the idea. The bigger the “yes” in your chest when you say the idea out loud, the more likely you are to finish it.

When the three buckets do not fit

They always fit, but sometimes it feels like they do not. Edge cases:

  • “I want to build a game.” A game is almost always a showcase, unless it is a tool you are making for yourself to play alone. If you want people to play it and remember it, showcase.
  • “I want to build an app other people subscribe to.” That is a product — bucket 3. First versions are tiny and for a handful of people. Do not start aimed at millions. Start with a product for five friends.
  • “I want to build AI tools.” AI tools are usually tools (bucket 1) unless you package them for strangers (then product, bucket 3). The underlying AI changes nothing about the bucket.
  • “I want to build my personal website.” Showcase.
  • “I want to build a thing that automates my invoices.” Tool.
  • “I want to build a marketplace where people buy and sell.” Product, and too big for a first project. Pick a tool or a showcase first, build it, come back.

Write it down before you close the session

Before you stop, ask Claude to save what you just decided:

Save my pick in a file called idea.md in this folder. One line: which bucket I chose. Then one sentence: the rough version of what I want to build. That is all. Do not write anything else in the file.

That file is the thing you carry into the next lesson. It is one line long and it is the only thing you need from this session.

When you are done

You should now have:

  1. A bucket you committed to. One word: tool, showcase, or product.
  2. A one-sentence rough version of the idea, saved in idea.md.
  3. A slight pit in your stomach about it, because it is slightly too personal or too earnest or too small. That is the signal.

You do not yet have a brief. You do not yet have a plan. You have the thing you are making. That is enough for the next lesson, which is about the constraints you are working under — and why constraints are the real unlock, not the idea itself.

Mission checkpoint

This is the first chapter of Mission 1: Your Brief. Do not rush the bucket decision. It is the one choice you cannot take back cheaply once you start building.