Lesson 3: Building the MVP
Course: Ship Your First AI App
Estimated time: 30 minutes to read, 2 hours to complete the exercise
Difficulty: Beginner Builder
You have a validated idea and a running stack. The dangerous part starts now. This is where most builders overshoot and spend three months building something they could have shipped in three weeks.
The MVP is not a rough version of your full product. It's the smallest thing that delivers the core value. Everything else is a future feature.
The Scoping Problem
Here's a real conversation that happens constantly:
Builder: "I'm building an AI tool for freelance designers. It'll generate client proposals, track project status, send automated updates, handle invoicing, and have a client portal."
The right response: "Which one of those is the thing that makes someone pay for it on day one?"
If you can't answer that immediately, your scope is too large. You have five products glued together and none of them are done.
The MVP scoping process has one job: find the one feature that delivers enough value that someone would pay for it, and ship only that.
Everything else is a v2 decision. Put it in a list. Call it the roadmap. Don't touch it until you have paying users.
The Ruthless Scoping Framework
Take your idea and list every feature you're imagining. Write them all down. Then sort them into three columns:
Core: Without this, the product doesn't work at all. This is the MVP.
Nice to have: This makes the product better but the core value works without it. Ship after launch.
Shouldn't exist: You thought of this but it doesn't actually serve the core use case. Delete it.
For an AI proposal generator for designers, that breakdown might look like:
| Core | Nice to Have | Shouldn't Exist |
|------|-------------|-----------------|
| Input: project brief | Save proposals as templates | CRM integration |
| AI generates proposal | PDF export | Client messaging inbox |
| User can edit the output | Brand customization | Project tracking |
| Copy/download output | Revision history | Invoice generation |
Notice what's in the MVP: input, generation, edit, output. That's it. A user can get real value from that in 5 minutes. Everything else is after they're already paying.
If your Core column has more than 5-6 items, you're still scoping too broadly. Keep cutting.
Writing Specs That AI Can Execute
This is where most builders waste hours with AI coding tools. They open the chat and say "build me a proposal generator" and then complain when the AI builds the wrong thing.
AI editors are not mind readers. They're spec executors. The quality of your output is almost entirely determined by the quality of your input.
The brief-in-file pattern fixes this. Instead of chatting with your AI editor, you write a spec file in your repo. Then you point the AI at it. The AI reads the full context and executes.
Here's what a good spec file looks like:
# Feature: AI Proposal Generator
## What This Does
Takes a project brief from the user and generates a professional client proposal.
## User Flow
1. User lands on /new-proposal
2. User fills out a form: project name, client name, budget range, deliverables, timeline
3. User clicks "Generate"
4. API call to Claude claude-3-5-sonnet-20241022 with the form data
5. Response streams back to the UI
6. User sees the proposal generating in real time
7. User can edit the text inline
8. User can copy the full text to clipboard
## API Route
POST /api/generate-proposal
Request body: { projectName, clientName, budget, deliverables, timeline }
Returns: streamed text response
## Prompt Template
System: You are an expert freelance designer who writes clear, professional client proposals. Write in first person. Be specific about deliverables and timeline. Use a confident, professional tone.
User: Generate a proposal for: [project details]
## UI Components
- ProposalForm component: the input form
- ProposalOutput component: displays the streamed result with edit capability
- Page: /app/new-proposal/page.tsx
## Data (Supabase)
Table: proposals
- id (uuid, primary key)
- user_id (uuid, references auth.users)
- project_name (text)
- client_name (text)
- content (text)
- created_at (timestamp)
Row-level security: users can only see their own proposals.
## Not in This Feature
- Templates
- PDF export
- Sharing
That spec has everything an AI editor needs to build the feature. The UI components, the API route, the prompt, the database schema, the security rule, and explicitly what's out of scope.
When you drop that into Claude Code or Cursor and say "implement this feature", you'll get working code that covers all of it. When you chat without a spec, you'll get half the feature and a lot of back-and-forth.
Prompting for Code vs. Prompting for Chat
There's a mode difference between asking an AI assistant to talk about code and asking it to write code you'll actually run.
Chat mode (what most people default to): "How would I implement streaming in Next.js?" You get an explanation. Maybe a code snippet. You then have to adapt it to your codebase.
Execute mode: You give context about your actual project, your actual file structure, your actual tech choices, and ask it to write the specific file. You get code that fits your project.
The difference in practice:
Bad prompt: "Write a Stripe webhook handler"
Good prompt: "Write a Stripe webhook handler for Next.js App Router. It should handle checkout.session.completed and customer.subscription.deleted events. When checkout.session.completed fires, update the user's subscription_status in Supabase to 'active'. When customer.subscription.deleted fires, set it to 'cancelled'. The Supabase client is already configured at lib/supabase.ts. The webhook secret is in process.env.STRIPE_WEBHOOK_SECRET."
The good prompt gives the AI everything it needs to write code that actually works in your project. It doesn't have to guess at your file paths, your environment variable names, or your database schema.
This is the biggest shift in how you work with AI code editors. More upfront context means much less back-and-forth.
The Build Loop
When you're building the MVP with an AI editor, you're not writing code from scratch. You're running a tight loop:
- Write or refine a spec for the piece you're building
- Give the AI the spec and ask it to implement
- Review what it generated (more on this in the Code Review lesson)
- Run it and test it manually
- Describe what's wrong and ask it to fix it
- Repeat until the feature works
The key discipline here is staying in small chunks. One feature at a time. One component at a time if the feature is complex. Don't ask the AI to build the whole app at once.
The longer your request, the more likely the AI is to produce something that almost works but misses something important. Break it down.
A realistic timeline for building the proposal generator MVP:
- 30 min: Write the spec file
- 45 min: AI generates the API route and UI components, you debug any issues
- 30 min: Hook up Supabase to save proposals
- 30 min: Add Clerk auth so only logged-in users can access it
- 15 min: Manual testing and fixing edge cases
- 30 min: Basic styling so it doesn't look like a wireframe
That's 3 hours to a working, deployed feature. Not 3 weeks.
Common AI Code Generation Problems (and Fixes)
Problem: AI generates code that uses an API that doesn't exist or uses the wrong method names.
This happens when you're using newer APIs that might not be well-represented in training data, or when you're not specific enough about the version. Fix: always specify the exact library version and include a note about which patterns are current. "Use the Vercel AI SDK v3 streamText function, not the older ai.stream() pattern."
Problem: AI generates code that works in isolation but breaks with the rest of your app.
This happens when the AI doesn't have enough context about your project. Fix: include relevant existing files in your prompt. "Here's my current Supabase client configuration [paste it]. Write the new query to match this pattern."
Problem: AI confidently generates something that's subtly wrong and you don't catch it.
This is the sneaky one. The code runs, but it's doing the wrong thing, or it has a security hole, or it'll break at scale. Fix: slow down on the review. Ask the AI to explain what the code does step by step. Ask it "what could go wrong with this approach?" We cover this in depth in Lesson 5 of Course 2.
Exercise: Build a Working Feature in 2 Hours
Take the MVP you scoped in the earlier section of this lesson and build one core feature using the spec-first approach.
Hour 1: Spec and structure
Write a spec file for the feature (use the template above). Be specific about:
- User flow (numbered steps)
- API route (path, request, response)
- Prompt (if AI is involved)
- UI components (names, locations)
- Database (table name, columns)
- What's explicitly out of scope
Then open your AI editor and ask it to scaffold the file structure based on the spec. Directories, file names, empty files. Review the structure before writing any real code.
Hour 2: Implementation and test
Work through the spec section by section. Use your AI editor to implement each piece. Give it context from your spec file and your existing project files for each request.
Test each piece as you go. Don't implement everything and then test. Find problems early while the context is fresh.
By the end of hour 2, you should have a feature that works. It might not be polished. It might have edge cases you haven't handled. That's fine. A working rough feature is infinitely more valuable than a beautifully planned unfinished one.
Key Takeaway
Writing a spec before touching code isn't bureaucracy - it's the thing that turns a day of confused AI back-and-forth into two hours of productive building.
What's Next
You have a working MVP. Now it needs to reach users. Lesson 4 covers launch day - where to go, what to say, and how to write copy that gets people to actually try it.