Building with AI

Do this before Session 2, on 9/2.

Set aside an hour. Most of it is waiting for things to install.

1. Get a Claude account with Claude Code access. The Pro plan is about $20 a month and is required course material, the same way a textbook would be. Sign up at claude.ai.

2. Install VS Code. It is free, at code.visualstudio.com. VS Code is just a window that shows your files. Think of it as Finder or File Explorer with better lighting. You will type notes into it, never code. Claude writes the code. You write things like your build log and your project's instructions file.

3. Install Claude Code. There are two ways to run it, and you only need one. They are the same tool underneath, so everything in this handbook works either way.

	The terminal	The desktop app
What you see	A text window where you type	A normal application window with panels
What this handbook assumes	This one	Works fine, with notes where it differs
Easier to get help with	Yes, because most guides online are written for it	Fewer guides so far
Easier to look at	No	Yes

Pick the terminal if you have no strong feeling either way, because it is what this handbook's instructions are written against and what the person next to you is most likely using. Pick the app if the terminal genuinely puts you off, because a tool you avoid is worse than one you find slightly ugly. You can change your mind later, and switching costs you nothing except an evening.

3a. If you chose the terminal. Open it. On a Mac, press Cmd and Space, type "Terminal," and hit enter. On Windows, search for "PowerShell." Then paste the one line for your computer.

TERMINAL, Mac or Linux:

curl -fsSL https://claude.ai/install.sh | bash

TERMINAL, Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Copy only what is inside the box. You'll know it worked when the terminal stops scrolling and gives you back a normal blank prompt with no red text.

3b. If you chose the desktop app. Download Claude for your computer from claude.ai, install it the way you would install any other application, and sign in with the same account from step 1. Then click the Code tab at the top.

Claude Code is already inside the app, so there is nothing else to install and you can skip the terminal line above.

One thing to be careful about, and it is the only real trap in the app. There are three tabs: Chat, Cowork, and Code. Only the Code tab can see the files in your project, and only the Code tab reads your project's instructions file from Part 4. Work in the Chat tab by accident and nothing looks broken, you just quietly get worse answers for reasons you cannot see. If you are unsure which tab you are in, look at the top of the window before you start typing.

4. Make a course folder and start Claude Code.

If you are using the desktop app, read this step anyway. The folder still has to exist and you still have to point Claude at it. The app's version of this step comes after.

TERMINAL

mkdir entp6314
cd entp6314
claude

A browser window will open to log you in. When it finishes, you have an AI software engineer running in your terminal.

Where did that folder go? Your terminal is always standing in one folder, the way a Finder window is always showing one folder. mkdir entp6314 made a new folder inside wherever you were standing, and cd entp6314 walked into it. If you ever lose track, type pwd and it tells you exactly where you are standing:

TERMINAL, with what it answers back:

pwd
/Users/yourname/entp6314

That is the same folder you would see in Finder under your name. Open Finder and look at it once now, so the terminal and the window on your screen connect to the same place in your head.

What you will see when Claude Code wants to do something. Claude Code asks permission before it edits a file or runs a command. You will see a prompt with the action and a yes or no choice. This is normal and it is not a warning that something is wrong.

• Editing files inside your own project folder, running the app, installing what it needs: approve these freely.
• Deleting things, or anything touching a folder outside your project: read it before you approve.

Saying no does not break anything. It just tells Claude to try something else.

In the desktop app the same thing happens through a setting rather than a question. Next to the send button there is a selector with a few choices, and the two worth knowing now are Manual, where Claude asks before it changes anything, and Plan, where it writes out what it intends to do and waits. Start on Manual. Part 4 covers Plan mode, which you start using at Session 3.

5. Create your accounts.

Account	What it is for	Needed by	Cost
claude.ai	Claude Code itself	Session 2, 9/2	About $20 a month, Pro plan
github.com	The off-site copy of your project, and the link you hand in	Session 3, 9/9	Free
vercel.com	Puts your app on the internet at a real URL	Session 3, 9/9	Free tier
formspree.io	Collects email signups on your landing pages	Session 4, 9/16	Free tier
supabase.com	Your database, once you need one	Session 8, 10/21	Free tier

Sign up for all of them now, even the later ones. It is ten minutes and it is done. (At Session 8 your team may also want a Google AI Studio, Stripe or Resend account, depending on which component you choose to add. You do not need those yet, and Part 11 walks you through each one when you get there.)

GitHub is worth one extra sentence, because you will hear the name all semester: it is a website that keeps a copy of your project, and it is where the "repo link" that assignments ask for comes from. You will barely visit the site. Claude Code talks to it for you. Part 5 explains what is actually happening.

Every time you sit down to work

Your terminal does not remember where you were last time. It always starts at the top, in your home folder. So every session begins the same way: walk into the folder of the project you are working on, then start Claude Code.

TERMINAL

cd entp6314
cd first-app
claude

Replace first-app with whichever project you are working on that week. Part 4 shows the full layout, so you can see what lives where.

You'll know it worked when Claude Code starts and tells you the folder it is working in, and that folder is your project. If it does not, you are standing one level too high. Type ls to see what is around you, cd foldername to go in, and cd .. to go back up.

In the desktop app, opening a project is the same idea with buttons instead of typing. Click the Code tab, choose Local, then click Select folder and pick the project you are working on. Selecting the folder is the app's version of cd, and it is worth being just as careful about it. The app remembers your recent projects in the sidebar, so after the first time it is one click.

This is the single most common way students lose an evening, on both paths. Claude with no project loaded, or with the wrong one loaded, will answer your questions and build things in the wrong place, and it will do it confidently.

If the install fails

Do not fight it alone for an hour. The official documentation is at code.claude.com/docs. Or open regular Claude at claude.ai and ask:

PROMPT

Copy
I am installing Claude Code on [Mac / Windows] and got this error:

[paste the entire error]

Explain the fix step by step. I am a beginner and I have never used a
terminal before.

Then bring it to class or the class channel. Debugging together earns participation credit.

The eight commands you type by hand

Everything more complicated than these, Claude Code runs for you. You will use these all semester.

Command	What it does
cd foldername	Go into a folder
cd ..	Go back up one level
ls	List the files here. On Windows, dir
pwd	Tell me where I am
mkdir name	Make a new folder
clear	Clean up the screen
up arrow	Repeat your last command
claude	Start Claude Code

A terminal looks intimidating because it is mostly black and has no buttons. It is a text conversation with your computer. You already know how to have a text conversation.

Two windows, one screen

The same black window does two different jobs, and telling them apart matters.

You are in	How you can tell	What you type
The terminal	A short prompt ending in $ or >	The eight commands above
Claude Code	It started after you typed claude, and it answers in sentences	Plain English, and slash commands

Slash commands are instructions to Claude Code itself rather than requests to build something. There are only three you need:

Command	What it does	Works in
/init	Creates your project's CLAUDE.md instructions file. Part 4	Both
/compact	Clears out the clutter when a long session starts going in circles. Part 4	Both
/context	Shows you what Claude loaded at the start of the session, including your CLAUDE.md. Part 4	Terminal

To leave Claude Code and go back to the plain terminal, type /exit.

If you are using the desktop app, you type slash commands into the same prompt box, or you can click the + button and choose Slash commands to see the list. A few commands that open a panel in the terminal behave differently in the app, and /context is one of them, so Part 4 gives you a check that works either way.

A note for app users on this whole section. You still meet the terminal eventually, because Part 5 uses it and the app has a terminal panel built in. None of the eight commands stop being useful. You just need them less often.

---

Session 2, on 9/2. Read this twice. Everything else in the handbook depends on it.

Rule 1: Small steps beat big asks

If you ask for your whole app at once, what usually comes back is a tangle that you have no way to debug. If you ask for a signup form on the homepage, you get something small enough to look at and check. So try to ask for one feature at a time.

This is not really about what AI can handle, because it can often handle quite a lot. The difficulty shows up later, when something is wrong and neither you nor the AI can tell which part of a large request caused it. Working in small steps keeps your failures small enough to find.

Rule 2: Always be able to go back

Try to commit after every feature that works. A commit is a save point, a snapshot of your whole project that you can come back to later, and Claude Code will make one for you whenever you ask.

PROMPT, after every working feature:

Copy
Commit this with a sensible message.

PROMPT, when something breaks:

Copy
The app was working thirty minutes ago and now it is broken. Show me the
recent commits and revert to the last working one.

That is all you need for now. Part 5 explains what is happening underneath and how to get a copy off your laptop, and it is your reading for Session 3.

Once you know you can undo anything, you will probably find yourself willing to try bolder things, since the worst case is that you lose twenty minutes. That confidence matters more than it sounds, especially if you have never written software before.

Rule 3: Never trust, always run

After every change, open the app and click on the thing you just changed. When Claude tells you that something works, treat that as a claim rather than as evidence.

If you do not know how to open your app yet, that is the first thing to fix:

PROMPT

Copy
How do I see this in my browser?

If you take one habit away from this course, it should probably be this one. AI models will tell you that a feature is complete, that the tests pass, and that a bug is fixed. Sometimes they are right. When they are wrong, they tend to be wrong confidently and in convincing detail, so the only reliable way to know is to look for yourself.

You will be graded on this too, since one of your build log entries has to describe a time when AI was confidently wrong and you caught it.

Rule 4: Never paste secrets

Please keep passwords and API keys out of your chat messages, and keep anything sensitive out of code that will end up on GitHub.

If a service gives you something it calls a "secret key," tell Claude Code:

PROMPT

Copy
Store this in an environment variable, not in the code. Then show me how
to confirm it is not going to end up on GitHub.

An environment variable is simply a place to keep a secret outside your code. In practice two files do the work here, and it is worth opening both yourself rather than taking "done" for an answer.

File	What is in it	Who sees it
.env.local	Your actual key	Only your laptop
.gitignore	A list of files to leave out of the project's history	Everyone, which is fine, it holds no secrets

You'll know it worked when .gitignore contains a line reading .env.local, and your key appears nowhere else when you search the project for it. Ask Claude Code to show you both files and to search the project for the key, then read the answer yourself. Of everything in this handbook, this is the mistake most likely to cause you trouble outside the course.

Rule 5: When stuck for twenty minutes, change strategy, not volume

When something will not work, try to resist sending the same prompt again with more emphasis. Adding "please" or "this is very important" does not help. If two attempts have already failed, the problem is usually your approach rather than your wording.

Part 17 has the full troubleshooting playbook. The short version is to stop patching and ask for a fresh diagnosis instead.

---

Session 2, on 9/2.

Every session with Claude Code follows the same rhythm. Learn it once and you can build anything in this course.

Describe, Plan, Approve, Build, Run, Inspect, Iterate.

Describe

Say what you want in terms of what a person experiences.

Good: "A page where a visitor types their monthly expenses and sees a pie chart."

Bad: "Implement a React component with a state hook that renders a Chart.js canvas."

You are not the engineer. You are the person who knows what it should do. Describe the outcome and let the engineer choose the tools.

Plan

In the terminal, press Shift and Tab together to switch Claude Code into Plan mode. In the desktop app, use the mode selector next to the send button and choose Plan. You'll know it worked when a plan mode indicator appears on screen. In the terminal it is a toggle, so pressing it again turns it back off. If nothing seems to happen, do not press it repeatedly. Just say it instead:

PROMPT

Copy
Before writing any code, give me a plan and wait for my approval.

Then read the plan the way a manager reads a proposal from a new hire. Does it match what you asked for? Is it doing something extra you did not want? Is it about to install four things you have never heard of?

Catching a mistake in the plan costs you thirty seconds. Catching it in the code costs you an hour.

Approve

Say yes, or say what to change. Then let it build.

Run

Ask:

PROMPT

Copy
How do I see this in my browser?

What happens next depends on what Claude built, and both answers are correct:

If Claude built	You will	And you will see
Plain HTML in one folder, like your first app	Double-click index.html, or ask Claude to open it	Your page in a browser tab
A Next.js app, which is what your real product uses	Run the command it gives you, usually npm run dev	A link like localhost:3000 to click

localhost means the app is running on your own machine only. Nobody else can reach that link. Putting it somewhere strangers can reach is Part 5.

Inspect

Click everything. Type nonsense into the fields. Press the back button. Try to break it.

Iterate

Report what you saw, specifically. "It's broken" gives the AI nothing to work with.

Good: "The chart appears, but the numbers do not update when I edit an expense. The old value stays until I refresh the page."

You can paste screenshots directly into Claude Code. A screenshot of a broken screen is worth a paragraph of description.

Your first app

Use this in the Session 2 lab:

PROMPT

Copy
I have never built software before. I want a simple one-page web app:
[a tip calculator / my personal homepage / a packing list maker].

Use the simplest possible technology: plain HTML, CSS, and JavaScript in
one folder. No frameworks.

Give me a plan first. After building, tell me exactly how to open it in
my browser.

Then improve it three times using the loop. That is it. You are a builder now. The rest of the semester is the same loop applied to harder problems.

---

Session 3, on 9/9.

Claude Code starts every session with no memory of the last one. Two files fix this.

Before either of them, start the way you always start, standing inside the project you are working on:

TERMINAL

cd entp6314/first-app
claude

In the desktop app, the same move is the Code tab, then Local, then Select folder, pointed at first-app. Check the tab before you start typing. Only the Code tab can see your files, and only the Code tab reads the instructions file this Part is about.

Where everything lives

From here on, the handbook keeps telling you to put things "in your project folder." This is what it means. entp6314 is the course folder you made in Part 1, and each project gets its own folder inside it:

FILE LAYOUT: your course folder by the end of the semester

entp6314/
  first-app/               <- Sessions 2 and 3, your practice project
    CLAUDE.md              <- project memory (Part 4)
  probe-idea-1/            <- Sessions 4 and 5, throwaway
  probe-idea-2/            <- throwaway
  my-product/              <- your real product, from Session 6 on
    CLAUDE.md              <- project memory (Part 4)
    .claude/               <- skills and hooks, added later (Part 11)
    prd.md                 <- your one-page PRD (Part 4)
    build-log.md           <- graded, weekly (Part 6)
    qa-report.md           <- required for the MVP demo (Part 13)
    .env.local             <- your secret keys, never leaves your laptop (Rule 4)
    research/              <- reports the research agents write (Part 7)
    interviews/            <- one file per interview (Part 9)

Three things to notice. Each project folder has its own CLAUDE.md, which is why you have to start Claude Code from inside the right one, or point the app at the right one. Your graded work lives in the real product folder, not in a probe folder, because the probes get thrown away. And you make none of these by hand. Ask Claude Code for them and it creates them where they belong.

CLAUDE.md

This is a file Claude Code reads automatically at the start of every session. It is your project's standing instructions.

Create it by typing /init inside Claude Code. That is a slash command, an instruction to Claude Code itself rather than a request to build something. It reads your project and writes a first draft, which is usually longer than you want.

Then open the file and cut it down to look like this. In the terminal, open it in VS Code. In the desktop app, click the file path where it appears in the chat and it opens in a panel you can type into. Editing this file is notes, not code, so it is yours to write:

FILE: CLAUDE.md

# Project: [name]

## What this is
[Two sentences: who it is for, what problem it solves]

## Stack
[Claude fills this in, for example: Next.js + Supabase + Vercel]

## Rules
- Explain changes in plain English. I am not a programmer.
- Prefer the simplest solution that works.
- Ask before adding any new service or library.
- After each feature, remind me to commit.

## Current focus
[Update this weekly: the one feature we are working on]

Update the "Current focus" line every week. It is thirty seconds of work and it stops Claude from wandering off into parts of the project you are not touching.

Check that it actually loaded

A project memory file you assume is working is exactly the problem Rule 3 exists for. So check, once, the first time you write it.

You'll know it worked when you quit Claude Code, start it again on the same project, and ask it this:

PROMPT

Copy
What does my CLAUDE.md say about how I want changes explained?

If it answers with something from your file, it read your file. If it guesses, gives you a general answer about being clear, or asks you what you mean, it did not.

If you are in the terminal, you have a second and sharper check. Type /context and look at the list under Memory files. Your CLAUDE.md should be on it. This one does not work the same way in the desktop app, so app users should stick with the question above.

When the check fails, the reason is almost always that Claude is looking at the wrong folder. In the terminal, pwd tells you where you are standing. In the app, look at which project the Code tab has open.

What belongs in CLAUDE.md, and what does not

The most common mistake with this file is putting too much in it.

Everything in CLAUDE.md is read at the start of every session, whether it is relevant to today's work or not. It is also read by every one of your teammates, every time any of them opens Claude Code. A long file crowds out the actual conversation and makes Claude worse, not better. Keep it to one screen. If you cannot see the whole thing without scrolling, cut something.

What belongs: what the project is, what it is built with, how you want to be talked to, and any convention your team has agreed on. Standing facts. Things that are true on every day of the semester.

What does not belong:

You are tempted to write	Put it here instead
A list of steps you repeat, like "how we get ready for a demo"	A skill. See Part 11.
"Never commit the API key"	A hook. See Part 11.
Preferences only you have, on a team project	A file called CLAUDE.local.md, in the same folder. Claude reads it, your teammates never see it, and it does not get committed

That middle row is worth pausing on. Writing "never do X" in CLAUDE.md is a request, and requests get forgotten in long sessions. When something genuinely must not happen, an instruction is the wrong tool. Part 11 shows you the right one.

Your CLAUDE.md is shared. It gets committed along with your code, so when you edit it you are changing how Claude behaves for everyone on your team. That is the point, and it is also why you agree on a change before making it rather than after. Part 5 covers how to hand that change to your teammates.

If you want the full version of this, Anthropic has written it up: Steering Claude Code. It is optional reading and it is written for programmers, but the first section on CLAUDE.md is readable by anyone.

When Claude starts going in circles

Long sessions get worse, not better. Claude Code has a limited amount of short-term memory, and a session full of dead ends fills it with clutter. When answers start repeating or drifting, type /compact to clear it out, or quit and start fresh.

Neither one loses your work. Your files are on disk and your commits are save points. And because CLAUDE.md is read automatically at the start of every session, a fresh session already knows what matters.

The file Claude writes for itself

At some point you will see something like "Saved 2 memories" go past in the interface, and it is worth knowing what that was.

Alongside the file you write, Claude keeps notes of its own. When you correct it, or tell it how you like to work, it can write that down so it does not have to be told again. This is on by default and it is genuinely useful. It is also completely separate from CLAUDE.md.

Two differences matter for a team project:

• Those notes live on your laptop, outside your project folder. They do not get committed and they do not travel to GitHub.
• Your teammates never see them. Two people on the same project can have Claude behaving differently, and neither of them can tell why.

So anything that has to be true for everyone goes in CLAUDE.md, which you wrote and which everyone shares. Treat the notes Claude keeps as a convenience rather than a place to put anything important. If you are curious what it has saved, type /memory in the terminal.

The one-page PRD

PRD stands for Product Requirements Document, which sounds more corporate than it is. It is one page describing what you are building, written before you build it.

You will write your real one before Session 6, when you build the walking skeleton. Save it in your project folder as prd.md, because later prompts ask Claude Code to read it by that name. Learn the format now.

FILE: prd.md

PRODUCT: [name]

USER: [a specific person, not a category]
  Good: "freelance photographers with 5 to 50 clients"
  Bad: "small businesses"

PROBLEM: [one sentence]

CORE USER STORY:
  As a [user], I can [action] so that [outcome].

FEATURES (maximum 3):
  1. [feature] - done means: [something you can observe]
     Example: "user submits the form and sees a confirmation message"
  2. ...
  3. ...

OUT OF SCOPE (the v2 parking lot):
  [Everything else you are tempted by. Write it down so you can stop
  thinking about it.]

DATA WE STORE:
  [Plain English. "Users. Each user has projects. Each project has
  photos and a status."]

Two things make a PRD useful rather than decorative.

The "done means" clause. If you cannot describe how you would observe that a feature works, you cannot tell whether the AI finished it. Vague acceptance criteria are how you end up with a feature that is 90 percent done forever.

The out-of-scope list. Writing down what you are not building is what stops you from building it. Every team in this course tries to build too much.

When you have a PRD, paste it into Claude Code in Plan mode, read the plan it produces, and build feature one only.

---

Session 3, on 9/9. The last section is for Session 6 onward.

Two words that sound like one thing

Git and GitHub are different things that share a syllable, and mixing them up is the most common confusion in this Part.

Git is a save-point system that runs on your laptop. It keeps a numbered history of your project, and it lets you go back to any point in that history. It is entirely local. Turn off the wifi and git still works.

GitHub is a website that holds a copy of that history. It is what makes your work survive a dead laptop, and it is where the "repo link" that assignments ask for comes from.

Staying with the restaurant analogy this handbook uses later: git is the notebook in the kitchen where you write down every version of the recipe. GitHub is the photocopy you keep off-site, in case the kitchen burns down.

You never need to learn git commands. Claude Code runs them for you. What you need is to know which of the two you just did.

Commit, then push

Everything in this section is written for working on your own, which is what you are doing at Session 3 on your practice project. Once your team shares one repository at Session 6, one rule changes. That is the last section of this Part, and you do not need it yet.

These are two separate actions. Doing one is not doing the other.

	Commit	Push
What it does	Records a save point	Sends your save points to GitHub
Where the copy lives	Your laptop only	GitHub's servers
How often	After every working feature	At least once per work session
What breaks if you skip it	You cannot go back	Your laptop dies and the work is gone

Read the last row twice. A student who commits diligently all semester and never pushes has no backup at all, and feels completely safe. This happens every year.

PROMPT, after every working feature:

Copy
Commit this with a sensible message.

PROMPT, at least once per work session:

Copy
Push this to GitHub.

PROMPT, the very first time, instead of the one above:

Copy
Create a GitHub repository for this project and push it. Make the
repository private. Walk me through any login steps.

Never create a public repository for your course project. Public means anyone can read every file, including any secret key that slipped through Rule 4. Private is one click at creation time and it is the default you want. You can share a private repo with an instructor without making it public.

What this actually looks like

Ask Claude Code to show you the history. The exact formatting varies, but you get a list like this, one line per commit, newest at the top:

PROMPT

Copy
Show me my recent commits.

What comes back:

a4f2c91  Add email signup form to landing page      12 minutes ago
7b3e8d5  Fix chart not updating after edit          1 hour ago
2c9a1f7  Add expense pie chart                      2 hours ago
e81b4a3  First working version                      yesterday

That is the undo list. "Revert to the last working one" means going back to one of those lines. The messages are why you ask for sensible ones. At Session 9 you will be reading this list looking for the moment before things broke.

PROMPT, when something breaks:

Copy
The app was working thirty minutes ago and now it is broken. Show me the
recent commits and revert to the last working one.

You'll know the push worked when you open github.com in a browser, click your repository, and see your files listed with those same commit messages beside them. Do this the first time. Claude Code saying "pushed successfully" is exactly the kind of claim Rule 3 exists for.

Never go a whole session without committing. The one time you do is the time you will need it.

Your git history is graded

This is not just housekeeping. The commit history is one of the artifacts this course assesses, alongside your build log, because it shows how you worked rather than what you ended up with. A history of small, frequent, sensibly labelled commits looks like someone taking steady steps. One enormous commit at midnight looks like what it is.

You also hand in the repository link three times: with the First App on 9/16, with the MVP demo on 11/4, and with the final package on 12/11. That link is the GitHub web address of your project.

Deploying gets you a real URL

Deploying is a third thing, and it is not pushing. Push sends your code to GitHub, where it is stored. Deploy sends your app to Vercel, where it runs and strangers can use it.

Action	Destination	Result
Commit	Your laptop	A save point
Push	GitHub	A backup, and your repo link
Deploy	Vercel	A live URL anyone can open

PROMPT

Copy
Deploy this app to Vercel. Walk me through it step by step. I have never
done this before.

The first time takes about fifteen minutes of following instructions. It will ask you to connect your GitHub account, because Vercel takes the code from your repository. That is the first time the two halves visibly connect.

You'll know it worked when Vercel gives you a URL ending in .vercel.app, you open it on your phone, and your app appears. Text it to a friend. If it works for them, it is really deployed.

After the first time, it is one command.

This matters more than it sounds. A live URL turns your idea from something you describe into something a stranger can use. That is the difference between asking someone whether they would like your product and watching whether they sign up. The second one is evidence. The first one is conversation.

Working as a team

Teams form at the end of Session 3. This section becomes real at Session 6, when you start the product you keep.

Up to now you have been the only person in your project. From Session 6 there are three or four of you in one repository, and the failure mode changes completely. Nothing in this section is about writing better code. It is about not overwriting each other.

The one rule that changes. On your own practice project, saving straight into the main version of the project is fine, and it is what you have been doing. On the shared product repository, nobody does that. main is the version that works, the one that is deployed, and the one you hand in. It is not a place to try things.

Everything below is how you work without touching it.

Decide who wears which hat

You are all builders. These are not job titles and they do not divide the work. They answer the question "who decides" before the moment you need an answer, which is the only time it is cheap to decide.

Hat	Owns the file	The call they make
Product owner	prd.md	What gets built and what goes on the out-of-scope list
Integrator	main	Reviews each teammate's work and merges it in
Evidence owner	research/ and interviews/	Says "we have no evidence for that" out loud
Demo owner	qa-report.md and the demo script	What gets shown at Session 10 and Session 13

Pick them in your first team meeting. It takes five minutes. Write them at the top of your shared CLAUDE.md so the file states them and Claude reads them too. Rotate them halfway through if you want to; teams that rotate usually learn more.

The product owner hat matters most, and earliest. Every team in this course argues about which feature to build. The argument is not the problem. Not having agreed in advance who ends it is the problem. See the cut list in Part 10.

Set the repository up once

One person does this, at Session 6, and only once.

PROMPT, from the product folder:

Copy
Create a private GitHub repository for this project and push it. Then
tell me how to add my teammates so they can push too, and what each of
them should do to get a copy onto their own laptop. Walk us through it.

You'll know it worked when every person on the team can open the project folder on their own machine and see the same files.

The handoff loop

Do these six steps every time you sit down to work. All of them are prompts. You never type a git command yourself.

1. Pull before you start. Always. This is the step people skip and it is the step that prevents the mess.

PROMPT

Copy
Pull the latest changes from GitHub before we start.

2. Make a branch. A branch is your own copy of the project to work in, so that whatever you break is broken only for you. Name it after the thing you are building.

PROMPT

Copy
Create a branch called signup-form and switch to it.

3. Build, in the core loop from Part 3. Commit after every step that works, exactly as before.

4. Push your branch and ask for it to be brought in. A pull request is the polite version of "I think this is ready, will someone look."

PROMPT

Copy
Push this branch and open a pull request. Summarize what changed in
plain English, so a teammate who did not write it can review it.

5. The integrator reviews it, then merges. Only that person, and they read before they merge.

PROMPT, for the integrator:

Copy
Show me what this pull request changes and explain it in plain English.
Flag anything that could break the app.

If it looks right, merge it. If it does not, say so in the pull request on GitHub and the author fixes it on the same branch.

6. Everybody pulls again. Back to step one.

Any of these words you have not met before are in the glossary at Part 18.

When two people change the same thing

This is called a merge conflict, and it means exactly one thing: two of you edited the same lines, and git will not guess which version wins. It is not a disaster and it is not your fault.

PROMPT

Copy
We have a merge conflict. Explain in plain English what two changes are
in conflict and which parts of the app each one affects. Do not pick for
me. I will tell you which one to keep.

Then decide, out loud, with the person who wrote the other half. Never let Claude choose for you here, and never guess. Choosing wrong silently deletes a teammate's work.

Never have two people building the same feature at the same time. Every conflict you will hit this semester is preventable with a two-minute message that says what you are about to touch.

One thing to watch once you start using branches: Vercel will give every pull request its own preview URL, which is handy for showing a teammate what you did before it goes in. The real URL is the one that comes from main, and that is the one you should hand in, measure, and put in front of a user. If you user-test a preview URL, you are testing something that is about to change.

You'll know the whole thing worked when a teammate opens your pull request on GitHub, reads your summary, merges it, pulls, and your feature is running on their laptop and on the live URL without either of you sitting next to the other.

Everything above is about the repository, which you share. Your build log stays yours alone, and Part 6 explains why.

---

Starts Session 4, on 9/16. Runs every week until the end of the course.

The build log is your own record of what you did. It is individual, not shared with your team. Each person keeps their own.

It is graded twice: a checkpoint on 11/4 with the MVP demo, and a final pass on 12/11.

At the final pass you mark your best entries and annotate each one. Graduate section: four entries. Undergraduate section: three.

Why it exists

This course cannot grade your code, because AI wrote most of it. What it can grade is your judgment: what you tried, what broke, how you recovered, and whether you noticed when the AI was wrong.

The build log is the evidence of that. A student who describes three failed approaches and a recovery is demonstrating more skill than a student who reports that everything worked.

This is also why it stays individual while the repository is shared. Four people working in one repo have four different weeks. A handoff that went wrong, a merge conflict you had to think about, a feature you argued for and lost, are all exactly the kind of entry that scores well, and none of them would survive in a shared document.

The format

One entry a week. Five minutes. Keep it in a file called build-log.md in your real product folder, not in a probe folder, because the probes get thrown away and this is graded.

FILE: build-log.md

## [date]

Tried:
  [What you set out to do this week]

Broke:
  [What went wrong. If nothing went wrong, you did not try hard enough.]

Fixed by:
  [What actually worked, including the dead ends]

Learned:
  [Something you did not know last week]

Next:
  [What you are doing next week]

What makes an entry good

The test is whether someone reading it could tell it was you who wrote it.

Weak: "Worked on the signup form. Had some issues but fixed them. Learned about databases."

Strong: "Tried to add email signup. Claude built it and said it was working. The form submitted and showed a success message, but no emails were arriving in Supabase. Claude insisted the code was correct. I checked the Supabase dashboard directly and the table was empty. Turned out it had created the table with a different name than the code was writing to. Lesson: a success message in the browser proves nothing about what happened in the database."

The second one takes four minutes to write and is worth several times the first one.

The one entry that must exist

At least one of your entries has to describe a time AI was confidently wrong, you caught it, and what it would have cost you if you had not.

This is the whole course in one paragraph. Do not leave it until December. Write it the week it happens, because you will forget the details.

---

---

Session 4, on 9/16.

Claude Code is not only for writing code. It can search the web, read what it finds, and write reports into files you keep. That makes it a research assistant that works at a speed you could not match.

It also makes things up. Both of these are true at once, and managing that is the skill.

The iron rule: every factual claim gets a URL. AI invents facts confidently. Made-up citations look exactly like real ones. You are graded on its errors as if they were your own, because they are.

The prompts below all end by telling Claude Code to write its report into a research/ folder inside your project. You do not need to create that folder first. Claude makes it.

7.1 Opportunity scan

PROMPT

Copy
You are a market research analyst. Research this problem space:
[for example, "small landlords managing maintenance requests"].

1. Who has this problem? Estimate how many such people or businesses
   exist in the US. Show your reasoning and your sources.
2. What do they use today? List tools, spreadsheets, and manual
   workarounds.
3. Search Reddit, G2, Capterra, and app store reviews for complaints
   about current solutions. Quote 10 real complaints with links.
4. Why might this be newly solvable with AI in 2026? Be specific about
   which capability changed and when.

Write the findings to research/opportunity-scan.md with a source URL for
every claim. Flag anything you could not verify.

7.2 Complaint mining

The fastest way to find a real problem is to read people complaining about the one they have. Three places are consistently productive.

Review sites. G2, Capterra, and app store reviews for the tools your users already pay for. Filter to one and two stars. People are specific when they are angry.

Reddit and forums. Search for the workaround, not the product. People post "how do I keep track of X in a spreadsheet" long before they look for software.

Job postings. If companies are hiring humans to do something repetitive, that is a job someone would pay software to do.

PROMPT

Copy
Search for complaints about [category of tool] from the last 18 months.
Look at G2, Capterra, app store reviews, and Reddit.

Group the complaints into themes. For each theme: how often it comes up,
three verbatim quotes with links, and whether it is a product problem or
a pricing problem.

Then search job postings for roles that involve [the task]. What are
companies paying humans to do here, and how much?

Write to research/complaints.md.

Watch the workarounds. When you find people using a spreadsheet plus email plus a group chat to do one job, that is a product waiting to exist. Workarounds are the clearest signal in customer research, because nobody builds a workaround for a problem they do not have.

7.3 Competitor teardown

PROMPT

Copy
Research these competitors: [list them, or say "find the top 5 products
that do X"].

For each one: pricing taken from their pricing page with a link, three
core features, target customer, funding if it is public, and the three
most common complaints in their reviews, quoted and linked.

Output a comparison table in research/competitors.md.

Then answer: what does nobody serve well?

Mark any claim you inferred rather than verified with [UNVERIFIED].

7.4 Market sizing, bottom up only

PROMPT

Copy
Help me size the market bottom up for [product] at [price] per month.

Number of [target customers] in the US, times a plausible adoption
percentage, times price.

Use a real source for the population number. Give a conservative, base,
and optimistic case. State every assumption in a table I can defend to
an investor.

Do not use top-down logic. "One percent of a fifty billion dollar
market" is not a market size.

7.5 The "why now" test

Every venture that works has a reason it could not have been built three years ago. For AI ventures the reason has to be specific. "AI is big" is not a reason.

PROMPT

Copy
I claim [product] is newly possible because [specific AI capability].

Find evidence for and against. Look at benchmark results, product
launches, and adoption data from the last 18 months.

Then argue the strongest version of both counterarguments:
1. "This was already possible five years ago."
2. "This still is not possible."

I want to test my claim, not confirm it.

The verification pass

Do this after every research agent run. Open five of the cited links yourself, chosen at random. If one is broken, or does not say what the report claims it says, redo that section.

Budget fifteen minutes. It is the difference between research and fiction, and it is the thing that separates a Discovery Report that scores well from one that does not.

---

Session 4, on 9/16.

Part 7 gathered information. This part is about judging it, and about judging the idea it was gathered for.

These are two different skills and the second one is harder. A research report always reads as though it found something. Your job is to work out whether it did, and then whether the problem behind it is worth six weeks of your life.

An AI assistant is genuinely useful here, for one reason: it has nothing invested in your idea. It will happily write the case against you, which is the case you are least able to write yourself. It is also happy to agree with you, so the prompts below are built to stop it doing that.

Make the answers readable

By default you will get long, padded, repetitive answers with a summary at the end that repeats the middle. Paste these lines at the end of any prompt in this part:

Copy
Keep it short. No introduction and no summary at the end. Do not repeat
my question back to me. Plain English. If you are not sure about
something, say so in one line rather than hedging all the way through.

You will use this constantly for the rest of the semester. It is worth putting in your CLAUDE.md so you stop typing it.

8.1 Score your candidates side by side

You have two or three problem areas and you have to choose one. Judging them one at a time does not work, because whichever you read last feels freshest.

PROMPT

Copy
Read the reports in research/.

I am choosing between these problem areas:
1. [area one]
2. [area two]

Score each from 1 to 5 on four things: how often the problem happens to
them, what it costs them today, whether anyone already pays to solve it,
and whether we have any way to reach these people.

Quote the line of research behind every score. Where the research does
not support a score, write "not established" rather than guessing.

Put it in one table.

The scores are not the point. The "not established" cells are. If nobody can tell whether these people already pay for anything, you have found the hole in your research, and it is a better result than a confident number would have been.

You'll know it worked when at least one cell says "not established." If every cell has a score, it is guessing and you should ask it which ones it inferred.

8.2 What would have to be true

You now believe something. This turns that belief into a list you can actually check.

PROMPT

Copy
We believe [the thing you believe, for example: an independent dog
walker would pay $40 a month for this].

List everything that would have to be true for that to hold, including
things about how these people work that we may not have thought of.

Then sort your list into three groups:
- things our research already established
- things we could find out by talking to five of these people next week
- things we cannot know yet

The middle group is your interview guide for Part 9. You did not have to invent it, and it came out of evidence rather than out of your imagination.

8.3 Write your kill criteria

The Discovery Report asks what would make you abandon the idea. Write it now, tonight, while you are not attached to it yet. In four weeks you will not be able to answer this honestly.

PROMPT

Copy
Based on the research in research/ and the gaps we just found, write
three things we could learn in the next two weeks that would mean we
should stop working on this idea.

Make each one specific enough that we would recognise it if it happened.
"People are not interested" is too vague to be useful.

Keep the answer. It goes in the Discovery Report, and it is one of the things that separates a team that is doing research from a team that is collecting reasons.

8.4 Two ways to get a real second opinion

The three moves above still happen inside a conversation that has spent the last hour helping you. Two ways out of that.

Ask it to argue against you.

Copy
Argue against this idea. I am not asking for a balanced view.

Give me the four strongest reasons [idea] fails, using only what is in
research/ and not what you assume.

For each reason, tell me what we could see or hear in the next two weeks
that would show it is happening.

Do not offer solutions and do not soften anything.

Send a helper that has not been listening. Claude Code can hand a job to a subagent, which is a fresh helper with its own workspace that has not seen your conversation. It has not spent an hour agreeing with you, which is the whole value of it.

Copy
Use a subagent to review our decision.

Give it the research folder and tell it which problem area we chose. Ask
it one question: would somebody reading only this evidence have chosen
the same one?

Report back what it said, including anything it disagreed with.

If it comes back agreeing, that is mildly reassuring. If it comes back with a different pick, you have something worth arguing about at the table, which is more useful.

8.5 What none of this proves

Everything in this part is a machine producing arguments about a report produced by a machine. You can generate a beautiful case against your idea and learn nothing at all.

What these moves actually do is narrow down what you need to go and find out. They tell you which questions matter. They cannot tell you the answers, because the answers are held by people who have the problem, and none of those people are in your terminal.

That is Part 9, and it is where the evidence in this course comes from.

---

Session 5, on 9/23. Interviews are due with the Discovery Report (10/28 for the graduate section, 10/27 for the undergraduate section).

AI prepares and synthesizes. Humans validate.

Synthetic interviews are inadmissible as evidence in this course. You may use AI to rehearse against a fake customer. You may never count that as data. This is a hard rule and it is graded.

Minimums, all due with the Discovery Report on 10/28 (graduate) or 10/27 (undergraduate):

	Interviews required
Graduate team	8
Undergraduate team	5
Graduate working alone	6
Undergraduate working alone	4

Bring something for them to react to

Before the interviews, build a one-page site describing your idea. A headline, a few bullets saying what it does and who it is for, and a box where a screenshot would go. About twenty minutes.

You are not putting it online, not collecting email addresses, and not taking money. It exists so that the person across the table has something concrete in front of them.

PROMPT

Copy
Build a one-page landing site for [idea], for [the specific kind of
person it is for].

Include a headline that states the problem, three benefit bullets, and
one placeholder box where a screenshot would go.

Do not add a database, a login, a signup form, or any other features.
This is a page for showing to someone, not a product.

Make it look credible rather than fancy, then show me how to open it on
my own machine.

Two things it does for you. Writing the headline forces you to decide who this is for, and a team that cannot agree on the headline has not agreed on the idea. Then, in the interview, handing someone a page gets you a more honest reaction than describing the idea out loud, because a spoken pitch quietly invites the listener to be encouraging.

The comprehension test. Show it for thirty seconds, take it away, and ask them to tell you what it does and who it is for. Write down what they said rather than what you hoped they would say. If they cannot describe it, you have learned something about the idea.

Never claim the product exists. Say it is an idea you are exploring, which is true, and which people are perfectly happy to talk about. No invented testimonials, no borrowed customer logos, no made-up statistics in the copy.

Be clear with yourself about what this is worth. Somebody saying "that sounds useful" is close to the weakest evidence there is, and you will hear it a lot. The page is a prop that makes the conversation better. The conversation is the evidence.

9.1 Draft the interview guide

PROMPT

Copy
I am doing customer discovery for [idea], targeting [user].

Draft a 20-minute interview guide following The Mom Test rules:
- Do not pitch my idea
- Ask about their life and their past behavior
- No hypothetical "would you use this" or "would you pay" questions

Cover: their current workflow, the last time the problem happened, what
it cost them, what they have already tried, and what they pay for today.

Then review your own guide and flag every leading question you wrote.

That last line matters. AI writes leading questions by default, because it is trying to be helpful about your idea. Asking it to attack its own draft catches most of them.

9.2 Rehearse against an AI customer

This is practice. It is not data.

PROMPT

Copy
Role-play a [busy restaurant owner in Dallas]. You are skeptical, busy,
and slightly annoyed at being pitched another app. Do not be agreeable.

I will practice my customer interview on you. Stay in character.

Afterwards, break character and grade me. Where did I pitch instead of
listen? Where did I ask leading questions? What did I fail to follow up
on?

9.3 During the real interview

Three rules that are harder than they sound.

Talk less than the other person. Aim for the interviewee speaking eighty percent of the time. If you are explaining your idea, you are not doing research.

Ask about the last time, not about generally. "When did this last happen?" gets you a story with details. "How often does this happen?" gets you a guess.

Follow the emotion. When someone gets animated, annoyed, or suddenly specific, stop your script and ask why. That is where the real problem lives.

Get consent before recording. Say what you are recording, what you will do with it, and who will see it. If they say no, take notes instead. Consent is not a formality here, because these are real people and you are storing what they said.

9.4 Synthesize what you heard

After each interview, write or dictate your notes into a file: interviews/person-1.md, person-2.md, and so on. Do this the same day, while you still remember which things mattered.

If you recorded with consent, you can transcribe:

PROMPT

Copy
Transcribe this recording into interviews/person-N.md. Keep the exact
wording. Do not clean up the grammar or summarize. I need the verbatim
quotes.

Then, once you have several:

PROMPT

Copy
Read all files in interviews/.

Extract across ALL interviews:
1. Recurring pains, ranked by how often they came up and how intense
   they were, with verbatim quotes for each
2. Current workarounds people described
3. Any evidence of willingness to pay: money or time already spent
4. Statements that CONTRADICT our idea. Do not soften these. Quote them
   exactly.
5. What we should ask better next time

Write to research/interview-synthesis.md. Tag each finding with which
interviews it came from.

Point four is the one that matters. AI is agreeable by default and will happily assemble a case that your idea is great. Asking explicitly for disconfirming evidence is the only reliable way to get it.

Try this as a follow-up:

PROMPT

Copy
Now argue that our idea is wrong, using only the interview evidence.
Build the strongest case you can that we should not build this.

If the AI cannot build that case from your interviews, either your idea is unusually well supported or you have not interviewed enough people. It is usually the second one.

9.5 Surveys

Surveys are weaker than interviews and much weaker than behavior. Use them to test something specific across more people, after interviews have told you what to ask.

PROMPT

Copy
Draft a 6-question survey testing [specific hypothesis].

Rules: no leading questions, no double-barrelled questions, no questions
about hypothetical future behavior. Ask about what they have actually
done.

Then review your own draft and flag every question that violates those
rules.

---

---

Session 6, on 9/30.

Your idea is locked. Now you build the real thing, and the first job is deciding what "the real thing" is.

The cut list

Every team wants to build too much. Do this exercise in class:

1. List ten features you imagine your product having.
2. Cut to three.
3. Cut to one core feature plus two supporting ones.
4. Everything else goes on the out-of-scope list in your PRD.

The features you cut are not gone. They are in the parking lot, where they belong until you have evidence anyone wants them.

You will not all agree, and the exercise is not finished when you do. It is finished when a decision exists. When the team is split, the product owner from Part 5 decides, the losing feature goes on the out-of-scope list with today's date beside it, and the conversation ends there. Writing the date down is what stops the same argument happening again in three weeks. This is the entire reason that hat exists.

MVP means minimum testable, not minimum

An MVP is not a bad version of your product. It is the smallest thing that tests your central assumption.

Ask: what is the one workflow that proves the value hypothesis from your Discovery Report? Build that. Nothing else.

Wizard of Oz is legitimate

If the hard part of your product is genuinely hard, do it manually at first and automate later. This is a real technique with a real history. DoorDash's founders delivered the food themselves. Users do not care whether a human or a machine is behind the curtain, as long as the job gets done.

If your AI feature is not working after two sessions of trying, replace it with yourself for now, and say so in your demo. A working product with a human in the loop beats a broken product with an ambitious architecture.

The walking skeleton

Before you make anything good, make something that works end to end, badly.

A walking skeleton is the thinnest possible version where a user can complete the core action from start to finish. Ugly is fine. Slow is fine. Missing everything except the one path is fine.

The reason is that end-to-end problems are the expensive ones. If you build a beautiful front end for three weeks and then discover the data model does not work, you have lost three weeks. If you connect everything badly on day one, you find that problem immediately.

PROMPT

Copy
Read CLAUDE.md and prd.md. We are building the MVP.

Propose the simplest architecture using Next.js, Supabase, and Vercel.

Then build a walking skeleton: the thinnest possible end-to-end version
where a user can [core action]. Ugly is fine. Working is mandatory.

Plan first. Then go one step at a time, and tell me what to test after
each step.

Do this before you leave the Session 6 lab: get the skeleton running and commit it. If it is not running, that is what office hours are for, and it is much cheaper to fix at Session 6 than at Session 10.

Your first real feature

Session 7, on 10/7.

The skeleton walks. Now give it one feature that a user would actually notice, chosen from the three in your PRD. One. The cut list exists so that you can answer "which one" without a meeting.

Work in the core loop from Part 3, and commit after each step that works.

One habit belongs in this week and not later.

A deployed version that matches what you built. From this week on, get your work merged into main and deployed at the end of every work session, not only when something is due. A product that only runs on your laptop cannot be user-tested, and user testing starts in two weeks.

(Analytics, which counts how many people visit your live site, is installed at Session 8. The walkthrough is 11a in Part 11.)

---

Session 8, on 10/21.

You have something that runs. Now you make it an application people could actually use.

What you can add, and when you would need it

This is the map for the Session 8 lab. The step-by-step instructions are further down this Part, under the headings 11a to 11h.

Your product runs, and at the moment it probably does one thing. This Part is about extending it. Each row in the table below is a ready-made service that you connect to your product so that it can do something new, such as remember things, take a payment or send an email. (The handbook calls these components.) You do not build any of them yourself. You create an account with the service, and Claude Code does the connecting.

	Component	What it is	Why it is useful	You would need it when...	Account you create	Difficulty
11a	Analytics (Vercel Analytics)	A counter that records how many people visit your live site and which pages they open	It tells you whether anybody is using what you built, which is evidence you can bring to the demo	you are about to put the product in front of real people, which every team is	None. It is part of your Vercel account	Easy
11b	Database (Supabase)	A place where your product keeps things	It remembers what a user did between visits	your product forgets everything when the page is refreshed	Supabase	Medium
11c	AI feature (Google Gemini)	A way for your product to send text to an AI model and get text back	It can summarize, draft, classify or answer	an AI step sits at the center of what your product does	Google AI Studio	Easy
11d	Payments (Stripe)	A checkout page that Stripe hosts for you, using fake cards	You can find out whether anybody presses "pay" without touching real money	you are testing whether people would pay	Stripe	Medium to hard
11e	Sign-in (Supabase)	User accounts	Each person has an account and sees only their own things	your product needs to know who the user is	Supabase (do 11b first)	Medium
11f	Email (Resend)	A service that sends email on your product's behalf	It can send a welcome or notification email	your product should tell the user something after they have left	Resend	Easy to medium
11g	File upload (Supabase)	Storage for files that users give you	Users can hand it a PDF or a photo	your product starts with the user's own document or photo	Supabase (do 11b first)	Medium
11h	Live outside data (Open-Meteo)	A free source of real, current information (the weather, in this example)	It shows facts from the outside world	your product needs information it does not hold itself	None	Easy

How the lab runs. Every team does 11a first. Analytics can only count visits that happen after it is switched on, and there is no way to recover earlier usage afterwards, so it goes in before anything else. It is also the shortest walkthrough here. After that, please pick one of 11b to 11h, whichever your product needs most, and work through it from the top. Nothing from 11b onward is required for a grade. The aim is that your team can add a component when you need one, having done it once with help in the room.

If you are not sure which to choose, 11h and 11c are the gentlest, and either is a good first one if this is all new to you. 11e and 11g build on 11b, so please do the database first if you want either of them.

What you need before you start. Every walkthrough assumes you already have these four things, which you set up in earlier sessions:

• your project folder, with Claude Code running inside it (Part 1, "Every time you sit down to work")
• a CLAUDE.md file and a prd.md file in that folder (Part 4)
• your project on GitHub (Part 5)
• a live URL on Vercel (Part 5)

If one of these is missing, please tell your instructor or TA before you begin, because the steps will not make much sense without it. The walkthroughs assume nothing beyond this list, so each one starts from creating the account.

The course stack

Do not deviate without a reason you can explain.

Piece	What it does
Claude Code	Your engineer
Next.js	The app framework. Claude chooses and manages it.
Supabase	Database and user accounts. Free tier.
Vercel	Hosting. Free tier.
Stripe	Payments, if your team chooses to add a checkout. In this course you use only its practice mode, where no real money moves.

The plain English map

When Claude uses these words, this is all they mean:

• Frontend is what users see. The dining room.
• Backend is the logic that does the work. The kitchen.
• Database is where things are stored. The pantry.
• API is how the pieces talk to each other. The waiter.

That analogy will get you through every architecture conversation in this course.

What you never build yourself

Authentication, payments, and email. Three things that look simple and are not. Getting them wrong has real consequences, and solved versions are free.

• Sign in uses Supabase Auth, or "Sign in with Google."
• Payments use Stripe.
• Email uses a service, never code you wrote.

PROMPT

Copy
Add sign-in to the app using Supabase Auth. Support email and Google.

Explain in plain English what happens to a password, where the session
is stored, and what a user sees if they are not signed in.

The general rule for build versus buy: if it is not the thing that makes your product different, buy it. Your competitive advantage is not your login page.

Your data model

A data model is a plain English description of what you store and how the pieces relate.

PROMPT

Copy
Here is what our app needs to store, in plain English:

[for example: "Users. Each user has projects. Each project has documents
and a status. Each document has an AI-generated summary."]

Design the database tables for this in Supabase. Explain each table and
each relationship in plain English before you build anything.

Then tell me: what happens if a user deletes a project? What happens to
its documents?

That last question catches a category of problem early. Most data model bugs are about what happens when something is removed.

Calling an AI model from inside your app

Many products in this course call an AI model as part of what they do. Summarizing a document, drafting a reply, categorizing an entry.

PROMPT

Copy
I want the app to [AI feature].

Add a call to the Claude API for this. Explain where to get an API key,
how to store it safely as an environment variable, and roughly what each
call costs.

Add a sensible fallback message for when the API fails or is slow.

Two things to watch.

Cost. This is a second, separate charge. Your Claude Pro subscription pays for Claude Code, which is you talking to Claude. An API key is your app talking to Claude, and it is billed on its own, by usage. For an MVP at classroom scale, expect a few dollars a month, not hundreds. Ask Claude to estimate before you launch. If the estimate is large, your prompt is probably sending far more text than it needs to. Set a spending limit on the API account the day you create it.

Failure. APIs go down and time out. If your app shows a spinner forever when that happens, your demo will be the time it happens. Always have a fallback message.

How the walkthroughs work

This is the Session 8 lab. The map at the top of this Part tells you which walkthrough to choose.

There are eight walkthroughs below, 11a to 11h, and they all have the same shape. Each one tells you what it adds and when you would need it, and then gives you numbered steps with one action in each. Please do the steps in order and finish one before you start the next, because most of them depend on the one before.

Two things are true of every walkthrough. The websites involved rename their buttons fairly often, so if what you see on screen does not match a step, please do not guess. Tell Claude Code what you are looking at (e.g., "I am on the Supabase dashboard and I cannot find the API keys") and ask where to click. And the main prompt in each walkthrough asks Claude to explain what it is doing, because you will need to explain it at the demo.

The main prompt also begins by asking Claude to read CLAUDE.md and prd.md, so that it knows what your product is before it changes anything. It ends by asking Claude to write the new service into the Stack section of CLAUDE.md, so that your next session (and your teammates' sessions) will know it is there.

Most walkthroughs finish with a step that says to check it on the live site. That means getting the change into main the way your team normally does (Part 5), waiting for Vercel to finish deploying, and then repeating the test at your live URL. A component that only works on your laptop is not finished yet.

If you are working as a team, two things are worth knowing before you begin. Several steps happen on vercel.com, inside your project. The Vercel project usually sits in the account of whichever teammate deployed it, so please do those steps on that person's laptop, or with them sitting next to you. And .env.local is never committed, which means it does not travel through GitHub. Each teammate who runs the app on their own laptop needs their own copy of the file, with the keys pasted in by hand (and passed along in person or through a password manager, not in a chat message).

How keys work

Most of the walkthroughs give you a key. (11a and 11h do not, so you can skip this section if those are the only two you are doing.) A key is a password that lets your app use somebody else's service, and Rule 4 in Part 2 already told you how to treat one. Here is the part that is new.

A key has to be in two places. Your app runs on your laptop while you build it, and on Vercel once it is live, and each of those needs its own copy of the key.

• On your laptop, the key goes in a file called .env.local in your project folder. Each line is a name, an equals sign and the key, with no spaces and no quote marks.
• On your live site, the key goes into Vercel. Open vercel.com, click your project, then Settings, then Environment Variables. Type the same name and paste the same key, and save. Vercel only picks up a new key the next time it builds your site, so push a commit afterwards (or ask Claude Code to redeploy).

FILE: .env.local

GEMINI_API_KEY=paste-your-key-here

The file is easy to miss, because your computer hides files whose names start with a dot, so you will not see it in Finder or File Explorer. The simplest way to get to it is to ask Claude Code to create .env.local with the names already in it and nothing after the equals signs, and then open it yourself with one command, typed in your second window while you are in your project folder.

TERMINAL (Mac)

open -e .env.local

TERMINAL (Windows)

notepad .env.local

Paste your key after the equals sign, save, and close the file.

When a component works on your laptop and fails on the live site, a key missing from Vercel is usually the reason.

Some keys are meant to be seen, and some are not. Services that your app talks to straight from the browser, such as Supabase and Stripe, give you a publishable key, which is safe for visitors to see, and a secret key, which is not. The other two keys in this Part (the Gemini key and the Resend key) are secret. A secret key must only be used by code that runs on the server, which is the kitchen in the restaurant picture, and never by code that runs in the visitor's browser, where anybody can read it. You do not need to know how to arrange that. You do need to ask, and every prompt below does.

Never paste a key into Claude Code, into a chat message, or into any file other than .env.local. Type or paste it into the file yourself, and let Claude refer to it by its name.

You'll know it worked when you ask Claude Code to search the project for the first few characters of your key and it finds them nowhere, and .gitignore contains a line reading .env.local.

11a. Analytics (Vercel Analytics)

Every team does this one, at the start of the Session 8 lab.

What this adds. Analytics is a counter on your live site. It records how many people visited and which pages they opened, and it shows you the totals on a page inside your Vercel account. Visitors do not see anything different. Vercel says that it identifies visitors without third-party cookies and records each page view anonymously, so what you get is totals, and no record of what a named person did (Vercel, Privacy and Compliance).

You would need it when you are about to show your product to real people, which every team does over the next two weeks. Analytics can only count visits that happen after it is switched on, and there is no way to recover last week's usage afterwards. That is why it goes in today, while the site is quiet and a mistake costs nothing.

What it costs. Nothing. Vercel's free plan (Vercel calls it Hobby) includes 50,000 page views a month, which should be far more than a class project sees. There is no new account to create and no key to copy.

Step 1. Open your project on Vercel. Go to vercel.com, sign in, and click your project.

Step 2. Switch analytics on. Click Analytics in the sidebar, and then click the Enable button. Please do this before the next step, because analytics that is added to the code before it is enabled tends to show no data.

Step 3. Ask Claude Code to add it to your app. Go back to Claude Code in your project folder and paste this.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add Vercel Web Analytics to this app. I have already clicked Enable on
the Analytics page for this project in the Vercel dashboard.

If this is a Next.js app, install the @vercel/analytics package and add
the Analytics component to the root layout. If it is a plain HTML site
with no package manager, tell me so, and follow the HTML instructions in
Vercel's Web Analytics quickstart instead.

Explain in plain English what you added, which file it is in, and what
it sends to Vercel when somebody opens a page.

Then add Vercel Analytics to the Stack section of CLAUDE.md.

Step 4. Put the change on your live site. Get it into main the way your team normally does (Part 5), and wait for Vercel to finish deploying. Analytics only starts counting from the first deployment after you enabled it.

Step 5. Visit your own site. Open your live URL, the one that comes from main, and click through two or three pages.

Step 6. Look at the count. Go back to the Analytics page in Vercel and refresh it. It can take a minute or two for a visit to show up, so please refresh once more before you decide something is wrong.

You'll know it worked when the Analytics page stops saying it is waiting for data and shows at least one visitor, which is you.

Three things about reading the page, which will matter at Session 9:

• It shows Production by default, which means your live URL from main. Visits to a preview URL from a pull request are kept separately, under the environments dropdown at the top right. Visits to the copy running on your laptop are not counted.
• On the free plan it counts visitors and page views, and it does not count button clicks. (Vercel calls those custom events, and they need a paid plan.)
• The free plan only promises to keep one month of data, so please take a screenshot of the page the day before your demo.

Try this if you want to know whether people finish the core action in your PRD: ask Claude Code to give that moment a page of its own (e.g., a "done" or "thank you" page). Finishing then shows up as a page view, which the free plan does count.

Never put anything private in a page address (e.g., somebody's email address or name in the URL). The page address is what analytics records.

If you still see no data after ten minutes, the usual cause is that the code went live before analytics was enabled. Check that the Analytics page says it is enabled, then push one more commit (or ask Claude Code to redeploy) and visit the live site again. If that does not help, check that you visited the live URL and not a preview or your laptop. Some ad blockers also stop analytics from loading, so it is worth trying once in a browser that does not have one.

11b. A database (Supabase)

What this adds. Right now your product probably forgets everything when the page is refreshed. A database is where it keeps things, so that what a user typed yesterday is still there today.

You would need it when your product has to remember anything between visits (e.g., saved notes, a list of orders or a user's settings).

Step 1. Create the Supabase account. Go to supabase.com and click Start your project. Choose Continue with GitHub, which saves you making another password.

Step 2. Create a project. Click New project and give it your product's name. It will ask you for a database password. Let it generate one, and save it in your password manager. (You will rarely need it, and it is tedious to reset.) Pick the region nearest to you and click Create new project. It takes a minute or two to get ready.

Step 3. Find your two values. In the project, open Project Settings and then API Keys. You need two things from here: the Project URL, and the publishable key, which starts with sb_publishable_. (Older guides call this the anon key. It is the same idea.) Leave the secret key alone for now, and keep this browser tab open.

Step 4. Make a place for them on your laptop. The names of the two variables depend on how your project is built, so ask Claude Code to set them up. Paste this into Claude Code.

PROMPT

Copy
I am about to add a Supabase database. Create a file called .env.local
in this project if it does not exist. Add the names of the two variables
you will need, one for the Supabase project URL and one for the
publishable key, with nothing after the equals signs.

Check that .gitignore lists .env.local. Then tell me the two names.

Step 5. Paste the two values in yourself. Open .env.local with the command from "How keys work" above (open -e .env.local on a Mac, notepad .env.local on Windows). Paste the Project URL after the first equals sign and the publishable key after the second, then save and close the file.

Step 6. Give Vercel the same two values. Open vercel.com, click your project, then Settings, then Environment Variables. Add each one under exactly the same name that Claude gave you, and save.

Step 7. Write down what you store. Use the plain English data model from "Your data model" above. One or two sentences is enough, and you will paste them into the next prompt.

Step 8. Ask Claude Code to build it.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add a Supabase database to this project. I have created the Supabase
project and put the project URL and the publishable key in .env.local.
Tell me what you expect those two variables to be named, and stop if
they do not match.

Here is what the app needs to store, in plain English:
[for example: "Notes. Each note has a title, some text, and the date it
was written."]

Explain each table in plain English before you build anything. Give me
any SQL to run as one block I can paste into the Supabase SQL Editor,
and tell me exactly where to paste it.

Turn on row level security for every table, and explain in plain English
who can read and who can change each table.

Then connect the app so that it saves to and reads from the database.

When it works, add Supabase to the Stack section of CLAUDE.md.

Step 9. Run the SQL that Claude gives you. Claude will probably hand you a block of SQL, which is the language databases are set up in. In Supabase, open SQL Editor in the left-hand menu, paste the block in, and click Run. You do not need to understand the SQL, but please do read Claude's plain English explanation of it.

Step 10. Try it on your laptop. Add something in your app, and then refresh the page.

Step 11. Check it on the live site. Get the change into main, wait for Vercel to deploy, and do the same thing at your live URL.

You'll know it worked when you add something in your app, refresh the page, and it is still there, and when you open Table Editor in Supabase you can see the same thing sitting in a row.

Never put real people's private information in the database while you are testing. Use made-up names and entries.

If it works on your laptop and not on the live site, check that both variables are in Vercel under the same names.

One more check, which matters as soon as you add sign-in: row level security is the set of rules saying who may read which rows. A database without those rules will usually let any visitor read everything. 11e has the test for it.

11c. An AI feature (Google Gemini, free)

What this adds. Your product sends some text to an AI model and gets text back, so it can summarize a document, draft a reply or sort an entry into a category. "Calling an AI model from inside your app" above shows the same thing with the Claude API, which is billed by usage. Gemini is the free option for this course, because Google offers a free tier that is enough for a class project.

You would need it when an AI step sits at the center of what your product does, and you want it working without paying for each call.

Step 1. Open Google AI Studio. Go to aistudio.google.com/apikey and sign in with a Google account. (If your university account is refused, a personal Gmail account usually works.)

Step 2. Get your key. Accept the terms. For a new user, Google AI Studio creates a first key for you. If you do not see one, click Create API key. Copy the key, and keep this browser tab open.

Step 3. Make a place for the key on your laptop. Paste this into Claude Code.

PROMPT

Copy
Create a file called .env.local in this project if it does not exist.
Add a line that reads GEMINI_API_KEY= with nothing after the equals
sign. Check that .gitignore lists .env.local.

Step 4. Paste the key in yourself. Open .env.local with the command from "How keys work" above (open -e .env.local on a Mac, notepad .env.local on Windows). Paste your key straight after GEMINI_API_KEY=, then save and close the file.

Step 5. Give Vercel the same key. Open vercel.com, click your project, then Settings, then Environment Variables. Type GEMINI_API_KEY as the name, paste the same key, and save.

Step 6. Decide what the AI feature does, in one sentence. For example, "summarize the note the user just wrote in two sentences." You will paste that sentence into the next prompt.

Step 7. Ask Claude Code to build it.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

I want the app to [AI feature, for example: "summarize the note the user
just wrote in two sentences"].

Add a call to the Google Gemini API for this. Use the @google/genai
package and the model gemini-3.5-flash. My key is in .env.local as
GEMINI_API_KEY.

The key is secret. Make the call from code that runs on the server, never
from the browser, and explain to me in plain English where that code
lives and why the browser cannot see the key.

Add a sensible fallback message for when the API fails, is slow, or has
hit its free usage limit.

Explain each step as you go.

When it works, add Google Gemini to the Stack section of CLAUDE.md.

Step 8. Try it on your laptop. Use the feature in your browser and read what comes back.

Step 9. Break it on purpose. Change one character of the key in .env.local, restart the app, and try the feature again. You should see your fallback message and not a spinner that never stops. Please put the key back afterwards.

Step 10. Check it on the live site. Get the change into main, wait for Vercel to deploy, and use the feature at your live URL.

You'll know it worked when a sensible answer comes back on your laptop and on the live site, and the fallback message appeared when you broke the key in Step 9.

Never send real personal or confidential information through the free tier. Google states that content sent on the free tier may be used to improve its products, so use made-up or public text while you build. If your product will handle sensitive text for real users, that is a reason to move to a paid tier later, and worth a sentence in your pitch.

If it works on your laptop and not on the live site, the key is probably missing from Vercel. If it works for a while and then stops, you have probably reached the free tier's limit for the minute or the day, which is what the fallback message is for.

11d. Payments (Stripe, practice mode only)

What this adds. A real checkout page where somebody can press "pay." In this course you use Stripe's practice environment, where the cards are fake and no money moves. Stripe calls it a sandbox, and older screens and guides call it test mode. A checkout that works in the sandbox is built the same way as a real one, so it is enough to show at the demo and enough to learn whether people press the button.

You would need it when you are testing whether people would pay, and you want to watch them press the button and not only hear them say they would.

Step 1. Create the Stripe account. Go to stripe.com and create an account with your email address.

Step 2. Skip the activation. Stripe will invite you to "activate" your account by entering business and bank details. You do not need to. Skip it and stay in the sandbox.

Step 3. Check that you are in practice mode. The top of the dashboard should say Sandbox or Test mode.

Step 4. Find your two keys. Open Developers, then API keys. You need the publishable key, which starts with pk_test_, and the secret key, which starts with sk_test_. If either key starts with pk_live_ or sk_live_, you are in the wrong mode. Please stop and switch back. Keep this browser tab open.

Step 5. Make a place for them on your laptop. Paste this into Claude Code.

PROMPT

Copy
I am about to add Stripe Checkout. Create a file called .env.local in
this project if it does not exist. Add the names of the two variables
you will need, one for the Stripe publishable key and one for the Stripe
secret key, with nothing after the equals signs.

Check that .gitignore lists .env.local. Then tell me the two names.

Step 6. Paste the two keys in yourself. Open .env.local with the command from "How keys work" above (open -e .env.local on a Mac, notepad .env.local on Windows). Paste each key after its own equals sign, then save and close the file.

Step 7. Give Vercel the same two keys. Open vercel.com, click your project, then Settings, then Environment Variables. Add each one under exactly the same name that Claude gave you, and save.

Step 8. Ask Claude Code to build it. Fill in your product's name and price first.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add a payment step to this app using Stripe Checkout, the page that
Stripe hosts. I have put my Stripe sandbox publishable key and secret
key in .env.local. Tell me what you expect them to be named.

The product is [name] and it costs [price, for example $10, one time].

Use test keys only. Refuse to continue if either key starts with pk_live
or sk_live.

The secret key must only be used by code that runs on the server. Explain
in plain English what happens, step by step, from the moment the user
clicks "pay" to the moment they land back on our site.

Add a simple page for a successful payment and one for a cancelled
payment.

When it works, add Stripe (sandbox only) to the Stack section of
CLAUDE.md.

Step 9. Pay with the fake card. Click your pay button. On the Stripe page, type the card number 4242 4242 4242 4242, any expiry date in the future, and any three digits for the security code.

Step 10. Check it on the live site. Get the change into main, wait for Vercel to deploy, and pay with the fake card again at your live URL.

You'll know it worked when you click your pay button, arrive on a Stripe page, pay with the fake card, and land on your success page, and the payment appears in your Stripe dashboard under Payments.

Never type a real card number into your checkout, yours or anybody else's, and never switch the account to live mode during this course. Stripe's own terms prohibit testing with real card details.

If it works on your laptop and not on the live site, check that both keys are in Vercel. If the payment goes through and you are then sent to a page that will not load, the success page address is probably still pointing at your laptop. Ask Claude Code to make it use the live site's address.

11e. Sign-in (Supabase)

What this adds. Each user gets an account, and the product can show each person only their own things.

You would need it when your product needs to know who the user is, which is usually the moment two people's data would otherwise get mixed together.

Before you start, please finish 11b. The accounts live in the same Supabase project as your database, so there is no new account to create and no new key. Sign-in uses the same Project URL and publishable key you already added.

Step 1. Check that email sign-in is switched on. In your Supabase project, open Authentication and look for the list of sign-in methods (it is called Providers or Sign In / Providers). Email should already be switched on, and that is the one to start with.

Step 2. Ask Claude Code to build it.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add sign-in to the app using Supabase Auth. Email and password only for
now.

Explain in plain English what happens to a password, where the session
is stored, and what a user sees if they are not signed in.

Then update the row level security rules so that each signed-in user can
read and change only their own rows. Give me any SQL as one block for
the Supabase SQL Editor, and explain each rule in plain English.

When it works, add Supabase Auth to the Stack section of CLAUDE.md.

Step 3. Run the SQL that Claude gives you. In Supabase, open SQL Editor, paste the block in, and click Run, as you did in 11b.

Step 4. Make two accounts. In your app, create two accounts with two different email addresses.

Step 5. Run the two-account test. Sign in as the first account and add something. Sign out, sign in as the second, and look for it.

Step 6. Check it on the live site. Get the change into main, wait for Vercel to deploy, and run the two-account test again at your live URL.

You'll know it worked when the second account cannot see what the first account added. If it can, the rules are not doing their job, so tell Claude Code exactly what you saw and ask it to fix the rules and explain what was wrong.

Never skip that test. A product in which any user can read every other user's data is the mistake Part 14 warns you about, and it is much easier to catch now than after real people have signed up.

If it works on your laptop and not on the live site, the usual cause is that Supabase is still sending people back to your laptop after they confirm their email. In Supabase, open Authentication, then URL Configuration, and set the Site URL to your live Vercel address.

Try this once email sign-in works: ask Claude Code to add "Sign in with Google." It needs some extra setup on Google's side, and Claude can walk you through it one screen at a time.

11f. Email (Resend)

What this adds. Your product can send an email, such as a welcome message when somebody signs up or a note when something is ready.

You would need it when your product should tell the user something after they have left the page.

There is a limit you should know about before you choose this one. Until you own a web domain (an address such as yourproduct.com) and connect it to Resend, Resend will only deliver to the email address you signed up with. That is enough to build the feature and show a welcome email arriving in your own inbox at the demo. It is not enough to email your users.

Step 1. Create the Resend account. Go to resend.com and sign up. Use an email address you can open during class, because that is the only address your test emails will reach.

Step 2. Get your key. Open API Keys and click Create API Key. Copy it straight away, since Resend shows it only once.

Step 3. Make a place for the key on your laptop. Paste this into Claude Code.

PROMPT

Copy
Create a file called .env.local in this project if it does not exist.
Add a line that reads RESEND_API_KEY= with nothing after the equals
sign. Check that .gitignore lists .env.local.

Step 4. Paste the key in yourself. Open .env.local with the command from "How keys work" above (open -e .env.local on a Mac, notepad .env.local on Windows). Paste your key straight after RESEND_API_KEY=, then save and close the file.

Step 5. Give Vercel the same key. Open vercel.com, click your project, then Settings, then Environment Variables. Type RESEND_API_KEY as the name, paste the same key, and save.

Step 6. Ask Claude Code to build it. Fill in the three bracketed parts first: what triggers the email, what it says, and the address you signed up to Resend with.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add an email to this app using Resend. My key is in .env.local as
RESEND_API_KEY.

When [trigger, for example: "somebody submits the signup form"], send
[what, for example: "a short welcome email"].

I have not verified a domain, so send from onboarding@resend.dev and send
only to [the email address I signed up to Resend with]. Explain what
would need to change to email real users later.

The key is secret. Send the email from code that runs on the server, and
explain in plain English where that code lives.

If sending fails, the app should carry on working and should not show
the user an error.

When it works, add Resend to the Stack section of CLAUDE.md.

Step 7. Trigger the email on your laptop. Do whatever is meant to send it (e.g., submit the signup form), and then look in your inbox. Please check the spam folder too.

Step 8. Check it on the live site. Get the change into main, wait for Vercel to deploy, and trigger the email again at your live URL.

You'll know it worked when the email arrives in your inbox, and the Emails page in Resend lists it as delivered.

Never send email to people who have not asked for it. Unsolicited email annoys the people you most want to impress, and in many places it can break anti-spam laws.

If it works on your laptop and not on the live site, check that the key is in Vercel.

11g. File upload (Supabase)

What this adds. A user can give your product a file, such as a PDF or a photo, and the product keeps it.

You would need it when your product starts with something the user already has, such as their own document or photo.

Before you start, please finish 11b, because the files live in the same Supabase project as your database. There is no new account and no new key. It is safer with 11e as well, so that each file belongs to somebody.

Step 1. Make a bucket. In your Supabase project, open Storage and click New bucket. A bucket is a folder for uploaded files. Give it a plain name (e.g., uploads), and leave Public bucket switched off, so that files are private unless a rule says otherwise.

Step 2. Ask Claude Code to build it. Fill in the bracketed parts first: the bucket name, what users may upload, which file types, and the largest size.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add file upload to this app using Supabase Storage. I have created a
private bucket called [bucket name].

Users should be able to upload [what, for example: "one PDF or image"].
Accept only [file types] and refuse anything over [size, for example
5 MB], with a clear message.

Explain in plain English where the file goes, who is allowed to open it,
and what rule enforces that. Give me any SQL as one block for the
Supabase SQL Editor.

Show the user a list of what they have uploaded.

When it works, add Supabase Storage to the Stack section of CLAUDE.md.

Step 3. Run any SQL that Claude gives you. In Supabase, open SQL Editor, paste the block in, and click Run, as you did in 11b.

Step 4. Upload a harmless file. Use your app to upload something you would not mind a stranger reading, and then open the bucket in Supabase to see whether it arrived.

Step 5. Run the two-account test, if you have sign-in. This is the same test as in 11e. Upload a file as the first account, then sign in as the second and look for it.

Step 6. Check it on the live site. Get the change into main, wait for Vercel to deploy, and upload a file at your live URL.

You'll know it worked when you upload a file in your app and it appears in the bucket in Supabase. If you have sign-in, the second account should not be able to see or open the first account's file.

Never upload real identity documents, medical records or anything else you would not want a stranger to read while you are testing. Use a harmless file.

If it works on your laptop and not on the live site, check the two Supabase variables in Vercel, as in 11b.

Try this if you also did 11c: ask Claude Code to send the text of an uploaded PDF to Gemini and show a summary. That combination is the core of a good many AI products.

11h. Live outside data (Open-Meteo)

What this adds. Your product shows real, current information from somewhere else. The example here is the weather, from a free service called Open-Meteo, because it needs no account and no key, which makes it the gentlest way to see how one piece of software asks another for information.

You would need it when your product needs information it does not hold itself (e.g., the weather, a price or a map).

Step 1. See what your app will receive. There is no account to create and no key. Paste this address into your browser:

https://api.open-meteo.com/v1/forecast?latitude=32.99&longitude=-96.75&current=temperature_2m

You will get back a small block of text containing the current temperature near campus. That text is what an API returns, and your app's job is to turn it into something a person would want to read.

Step 2. Decide what to show, and where. For example, "today's temperature and chance of rain for Dallas, at the top of the home page." You will paste that into the next prompt.

Step 3. Ask Claude Code to build it.

PROMPT

Copy
Read CLAUDE.md and prd.md first.

Add live weather to this app using the Open-Meteo API, which needs no
API key.

Show [what, for example: "today's temperature and chance of rain"] for
[place], in [where on the page].

Explain in plain English what request the app sends, what comes back,
and how often it asks.

If the request fails or is slow, show a short, friendly message and keep
the rest of the page working.

When it works, add Open-Meteo to the Stack section of CLAUDE.md.

Step 4. Compare it with your phone. Open your app on your laptop and check the temperature against a weather app.

Step 5. Check it on the live site. Get the change into main, wait for Vercel to deploy, and look at the same page at your live URL.

You'll know it worked when your page shows a temperature that roughly matches a weather app on your phone, and it is still right when you check again tomorrow.

Never assume a free data service is free for every use. Open-Meteo is free for non-commercial use, which covers a course project. If your product needs different data (e.g., maps, prices or news), ask Claude Code to suggest a free API for it, and read that service's terms before you build on it.

If it works on your laptop and not on the live site, tell Claude Code what you see on the live page. With no key involved, the cause is usually something small in how the request is made.

Steering Claude Code: skills and hooks

By now you have told Claude the same things dozens of times. Explain it in plain English. Do not touch the payments code. Run through the demo checklist before we stop. Repeating yourself is not a discipline problem. It is a sign that the instruction belongs somewhere other than the conversation.

There are three places you can put a standing instruction, and the useful part is knowing which one fits.

Where	What it is	When Claude sees it	Use it for
CLAUDE.md	A file of standing facts	Every session, automatically	Things that are always true: your stack, your team's norms
A skill	A written procedure	Only when you call it	Steps you repeat: your pre-demo checklist
A hook	An automatic check on an action	Every time that action happens	Things that must never happen: committing a secret key

The rule of thumb, in three lines:

• A fact goes in CLAUDE.md.
• A procedure becomes a skill.
• A must-never becomes a hook.

(There is a fourth option you have already used without the name. When you send Claude off to do a big piece of research on its own, as in Part 7, that is a subagent. You do not need to set anything up for it.)

The difference between a skill and a hook is the one worth learning. A skill is instructions, and instructions can be forgotten in a long session. A hook is not an instruction. It runs whether Claude agrees with it or not. This is why "never commit the API key" in CLAUDE.md is weaker than it looks, and why Part 4 told you to put it here instead.

Try this once your product is real, which is roughly now. You do not write these files by hand. You ask.

PROMPT, to make a skill:

Copy
Create a skill called demo-check that runs through these steps: confirm
the app builds, confirm the live URL loads, confirm the signup flow works
end to end, and confirm no error messages appear in the browser console.

Explain what a skill is and where you are putting the file as you go.

PROMPT, to make a hook:

Copy
Add a hook that blocks any commit containing a file called .env or
.env.local. Explain exactly what it will do, and when it will fire,
before you add it.

You'll know the hook worked when you deliberately try to commit a file called .env.local and the commit is refused. Test it once on purpose. An untested guardrail is a guess.

Both of these live in a folder called .claude/ inside your project, and both get committed along with your code. That is the point for a team: a hook one person adds protects everybody from the next day onward, without anyone having to remember it. If you are wearing the integrator hat from Part 5, this is the highest-leverage five minutes available to you.

The full write-up is Anthropic's Steering Claude Code. Optional, written for programmers, and the comparison table near the top is worth the visit on its own.

---

Session 9, on 10/28.

When everyone can build, execution quality becomes the visible difference. Users decide whether your product is credible in well under a second, and mostly on how it looks and how clearly it speaks.

You do not need to be a designer. You need enough judgment to recognize bad and enough vocabulary to ask for better.

The five heuristics that matter for an MVP

Jakob Nielsen wrote ten usability heuristics. These five are the ones that will actually bite you.

1. Visibility of system status. The user should always know what is happening. If something takes two seconds, show that it is working.
2. User control. Let people undo things and go back. Nothing feels worse than an action you cannot reverse.
3. Error prevention. Stop the mistake before it happens rather than explaining it afterwards.
4. Recognition over recall. Show people their options. Do not make them remember what to type.
5. Help users recover from errors. An error message should say what happened and what to do next, in plain language.

Three ideas from Don Norman worth knowing

From The Design of Everyday Things, which is the foundational book on why objects confuse people.

• Affordance. The visual suggestion of what something does. A button that looks pressable affords pressing. A word that looks like plain text does not, even if it is a link.
• Feedback. Every action needs a visible response. If a user clicks and nothing changes, they will click again, and now you have two of everything.
• Mapping. The relationship between a control and its effect should be obvious. Controls that are near what they affect are easier than controls in a distant menu.

The empty state problem

Every product has a moment where a new user arrives and there is nothing there yet. No projects, no data, no history. Most student products show a blank screen at this moment, which reads as broken.

Design that screen deliberately. It should say what this is, what to do first, and ideally offer one button that does it.

Time to first value is the metric to think about here. How long from arriving to getting something useful? Every step you remove from that path is worth more than any feature you add.

Words are design

Button labels, error messages, and empty states are the interface. AI is genuinely excellent at drafting these, and you are the editor.

PROMPT

Copy
Rewrite every piece of text in this interface: buttons, error messages,
empty states, form labels, and confirmations.

Make each one clearer and friendlier. Use plain language. Show me
before and after side by side.

This is the cheapest quality upgrade available to you. It takes twenty minutes and it changes how the whole product feels.

The AI design critique loop

1. Take screenshots of every screen of your app.
2. Paste them into Claude, in Claude Code or at claude.ai:

PROMPT

Copy
Critique these screens against Nielsen's usability heuristics.

For each screen: what is confusing, what is missing (loading states,
empty states, error messages), and what violates visual hierarchy.

Also check accessibility basics: color contrast, font size, and whether
everything can be reached with a keyboard.

Then give me a prioritized top ten fix list, easiest first, phrased so
I can hand each item straight to Claude Code.

3. Hand the items to Claude Code one at a time. Not all ten at once.
4. Re-screenshot and run it again.

Try this for consistency: ask for a design system rather than styling things one at a time.

PROMPT

Copy
Define a small design system for this app: a color palette, a spacing
scale, and three text sizes. Then apply it consistently everywhere.

Ad hoc styling is why student projects look like four different products stitched together.

---

Session 9, on 10/28. Required for the MVP demo.

There are three separate things to test, and most teams only do the first one.

13.1 Does it break?

PROMPT

Copy
Act as a hostile QA tester on this app. Systematically try to break it:

- Empty inputs, absurdly long inputs, emoji, negative numbers, and
  SQL-looking strings in every field
- Double-clicking submit buttons
- Using the browser back button in the middle of a flow
- A brand new user with no data. What do the empty screens look like?
- A mobile-width screen
- What happens if the AI or API call fails, or takes 30 seconds?

For each issue: severity (breaks it / embarrasses us / cosmetic), how to
reproduce it, and the fix.

Write to qa-report.md. Then fix all the "breaks it" items one at a time,
re-testing after each fix.

Also do it by hand for fifteen minutes. You will find things the agent did not, and it will find things you did not. Both go in the report. The QA report is a required part of your MVP demo submission.

13.2 Is your AI feature any good?

This is the part almost everyone skips, and it is the part this course cares most about.

If your product calls an AI model, that feature can run without errors and still produce output that is wrong, useless, or embarrassing. Your QA test above will not catch it, because nothing crashed.

Do this:

1. Write down ten realistic inputs your users would actually give it. Not clean test cases. Real, messy ones.
2. Run all ten through your feature.
3. Grade each output yourself: good, acceptable, or bad.
4. For every bad one, work out why.

PROMPT

Copy
Here are ten real inputs to our [AI feature] and the outputs it produced:

[paste all ten pairs]

For each one, evaluate: is this output actually useful to our user?
Is anything in it factually wrong? Is the tone right?

Then identify patterns in the failures. What kind of input makes this
feature perform badly?

Suggest changes to the prompt we send, and tell me which failures a
prompt change will NOT fix.

That final clause matters. Some failures are prompt problems and some are "this is not something the model can do reliably." Knowing the difference is exactly the judgment this course is about. If your feature fails on a third of realistic inputs, the honest move is to narrow what it claims to do, not to keep tuning the prompt.

Put the result in your demo. A team that says "our summarizer works well on documents under two pages and degrades badly after that, so we cap it" is demonstrating more skill than a team that claims it always works.

13.3 Can a human use it?

Do this: each team runs at least three moderated user tests with real humans before the MVP demo on 11/4. The requirement is assigned at Session 8 on 10/21, so you have two weeks. Start early, because scheduling other people is the slow part. Send the messages before you have read this protocol, not after.

The protocol is simple and hard to follow:

1. Give them a task. "Sign up and create your first project."
2. Say nothing else. Nothing.
3. Watch where they stall, hesitate, or click the wrong thing.
4. Write down exactly what they said, especially when confused.

The hard part is the silence. Every instinct will tell you to help. Do not help. The moment you explain something is the moment you stop learning that it needed explaining.

Five users will surface about eighty five percent of your usability problems. Three is the minimum here because your timeline is short.

Their confusion outranks any AI opinion about your design.

13.4 Make Claude check its own work

The three tests above are things you do. This one is a check Claude runs on itself, every time, before it tells you it is finished. It is Rule 3 turned into something automatic instead of something you have to remember.

The name for this is a verification loop, and it is built out of the skills you met in Part 11.

Try this once the product is real. It is not required for the MVP demo, and it is the single thing on this page most likely to still be useful to you a year from now.

Here is how you find yours. It is four steps and none of them are technical.

1. Notice what you correct every single time. For most teams there are two or three. Claude says it is done and you find the error message is missing. Or the empty screen is blank. Or it committed something it should not have. Write them down for one week.

2. Write the check in plain English, the way you would brief a new teammate on their first day. Not "validate the form state." Something a person could follow.

3. Ask Claude to turn it into a skill.

PROMPT

Copy
I check the same four things by hand every time before we ship. Turn
them into a skill called verify-ship:

[paste your four things, in plain English]

For each one, tell me how you would actually check it, and say so if
there is one you cannot check without me looking.

Then run it on what we just built and report what it finds.

That second clause is the one that keeps it honest. Some things cannot be checked automatically, and you want to know which ones those are rather than assume they are covered.

Here is what a finished one looks like for this course. You do not type this in anywhere. It is what the file Claude creates should contain.

FILE: .claude/skills/verify-ship/SKILL.md

Before saying this work is finished, check all of the following and
report each one as pass or fail:

1. No API keys or secrets appear in any committed file.
2. Every form shows a visible error message when submission fails.
3. Every screen a brand new user sees has something on it, not a blank
   page or an empty list.
4. The app builds without errors.
5. The live URL loads and the core action can be completed.

Report the failures first, and do not fix anything until I say so.

Where you run it. Two ways, and start with the first.

Standalone. You call it yourself when it matters, usually before a merge or a demo. This is the version to build first, because you find out quickly whether it catches anything real.

Built in. Once you trust it, ask Claude to run the check at the end of a task automatically, so it fires whether you remember or not. This is the version that earns its keep, and it is only worth doing after the standalone version has caught something.

Now the honest part. A verification loop checks what you told it to check, and nothing else. Claude passing its own skill is Claude making a claim, which is the exact thing Rule 3 says is not evidence. This does not replace the hostile QA pass in 13.1, your fifteen minutes of clicking around by hand, or the three humans in 13.3. It replaces the part where you forget.

A team that builds one of these, has it catch a real problem, and writes that up is describing exactly the judgment this course grades. That is a build log entry.

Anthropic's write-up is Building verification loops in Claude Code with skills. Optional.

---

Session 9, on 10/28.

This is the week your product stops being a class project and starts being something real people use. Two things change.

14.1 Getting your first users

You already know how to do this from the probe phase. The difference is that now the thing works.

• Go back to everyone who signed up on your landing page. They asked to hear from you. Email them.
• Return to the communities where you found interest, and share what you built.
• Go back to your interviewees. They told you about the problem. Show them the solution.

Start with ten people who will actually use it, not a hundred who will look once.

14.2 You are now responsible for other people's data

The moment a real person types real information into your app, you have taken on obligations. This is not a legal course and nobody expects you to draft a privacy policy. You are expected to have thought about four questions.

What are you storing? List it. Names, emails, whatever they type into your product. If you are sending their input to an AI API, that is also a thing you are doing with their data.

Where does it live? Your Supabase database, and possibly Anthropic's or another provider's servers if you call an API. Know which.

Who can see it? Check this rather than assuming. A common and serious mistake is a database configured so that any user can read every other user's rows.

PROMPT

Copy
Review the database security rules for this app. Can any signed-in user
read or modify data belonging to another user? Show me exactly how the
rules prevent that, and test it.

Did they agree to it? If you are recording interviews, ask first. If you are storing user data, say so somewhere visible. If you are sending their input to a third-party AI service, that belongs in the same sentence.

A single honest paragraph on your site is enough for this course:

PROMPT

Copy
Write a short, plain-language note for our site explaining what data we
collect, where it is stored, that we send [specific input] to an AI
service to provide [feature], and how someone can ask us to delete their
data. Keep it under 150 words and avoid legal jargon.

Never collect more than you need. The safest data is the data you did not store.

14.3 Triage before demo day

You will have more broken things than time. Prioritizing is the skill.

Sort every known issue on two axes: how bad it is, and how long it takes to fix.

1. Breaks the core workflow. Fix immediately, whatever it costs.
2. Embarrassing but survivable, quick to fix. Fix it.
3. Embarrassing but survivable, slow to fix. Leave it and mention it in the demo.
4. Cosmetic. Leave it. Nobody is grading your button corners.

Deliberately leaving something broken is a legitimate decision when you say so out loud. The MVP demo rubric rewards documented failures over hidden ones. A team that says "we know the export function times out on large files, here is why, here is what we would do" scores better than a team that hopes nobody clicks export.

Write your triage decisions in your build log. That is exactly the kind of judgment the log exists to capture.

---

---

Session 10, on 11/4. This session is the assessment.

You get eight minutes. It is a live demo of the product, not a slide deck about the product.

The checklist

• Rehearse the happy path five times, out loud, with a timer
• Record a backup screen capture with Loom or QuickTime, in case the live demo dies
• Set up a fresh test account with realistic data. No "asdf test 123" on screen
• Narrate value, not technology. "Watch how Maria gets this done in thirty seconds," never "we used Next.js"
• One slide maximum before the demo: the problem and who has it. The product is the presentation
• Show your evidence: one slide of interview quotes, signups, and user test findings, and what you changed because of them
• Report what you measured, and say plainly what you could not measure yet
• End with what you would build next and why, grounded in user evidence
• Assign question topics to teammates in advance

Things that go wrong, and what to do

The live demo breaks. Switch to your backup recording and keep talking. You lose one point on the live criterion and nothing else. Panicking costs more than the bug.

You run out of time. This is the most common failure. It happens because teams show three features instead of one. Show the core workflow completely. Mention the rest in one sentence.

Someone asks a question you cannot answer. Say "I don't know, and here is how we would find out." That is a good answer. Bluffing is graded down, and experienced listeners can always tell.

What the rubric actually rewards

The core workflow running end to end in front of people. Evidence visibly shaping the product, which means you can say "we changed X because user Y did Z." Honesty about limitations. Command of the questions afterwards.

Polish is not on that list. Polish is nearly free now, so it is not what distinguishes you.

---

Sessions 11 and 12, on 11/11 and 11/18. Pitch Day is 12/2.

A demo shows the product works. A pitch argues the business works. They are different claims and they need different evidence.

What you are working toward:

	Graduate	Undergraduate
Pitch length on 12/2	8 minutes, then 4 minutes of questions	8 minutes, then 3 minutes of questions
Slides	10 maximum	8 maximum

Two dates sit around Pitch Day. A near-final deck is due 11/29 for written feedback. It is ungraded, and it only helps if the deck is genuinely near final. The full Venture Package is due 12/11, after you have pitched.

16.1 The narrative comes before the slides

Do not open your deck first. Write the story first.

The structure that works: name the change in the world, describe the stakes, show the promised land for your customer, then explain the thing you have that gets them there, and prove it.

AI ventures have an obvious change to name, which is exactly the problem. Every deck this year opens with "AI is transforming everything." Specificity is the only way out. Name the change in your industry, in the last eighteen months, with a date.

PROMPT

Copy
Here is our pitch narrative: [paste].

Rewrite it in this arc:
1. Name the undeniable change in the world, specific to our market
2. Stakes: who wins and who loses because of it
3. The promised land for our customer
4. Our "magic": what we have that gets them there
5. Proof

Keep OUR evidence and numbers exactly as given. Do not invent or inflate
anything. Ninety seconds spoken, maximum.

16.2 Market sizing that survives scrutiny

Bottom up, always. Number of customers times price. Show the source for the customer count.

If you are selling work rather than software, size the labor spend instead of the software spend. That is usually a much bigger number and it is the honest comparison, because that is the budget you are attacking.

Never write "one percent of a fifty billion dollar market." Experienced listeners stop reading at that slide.

16.3 The five questions

Every investor asks AI startups the same five things. Prepare all five before Pitch Day.

1. What is your moat when the model improves?
2. Why doesn't OpenAI or the incumbent just do this?
3. What are your inference costs at scale, and what does that do to margins?
4. Is this a feature or a company?
5. What proprietary data or workflow lock-in accrues over time?

Your Session 6 answer to "what if Anthropic ships this next quarter" is the raw material for question one and two. It becomes a slide.

16.4 Deck critique

PROMPT

Copy
You are a skeptical Series A investor who has seen 400 AI pitch decks
this year. Review my deck slide by slide [paste text or screenshots].

For each slide: what claim needs evidence, what a bored partner would
object to, and what to cut.

Be blunt. Then tell me the one slide that loses you, and why.

16.5 The murder board

PROMPT

Copy
Generate the 20 hardest questions an investor would ask this venture.
Cover: moat when models improve, why the incumbent doesn't do this,
inference costs and margins, feature versus company, go to market, and
team credibility.

Then interview me. One question at a time. Interrupt vague answers.
Follow up twice before moving on.

Grade each answer from 1 to 5 at the end.

Do this at least once before Pitch Day, and log it. It is a requirement, not a suggestion. The murder board at Session 12 gives you two live rounds; this is the third, and it is the one you can run at midnight.

The rule that does not change

AI polishes the story. The evidence must be real. Your deck is checked against your Discovery Report and your demo. Numbers that appear for the first time in the pitch will be asked about.

---

---

What is happening	What to do
An error message, anywhere	Paste the entire error into Claude Code: "Explain this in plain English, then fix it." Never retype or shorten an error.
The fix did not work twice in a row	"Stop. Do not patch again. Diagnose the root cause from scratch, list three hypotheses, and test them one at a time."
It worked before and is broken now	"Show me recent commits and revert to the last working one." Then try the feature again in smaller steps.
Claude seems confused or is going in circles	Long sessions degrade. Type /compact, or start a fresh session. CLAUDE.md means it re-reads what matters.
Claude says it is done but it is not	"Walk me through how to verify this myself in the browser, step by step." Then actually do it.
You do not understand what it changed	"Explain what you just changed as if to a smart non-programmer, in five sentences." Never let unexplained changes pile up.
The app is slow or the AI call takes forever	"Show me what is slow here and why. What is the cheapest fix?" Often you are sending far more text to the API than you need to.
Git says there is a merge conflict	Two of you edited the same lines. Use the prompt in Part 5, "When two people change the same thing," and decide with the other person. Never let Claude pick for you.
A teammate's work is missing from your copy	You have not pulled. "Pull the latest changes from GitHub." Nothing is lost; it is on main or still on their branch.
Your pull request has sat unmerged for days	Ask whoever has the integrator hat to review it. Anything you build on top of an unmerged branch gets harder to merge every day.
A commit is being refused	If your team added a hook (Part 11), it is doing its job. Read what it says before you consider turning it off.
You have been stuck 45 minutes	Post in the class channel: your goal, the error, and what you tried. Helping each other debug earns participation credit.

The one that catches everyone

If you find yourself sending increasingly frustrated messages to an AI, stop. Close the terminal. Go do something else for twenty minutes.

The pattern where you send the same request eight times with more emphasis each time has never worked for anyone. When two attempts have failed, the approach is wrong. Change the approach.

---

Acceptance criteria The "done means" line in your PRD. A description of what you would see with your own eyes if the feature worked.

Agent An AI model that can take actions in a loop, checking results and trying again. Claude Code is one. What makes it an agent rather than a chat window is that it has tools.

Analytics A counter on your live site that records how many people visited and which pages they opened. In this course it is Vercel Analytics, installed in 11a of Part 11.

API How one piece of software talks to another.

API key A password for an API. Treat it like a password, because it is one.

Backend The logic that does the work. The kitchen.

Barrier Whatever stops a competitor copying an advantage you have. Hamilton Helmer's test for a moat is a benefit plus a barrier, and the barrier is usually the harder half to find.

Beachhead The small, specific group of customers you set out to win completely before trying to win anybody else. For an AI product it is usually a workflow rather than a demographic.

Bottom-up market sizing Working out how big a market is by counting real customers and multiplying by a price you could defend. The opposite of "one percent of a fifty-billion-dollar market," which is a sentence rather than a number.

Branch Your own copy of the project to work in, so what you break is broken only for you. You merge it back when it works.

Brand Customers will pay more for your product than for an identical one, because of what they believe about you. It usually takes years to build.

Commit A save point in your project's history, stored on your own machine until you push it.

Complement Something that gets more valuable when a related thing gets cheaper, because the two get used together. Cheap flights made hotels more valuable. As intelligence gets cheap, the question worth asking is what its complements are.

Context window The AI's short-term memory. It is why long sessions get worse and why /compact helps.

Cornered resource Exclusive access, on good terms, to something valuable nobody else can get, such as a patent or a dataset. One of Helmer's seven powers.

Cost of goods sold (COGS) What it costs you to deliver your product to one more customer. For an AI product that includes every request to the model, which is why a heavy user can cost more than they pay.

Cost-plus pricing Working out what something costs you and adding a markup. Easy to calculate, and it tells you nothing about what the customer would actually pay.

Counter-positioning A new way of doing business that a bigger competitor could copy but will not, because copying it would hurt their existing revenue. One of Helmer's seven powers.

Customer acquisition cost (CAC) What you spend, on average, to win one new paying customer.

Database Where information is stored between visits. The pantry.

Deploy To put your app on the internet so other people can open it.

Distribution How a product reaches its customers. A company that already sells to millions of people can put a new product in front of all of them cheaply, which a newcomer cannot.

Dynamic pricing A price that changes with conditions, usually demand. Uber's surge pricing is the example most people have met.

Environment variable The safe place to keep API keys, outside your code.

Founder–market fit Whether you personally have access, experience, or credibility in the market you picked. Usually decided by whether you can get five of these people on the phone this week.

Freemium A free version that is useful on its own, plus a paid version some free users upgrade to. For an AI product every free user still costs you inference, so be careful how generous the free tier is.

Frontend What users see and click. The dining room.

Git The save-point system that runs on your own laptop. Keeps the history, lets you go back.

GitHub The website that holds a copy of that history. Where your repo link comes from. Not the same thing as git.

Gross margin What is left of each dollar of revenue after the cost of delivering the product, as a percentage. Charge $50, spend $20 delivering it, and your gross margin is 60%.

Hair-on-fire problem A problem somebody is already actively trying to solve, badly, right now. The clearest sign of one is a workaround.

Hallucination When AI confidently makes something up. The reason for every verification rule in this handbook.

Hook An automatic check that fires when something happens, whether the AI agrees with it or not. What you use when an instruction is not strong enough.

Horizontal product One tool sold to everybody, whatever industry they are in. A spreadsheet or a general chatbot. Compare vertical product.

Jevons paradox When something gets cheaper to use, total use of it often goes up rather than down, because it becomes worth using for things nobody would have bothered with before. Named after William Stanley Jevons, who noticed it about coal in 1865.

LLM Large language model. The AI itself.

localhost Your app running only on your own machine. Nobody else can see it.

Main The version of your team's project that works. It is what is deployed and what you hand in. Nobody edits it directly.

Merge Adding an approved branch into main. On a team, one person does this.

Merge conflict Two people changed the same lines and git will not guess which version wins. You decide, with the other person, out loud.

Moat Whatever makes it hard for somebody else to copy you and take your customers.

MVP Minimum viable product. The smallest thing that tests whether your idea is right.

Network effects The product gets more valuable to each user as more people use it. One of Helmer's seven powers.

Outcome-based pricing The customer pays only when the product achieves a defined result, such as a support ticket resolved without a human. How you define the result usually matters as much as the price.

Per-seat pricing A fixed price for each person who uses the product, usually per month. Awkward for AI products, because if the AI does the work of three people the customer needs fewer seats.

Plan mode A setting that makes Claude Code show you its plan and wait, instead of starting work straight away. Shift+Tab in the terminal, or the mode selector in the desktop app.

Positioning statement One sentence saying who the product is for, what problem it solves, and why it beats what they use today. "For [segment] who [problem], [product] is a [category] that [benefit], unlike [alternative], because [proof]."

PRD The one page describing what you are building, before you build it.

Price discrimination Charging different customers different prices for much the same thing. Student discounts, business tiers and volume deals are all ordinary examples.

Probe A deliberately disposable thing you build to think an idea through and to give other people something concrete to react to. Not a product, and not meant to survive.

Process power A way of working, built up over years, that competitors cannot copy even when they can see it. One of Helmer's seven powers, and rare in young companies.

Project memory A file in your project that Claude reads automatically at the start of every session, so you stop re-explaining the same things. Yours is called CLAUDE.md.

Prompt What you tell the AI.

Publishable key A key that is safe for visitors to see, because it can only do harmless things. Supabase and Stripe each give you one. Compare with a secret key.

Pull Bringing your teammates' merged work down onto your laptop. Do it before you start, every time.

Pull request Asking for your branch to be added to main, so a teammate can look before it goes in.

Push Sending your commits from your laptop up to GitHub. Committing is not pushing.

Repo Short for repository. Your project folder stored on GitHub. When an assignment asks for a repo link, it wants the GitHub web address.

Row level security The rules in a database saying who may read or change each row. Without them, a database will usually let any visitor read everything.

Sandbox A practice version of a service in which nothing is real. In Stripe's sandbox (also called test mode) the cards are fake and no money moves.

Scale economies Your cost per unit falls as you grow, so a smaller rival cannot match your price without losing money. One of Helmer's seven powers.

Secret key A key that must never be seen by visitors. It is only used by code that runs on the server, and it lives in .env.local and in Vercel's settings.

Seven Powers Hamilton Helmer's list of the advantages that can last: scale economies, network effects, counter-positioning, switching costs, brand, cornered resource, and process power. Each needs a benefit, which improves your cash flow, and a barrier, which stops competitors copying it.

Sherlocking When the platform you build on adds your product as a built-in feature. The risk every AI wrapper runs.

Skill A procedure you wrote down once so Claude can follow it on request instead of you explaining it again.

Slash command An instruction to Claude Code itself rather than a request to build something. /init, /compact, and /context are the three you need. Any skill you make adds one of its own.

Storage bucket A folder, kept by a service such as Supabase, for files that your users upload.

Subagent A helper Claude sends off on a side job with its own workspace. It reports back a summary rather than every step.

Substitute Something people buy instead of another thing. Tea is a substitute for coffee. When one gets cheaper, the other sells less.

Switching costs What a customer would lose by moving to a competitor, such as their data, their setup, or the time it took to learn your product. One of Helmer's seven powers.

Tool Something the AI can actually do rather than talk about: read one of your files, write a new one, run your app, search the web. Tools are what turn a chat window into an agent.

Two-sided marketplace A business serving two groups who need each other, such as Uber's riders and drivers. The hard question is which side to charge and which to make it cheap for.

Unit economics Whether you make or lose money on one customer, before counting the fixed costs of running the company. Price minus what that customer costs you to serve.

Usage-based pricing The customer pays for how much they use, counted in something like requests, credits or tokens.

Value chain Every company involved in getting a product to the customer, in order, and what each contributes. The useful question is who holds the scarce part.

Value-based pricing Setting the price from what the product is worth to the customer, such as the hours or money it saves them. This is where the ceiling on your price comes from.

Verification loop A check Claude runs on its own work before claiming it is finished. Useful, and still a claim.

Version control The general name for what git does: keeping a history you can move around in.

Vertical product One industry's workflow handled all the way down, and nobody else's. Software for personal-injury law firms, or for dental practices. Compare horizontal product.

Walking skeleton The thinnest end-to-end version of your product where the core action works, badly.

"Why now" The specific reason your idea could not have been built three years ago. For an AI venture it has to name a capability that crossed a threshold and roughly when. "AI is big" is not a why-now.

Willingness to pay What somebody would actually hand money over for, which is usually a much shorter list than what they say is a good idea.

Workaround The spreadsheet plus email plus group chat rig people build when no product exists. Nobody builds one for a problem they do not have, which is why it is the clearest signal in customer research.

Wrapper A product built on top of somebody else's AI model. The criticism is about how thin the layer on top is, rather than about using a model at all.

Anything not on this list, ask Claude. "Explain [term] to someone who has never written code" works every time.

---