Scoping the MVP with Claude Code

What This Track Builds

Over the next several lessons you will build a real, working product: a Local Business Reputation Dashboard that consolidates Google, Yelp, and Facebook reviews into one place a business owner can filter, sort, and respond from. It has real auth, a real Postgres schema, real Stripe billing, real transactional email, and a real test suite. Every code sample in this track is pulled from an actual working reference build -- not invented for the lesson.

The stack: Next.js (App Router) with React and TypeScript, Supabase for auth and Postgres hosting, Drizzle ORM for the schema and queries, Tailwind CSS for styling, Stripe for subscription billing, and Resend for email. None of this requires prior experience with these specific tools -- Claude Code can scaffold and explain each one as you go. What it does require is knowing how to direct an agent on a multi-week build instead of asking it for everything at once.

Why Scoping Comes Before Code

The single most common failure mode when building with an AI coding agent is skipping straight to "build me a reputation dashboard." That prompt is too underspecified to produce something you actually want -- the agent will guess at scope, and every guess it makes is a decision you didn't make. The fix is not to write a 10-page spec yourself. It is to have a focused conversation with Claude Code that turns a vague idea into a written, scoped plan you both agree on before any code exists.

I want to build a reputation dashboard for local businesses that pulls in Google, Yelp, and Facebook reviews. Before we write any code, help me scope an MVP. Ask me clarifying questions one at a time about: who the user is, what the absolute minimum feature set is, what data model this implies, and what I am explicitly NOT building yet.

Asking the agent to question you one at a time matters. A wall of ten questions at once gets shallow, rushed answers. One question, your answer, the next question -- the same pattern good product managers use -- produces a spec you actually thought through.

The Real Scope Decisions Behind This Build

For the reference build in this track, here is what scoping actually decided, and why each cut matters:

• Single business per account. One owner, one business. No multi-location, no team members, no agency-managing-many-clients. This is the single biggest scope cut in the whole project, and it shapes the schema, the auth model, and every query for the rest of the track.
• Reviews are seeded, not live-polled. Pulling real reviews from the Google Places API, Yelp Fusion API, and Facebook Graph API each require business verification or app review processes that do not fit inside a self-paced tutorial. The MVP builds a real ingestion endpoint with real validation and dedupe logic, but feeds it from a seed script instead of live pollers. That endpoint is still the genuine integration point a real poller would call later.
• Two tiers, one paid plan. Free and Pro, billed through Stripe Checkout. No usage-based billing, no annual discount tier, no enterprise plan.
• Respond means draft-and-track, not publish-back. The MVP lets an owner write and save a response and marks the review as responded. It does not push that response back to Google/Yelp/Facebook's own APIs -- those write-back APIs have their own approval gates. The schema models a published_at field so the UI and data flow are realistic, ready for that integration later.

Notice the shape of these cuts: each one is a real product capability deliberately deferred, with a clear note on what would extend it later. That is what a good MVP scope looks like -- not a smaller, vaguer version of the idea, but a precise subset of it.

Turning the Conversation Into a Spec

Once you and Claude Code have talked through the questions above, ask it to write the answers down:

Summarize everything we just decided into a short MVP-SPEC.md: target user, core user flows, the data entities involved, what is explicitly out of scope, and the tech stack we are using.

This file becomes the thing you point back to for the rest of the build -- including in lesson 2, where it becomes one of the seed documents for your project's persistent memory. A spec that lives only in chat history is gone the moment that conversation ends; a spec that lives in a file in your repo is something both you and the agent can re-read in every future session.

What Good Scoping Looks Like in Practice

You will know the scoping conversation worked when you can answer these without hesitation: who signs in, what is the one screen they spend the most time on, what data does that screen need, and what did you say no to. If any of those answers is fuzzy, the conversation was too short. Going back and forth for ten minutes before touching a keyboard is not slower than diving in -- it is the difference between Claude Code building the thing you meant and Claude Code building the thing it guessed you meant.

Lesson 2 takes this spec and turns it into the persistent project memory -- CLAUDE.md -- that keeps every future session, yours and the agent's, working from the same understanding of the project.