← Back to resources
Day 1 · Module

Product scoping

Before you write a spec, you need to know what you're building and why. This module walks you through finding a real problem, shaping the solution that fits it, and scoping it down to the simplest version that works — so you walk into the next session with something worth specing.

1 of 7

Know who you're building for

Yourself
Someone specific
A small group you know
People who might pay

Each answer shapes what "good" looks like — how much polish, how many features, how much rigor.

2 of 7

The 10x test

If I got 10x better at this,
would I have 10x the impact?
Yes

This is your work. Don't build it away — get better at it.

No

Good automation candidate. Your time is better spent elsewhere.

Don't automate away the things that bring you joy or make you uniquely good at what you do. Build away the drudgery.

3 of 7

Get clear on the problem

Vague
"Something for meetings"
Specific
"Two days after a meeting, I can't remember what was decided when I need to act on it"

You should be able to name the problem in one sentence. Specific problems generate specific solutions.

4 of 7

Know when the problem shows up

When it's Monday morning and I'm prepping for 1:1s
I want a briefing on what each person worked on last week
So that I can ask about real things instead of "how's it going?"

A loose pattern that forces specificity. The more concrete the moment, the more buildable the solution.

5 of 7

People won't open the app

Too much friction
"Open app → tap + → upload screenshot → tag it"
Zero extra effort
"Take a screenshot, it shows up in the app"

People overestimate their own willingness to open an app — including their own. Think about the entry points: where does the problem happen, and can the app meet it there?

6 of 7

App or agent?

App
You interact with it
  • Read-it-later
  • Tab manager
  • Meal planner
  • Embroidery sampler
Agent
It runs without you
  • Invoice sender
  • Lead scorer
  • Subscription canceller
  • Daily brief

This session focuses on apps — you see and shape the UI as you build.

7 of 7

Do one thing really well first

Kitchen-sink v1
Ship everything at once
  • Hard to use
  • Hard to debug
  • Rarely gets better
Focused v1
Ship one thing, iterate
  • Actually usable
  • Easy to fix
  • Gets sharper each round

You can only iterate on what you can actually test. A bloated v1 is a v1 you can't improve — because when something breaks, you can't tell what broke it.

A few favorite examples

Apps people vibe-coded to scratch a real itch.

A read-it-later app
by Kevin Roose

Articles, audio readouts, spaced-repetition emails, Kindle sync.
A tab manager
by @zarazhangrui

Groups tabs by domain, batch-closes duplicates, plays confetti when you close one.
A fit checker for vintage shopping
by @yrechtman

Compares listed measurements against your saved wardrobe.
A multiplayer embroidery sampler
by @0xCharlota

Everyone adds their patch to a shared infinite canvas.
A last-minute ski trip finder
by @jphorism

Combines snow forecasts with flight prices to surface cheap powder days.
A meal planner that fills your cart
by Geoffrey Litt

Plans a week of meals from your recipe library, then fills your Instacart for you.
A daily goal tracker
by @j_smith (iOS)

Native iOS app with custom sound design for little satisfying moments.
A fundraise deck system
by @rsarver

Each slide is a standalone HTML file. Reorder the deck by editing a simple list of slide names.
A Google growth simulator
by Hilary

A learning tool to explore Google's growth levers. Reallocate investment across different parts of the business and see if you can beat the historical trajectory.
Deck Chef
by Hilary

Feedback on your presentation decks — references what good looks like, examples of good and bad, and an upload for critique on your own deck.

 See the upload log →
A live context window visualizer
by @zarazhangrui

An HTML dashboard of Claude Code's current context window — a vivid way to see how context accumulates and what's eating tokens.
Why vibe code?

You get something that fits exactly one person — you.

Most apps are built to serve many users, so they average across everyone's needs and fit no one perfectly. When you build for yourself, you only have to fit one person.

Clothes made for you, not off the rack.
You'll need Claude Pro or Max open in another tab. As you work through each step, copy the prompt and paste it into a Claude conversation. Fill in the fields along the way — they'll populate downstream prompts automatically.
Section 1

Find a problem worth solving

You can't build something useful without a clear problem. The move is: generate many candidates, interrogate the best ones, pick one that's real. Don't build the first thing you think of.

Start here · no AI yet

Your own brainstorm

Take 3 minutes. Write down any ideas that come to mind — problems, tools, apps you wish existed. Don't filter. Getting your own list out first keeps AI from anchoring your thinking when you ask it to generate ideas in the next step.

1
Brainstorm candidate problems
Before I commit to building anything, I want a big list to choose from. AI can help me mine my own life for problems I've stopped noticing.
Paste into Claude and hit Enter
Help me generate 15 problems that a small custom app could solve in my work or life — something I could build in a weekend. Before you list them, ask me 3-4 questions to understand what I do, what takes up my time, and what I repeat. Then generate a wide range — some tactical, some bigger. Include problems I might have stopped noticing because I've lived with them.
Answer Claude's questions honestly — even better, dictate. Don't filter the output yet. A messy long list is what you want. Pick your top 3-5 to bring to the next step.
2
Rank by what matters to you
Lots of problems are interesting. The right question isn't "which is interesting" — it's "which matters most given what I care about today."
What matters to you today?
Pick up to 3. The prompt below updates as you select.
Paste into the same Claude chat as Step 1
Pick the one that's most worth going after. Type it into the field below — every downstream prompt will use it.
Keep it to 1-2 sentences. Include who has the problem and what it costs them.
Saved ✓
Section 2

Figure out what you're building

Now you have a problem. Before you jump to a solution, check: does this need an app (a UI you interact with) or an agent (something that runs in the background)? This session we're focused on apps. Then explore a few concepts — your first instinct isn't always the best shape.

3
App or agent?
Some problems want a UI. Others want automation. I need to know which shape I'm building before I start.
Paste into Claude and hit Enter
If Claude thinks it's an agent problem, you have two choices: pick a different problem from step 1, or push back — is there a UI version of this that gives you more control? (A Monday briefing you accept is a different experience than one that arrives automatically.)
4
Imagine the ideal solution
If a senior designer handed me a beautiful v1 of this app tomorrow, what would it actually do?
Paste into Claude and hit Enter
Read it as if you're reviewing a designer's pitch. What lands? What feels off? Use those reactions to sharpen your own thinking.
5
Compare a few approaches
My first instinct isn't always the best shape. What other angles am I missing?
Paste into Claude and hit Enter
Pick one. It doesn't have to be Claude's favorite — but choose deliberately, not by default. Type your chosen concept into the field below.
In 1-2 sentences. What does the user do, and what does the app do for them?
Saved ✓
Section 3

Scope to the essentials

The gap between an idea and something you'll ship is ruthless scope. The simplest version that solves the problem is almost always smaller than you think. Be brutal here.

6
Scope down to the simplest version
The difference between "idea" and "built this weekend" is ruthless scope. What's the absolute core?
Paste into Claude and hit Enter
Write down the three things v1 must do — and the three things you're deliberately not doing. Those cuts are what make shipping possible.