91  91. Project 3: Build Your Own App

Draft: not yet approved

This page is a draft for the instructor. The milestones, dates, deliverables and grading may change before the project is assigned.

In this final project you build a web app for your own business idea, from scratch, with Claude Code as your partner. You use the same architecture as the task app from Classes 10–12: Next.js, Supabase, GitHub and Vercel. In Project 2: Change the Task App’s Database you changed an app that already existed; now you design one yourself.

91.1 Goals

By the end, you will have turned a business idea into a short written spec, designed a small database with rules that keep each user’s data private, built and tested the app on your computer, put it online, and directed an AI coding agent through a real project while checking its work. The point is a small app that works, that you understand and can explain.

91.2 Choose and scope your idea

Pick a problem that a real small business, club or freelancer has. Then cut it down until it fits in a few weeks. A good project has:

  • one main workflow: the one thing a user comes to the app to do, from start to finish;
  • 2-3 tables of your own in the database (the user accounts come with Supabase);
  • one kind of user, who signs in and sees only their own data.

Some ideas that fit:

Idea Tables Main workflow
Booking for a hair salon services, appointments A customer picks a service and a time, and sees their upcoming appointments
Invoice tracker for a freelancer clients, invoices Add a client, create an invoice, mark it paid, see what’s still owed
Inventory for a small café items, stock_counts Record today’s count of each item, and see which items are running low
Resale tracker for a thrift seller items, sales Add an item with its cost, record the sale, see the profit per month
Dues for a student club members, payments Add members, record who paid, list who still owes dues

Signs that an idea is too big: two kinds of users (buyers and sellers), chat, maps, a phone app, real money, or several outside services. Keep those for “version 2” in your spec.

Start smaller than you think

Your first version is your MVP (minimum viable product): the smallest app that does the main workflow. Get it working and online first. Add extras only after that. See Putting It Together: Architecting a Web App with AI.

91.3 The starter template

As of Oct 16, 2026 · Official docs: Use Supabase with Next.js · The with-supabase example

You don’t start from an empty folder. Supabase and Next.js publish an official starter template: a small, working Next.js app that is already connected to Supabase, with sign-up, login and password-reset pages (email and password). Supabase’s guide creates it with:

npx create-next-app@latest my-app -e with-supabase
  • npx create-next-app@latest downloads and runs the newest version of Next.js’s app creator.
  • my-app is the name of the new folder for your app’s code. Use your app’s name, in lowercase with dashes, for example salon-booking.
  • -e with-supabase means “start from the example named with-supabase”.

The command also makes the folder a Git repository, with a first commit. The app needs two settings, which go in a file named .env.local: NEXT_PUBLIC_SUPABASE_URL (your project’s URL) and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY (your project’s publishable key). The template’s .gitignore already keeps .env.local out of Git. (Older guides call the key ..._ANON_KEY; see Environment Variables and .gitignore and Keeping Secrets Out of Git.)

Claude runs these commands for you, after asking your permission. The template changes over time, so the prompt below tells Claude to check Supabase’s guide first.

Next.js copies the value of every variable whose name starts with NEXT_PUBLIC_ into the JavaScript that it sends to the browser. Anyone can read it there. That is fine for the Supabase URL and the publishable key, because Row Level Security decides what that key may do. A secret key, such as an OpenAI or Stripe key, must never go in a NEXT_PUBLIC_ variable. It belongs only on a server: in a Supabase Edge Function’s secrets, as the task app does, or in a Vercel variable without the prefix. See APIs, API Keys, and Third-Party Services.

91.4 Start Claude Code with this prompt

As of Oct 16, 2026 · Official docs: Choose a permission mode · Model configuration · How Claude remembers your project

Work the same way as in Classes 10–12. Open a terminal (Git Bash on Windows) and type each command, pressing Enter after each one:

mkdir -p ~/projects/final-project
cd ~/projects/final-project
claude --permission-mode manual

In Manual mode, Claude asks before it runs each command or changes a file. In Claude’s chat box, type /model sonnet and press Enter: Sonnet handles this project and uses up your Pro plan’s limit more slowly than the default model (see Context, Models, Effort, and Usage in Claude Code).

Then paste the prompt for your computer. First replace the text in square brackets with your idea:

I'm on a Mac.

I'm a business student with no programming background, starting my course's
final project: a small web app for my own business idea, built from scratch.
We're in the folder ~/projects/final-project, which I just created.

My idea: [two or three sentences: who uses the app, what problem it solves,
and the one main thing they do in it].

The assignment, with its milestones and rules, is here. Read it first:
https://y-rosenthal.github.io/aiasd-in-progress/001310-assignment-buildYourOwnApp-v001.html

Use the same architecture as the task app from my class: Next.js for the web
pages, Supabase for the database and login, GitHub for the code, and Vercel
to put the app online. Start from the official starter template
(npx create-next-app@latest my-app -e with-supabase, with my app's name
instead of my-app), inside this folder. Check the current command and setup
steps in Supabase's guide before you use them:
https://supabase.com/docs/guides/getting-started/quickstarts/nextjs
Don't add Google sign-in, OpenAI or Stripe unless I ask for them later.

First, create two files in this folder (not inside the app's folder):
- CLAUDE.md, with the rules under "How to work with me" below, so you follow
  them in every session.
- checklist.md, a Markdown checklist ("- [ ]" for each item) of the five
  milestones on the assignment page and the steps for each, followed by a
  "Notes and issues" section and a "History" section. Update it as soon as
  each step is done: check its box, add the date, and add a line to History.

Then, before any code, help me write a short spec, docs/spec.md in the app's
folder: the problem and who has it, 3-5 user stories, the tables with their
columns and who may see each row, the pages, what is out of scope for now,
and how we'll test that it works. Ask me questions one at a time. Show me the
draft and wait for my approval before you build anything.

How to work with me:
- Do one step at a time. Before each command, tell me in a sentence or two
  what it does and why. Ask before anything that deletes files, changes my
  accounts, or costs money.
- When a step needs a website (GitHub, Supabase, Vercel) or installing a
  program, stop. Tell me exactly what to click and what to copy, and wait
  until I say I'm done.
- I paste secret keys into .env.local and into websites myself. Never ask me
  to paste a key into this chat, never open or print .env.local, never commit
  a key, and never put one in CLAUDE.md, checklist.md or any file Git tracks.
  Never put a secret key in a NEXT_PUBLIC_ variable.
- Change the database only with migration files in supabase/migrations,
  applied with the Supabase CLI; never change tables in the Supabase
  dashboard. Turn on Row Level Security for every table, with policies so
  each user sees and changes only their own rows.
- Build the smallest version that works first. Don't add anything that isn't
  in the spec without asking me.
- After each step, check that it worked. Test everything on my computer
  (npm run dev) before we deploy, and don't deploy until I say so. If
  something fails, explain the error in plain English, fix it with me, and
  note it in checklist.md.
- Commit after each step that works, with a clear message. Before each
  commit, run git status and check that no .env file is in it.
- Don't use Docker. We use a hosted Supabase project.
- Keep checklist.md up to date as we go, not just at the end.
I'm on Windows, and I use Git Bash.

I'm a business student with no programming background, starting my course's
final project: a small web app for my own business idea, built from scratch.
We're in the folder ~/projects/final-project, which I just created.

My idea: [two or three sentences: who uses the app, what problem it solves,
and the one main thing they do in it].

The assignment, with its milestones and rules, is here. Read it first:
https://y-rosenthal.github.io/aiasd-in-progress/001310-assignment-buildYourOwnApp-v001.html

Use the same architecture as the task app from my class: Next.js for the web
pages, Supabase for the database and login, GitHub for the code, and Vercel
to put the app online. Start from the official starter template
(npx create-next-app@latest my-app -e with-supabase, with my app's name
instead of my-app), inside this folder. Check the current command and setup
steps in Supabase's guide before you use them:
https://supabase.com/docs/guides/getting-started/quickstarts/nextjs
Don't add Google sign-in, OpenAI or Stripe unless I ask for them later.

First, create two files in this folder (not inside the app's folder):
- CLAUDE.md, with the rules under "How to work with me" below, so you follow
  them in every session.
- checklist.md, a Markdown checklist ("- [ ]" for each item) of the five
  milestones on the assignment page and the steps for each, followed by a
  "Notes and issues" section and a "History" section. Update it as soon as
  each step is done: check its box, add the date, and add a line to History.

Then, before any code, help me write a short spec, docs/spec.md in the app's
folder: the problem and who has it, 3-5 user stories, the tables with their
columns and who may see each row, the pages, what is out of scope for now,
and how we'll test that it works. Ask me questions one at a time. Show me the
draft and wait for my approval before you build anything.

How to work with me:
- Do one step at a time. Before each command, tell me in a sentence or two
  what it does and why. Ask before anything that deletes files, changes my
  accounts, or costs money.
- When a step needs a website (GitHub, Supabase, Vercel) or installing a
  program, stop. Tell me exactly what to click and what to copy, and wait
  until I say I'm done.
- I paste secret keys into .env.local and into websites myself. Never ask me
  to paste a key into this chat, never open or print .env.local, never commit
  a key, and never put one in CLAUDE.md, checklist.md or any file Git tracks.
  Never put a secret key in a NEXT_PUBLIC_ variable.
- Change the database only with migration files in supabase/migrations,
  applied with the Supabase CLI; never change tables in the Supabase
  dashboard. Turn on Row Level Security for every table, with policies so
  each user sees and changes only their own rows.
- Build the smallest version that works first. Don't add anything that isn't
  in the spec without asking me.
- After each step, check that it worked. Test everything on my computer
  (npm run dev) before we deploy, and don't deploy until I say so. If
  something fails, explain the error in plain English, fix it with me, and
  note it in checklist.md.
- Commit after each step that works, with a clear message. Before each
  commit, run git status and check that no .env file is in it.
- Don't use Docker. We use a hosted Supabase project.
- Keep checklist.md up to date as we go, not just at the end.
I'm on Linux.

I'm a business student with no programming background, starting my course's
final project: a small web app for my own business idea, built from scratch.
We're in the folder ~/projects/final-project, which I just created.

My idea: [two or three sentences: who uses the app, what problem it solves,
and the one main thing they do in it].

The assignment, with its milestones and rules, is here. Read it first:
https://y-rosenthal.github.io/aiasd-in-progress/001310-assignment-buildYourOwnApp-v001.html

Use the same architecture as the task app from my class: Next.js for the web
pages, Supabase for the database and login, GitHub for the code, and Vercel
to put the app online. Start from the official starter template
(npx create-next-app@latest my-app -e with-supabase, with my app's name
instead of my-app), inside this folder. Check the current command and setup
steps in Supabase's guide before you use them:
https://supabase.com/docs/guides/getting-started/quickstarts/nextjs
Don't add Google sign-in, OpenAI or Stripe unless I ask for them later.

First, create two files in this folder (not inside the app's folder):
- CLAUDE.md, with the rules under "How to work with me" below, so you follow
  them in every session.
- checklist.md, a Markdown checklist ("- [ ]" for each item) of the five
  milestones on the assignment page and the steps for each, followed by a
  "Notes and issues" section and a "History" section. Update it as soon as
  each step is done: check its box, add the date, and add a line to History.

Then, before any code, help me write a short spec, docs/spec.md in the app's
folder: the problem and who has it, 3-5 user stories, the tables with their
columns and who may see each row, the pages, what is out of scope for now,
and how we'll test that it works. Ask me questions one at a time. Show me the
draft and wait for my approval before you build anything.

How to work with me:
- Do one step at a time. Before each command, tell me in a sentence or two
  what it does and why. Ask before anything that deletes files, changes my
  accounts, or costs money.
- When a step needs a website (GitHub, Supabase, Vercel) or installing a
  program, stop. Tell me exactly what to click and what to copy, and wait
  until I say I'm done.
- I paste secret keys into .env.local and into websites myself. Never ask me
  to paste a key into this chat, never open or print .env.local, never commit
  a key, and never put one in CLAUDE.md, checklist.md or any file Git tracks.
  Never put a secret key in a NEXT_PUBLIC_ variable.
- Change the database only with migration files in supabase/migrations,
  applied with the Supabase CLI; never change tables in the Supabase
  dashboard. Turn on Row Level Security for every table, with policies so
  each user sees and changes only their own rows.
- Build the smallest version that works first. Don't add anything that isn't
  in the spec without asking me.
- After each step, check that it worked. Test everything on my computer
  (npm run dev) before we deploy, and don't deploy until I say so. If
  something fails, explain the error in plain English, fix it with me, and
  note it in checklist.md.
- Commit after each step that works, with a clear message. Before each
  commit, run git status and check that no .env file is in it.
- Don't use Docker. We use a hosted Supabase project.
- Keep checklist.md up to date as we go, not just at the end.

Your folders end up like this:

~/projects/final-project/
    CLAUDE.md          the working rules (never uploaded)
    checklist.md       your progress and notes (never uploaded)
    salon-booking/     your app: the Git repository you push to GitHub
        docs/spec.md
        supabase/migrations/
        README.md
        .env.local     your keys (Git ignores it)

Next time (a new session, or after /clear), start Claude in ~/projects/final-project the same way, type /model sonnet, and paste:

We're continuing my final project. Read checklist.md, docs/spec.md and the
assignment page, check that the finished steps still work, and continue with
the next unchecked step.

The usage tips from Classes 10–12 apply here too: use Sonnet, /clear between big steps, and check /usage (see Using Claude Code without running out of usage).

91.5 What the spec is for

A spec, or PRD (product requirements document), is a short description of what the app must do, written before the code. It is one or two pages, not a novel. It matters even more with an AI:

  • Claude reads it in every session, so it builds what you decided, not what it guesses.
  • When Claude suggests a feature that isn’t in the spec, you can say no.
  • Its “how we’ll test it” list tells you when you’re done.

If you change your mind, change the spec first, then the code. An example spec is in AI-Assisted Development: From Chatbots to Coding Agents.

91.6 Milestones

The instructor will announce the due dates.

Milestone What you do What’s due
1. Proposal and spec Choose and scope your idea. Write docs/spec.md with Claude. Create the app from the starter and run it on your computer. Push it to a new GitHub repository. A one-paragraph proposal (approved by the instructor before you build), the repository link, and the spec in it
2. Database and sign-in Create a Supabase project (the same settings as Classes 10–12, step (C)). Write migrations for your 2-3 tables, with RLS policies, and push them with the Supabase CLI. Check that sign-up and login work. Migrations in supabase/migrations, and a note in the README on how you tested that one user can’t see another user’s rows
3. Core feature Build the main workflow, end to end, on your computer. Test it with made-up data and at least two test accounts. The workflow working on localhost, with a commit for each working step
4. Deploy Put the app on Vercel, add the two NEXT_PUBLIC_ variables, and update Supabase’s Site URL and redirect URLs (Classes 10–12, step (K)). Test it again online with a new account. The live Vercel URL
5. Final demo Finish the README and write your reflection. Show the app in class. Everything in the next section, and a 3-5 minute demo

Test RLS on purpose: sign up as two users (one in a private browser window), add rows as each, and check that neither sees the other’s rows. RLS is explained in Step 9: Set Up Supabase Database.

Optional extras, only after milestone 4 works: “Sign in with Google” (Classes 10–12, step (D)), an AI feature with the OpenAI API (Step E, with the same $5 limit), or payments with Stripe in test mode (Step F). Add each one to your spec first.

91.7 Deliverables

Submit these by the final deadline:

  1. The GitHub repository link. The instructor must be able to see it (make it public, or add the instructor as a collaborator).
  2. The live Vercel URL, with a test account the instructor can use (a made-up email and password, written in your submission, not in the repository).
  3. README.md, replacing the starter’s README: what the app does and for whom, the live URL, the tables, how to run it, and how you tested it.
  4. docs/spec.md, updated to match what you built.
  5. docs/reflection.md (400-600 words, in your own words): how you worked with Claude, one thing the AI got wrong and how you noticed and fixed it, and what you would do differently.

91.8 Grading

Part Weight
Spec: clear problem, users, user stories, scope, tests 10%
Database: sensible tables, migrations, RLS policies that work 20%
Core workflow works, locally and online 25%
Deployment on Vercel, with the right settings 10%
Security: no secrets in the repository or in NEXT_PUBLIC_ variables, only made-up data 10%
Git history (small commits with clear messages) and README 10%
Reflection, including what the AI got wrong 10%
Final demo: you can explain how your app works 5%
Total 100%

91.9 Rules

  • AI use is expected. Use Claude Code for code, commands and explanations.
  • You are responsible for the code. You approve every change, so be ready to explain any part of your app in the demo.
  • No real secrets in the repository. Keys go in .env.local and on the websites only. If a key ever reaches GitHub, tell the instructor and create a new key right away: deleting the file doesn’t remove it from Git’s history.
  • No real customer data. Use made-up names, emails and numbers, even if your idea comes from a real business.
  • Stay on free plans. The free Supabase plan allows only a few active projects, so you may have to pause your task-app project.

91.10 Key takeaways

  • Small and working beats big and broken: one workflow, 2-3 tables, one kind of user.
  • Write the spec first. It keeps you and Claude building the same thing.
  • Every table gets RLS, and you test it with two accounts.
  • Secret keys never go in the chat, in Git, or in a NEXT_PUBLIC_ variable.
  • Test on your computer first, then deploy, then test again online.

Practice Questions

Easy

Question 1 · Short answer

What is a spec (PRD), and name three things that go in this project’s spec.

A spec, or product requirements document, is a short description of what the app must do, written before the code. Any three of: the problem and who has it; 3-5 user stories; the tables, their columns and who may see each row; the pages; what is out of scope for now; how you’ll test that it works.

Question 2 · Multiple choice

Which project idea is best scoped for this assignment?

  1. A marketplace where landlords list apartments and students message them
  2. A tracker where a freelancer adds clients, creates invoices and marks them paid
  3. A phone app that shows nearby food trucks on a map
  4. A store that takes real credit-card payments for three different kinds of users

b. It has one kind of user, one main workflow and two tables (clients, invoices). The marketplace (a) has two kinds of users and messaging; the food-truck app (c) is a phone app with maps; the store (d) has real money and several kinds of users. All three are signs the idea is too big.

Question 3 · True or false

Because the starter template’s .gitignore excludes .env.local, it’s fine to paste your keys into Claude’s chat box so Claude can fill in the file.

False. .gitignore only keeps the file out of Git. Anything you paste into the chat becomes part of the conversation, which is sent to Anthropic’s servers and saved in the session history. You paste keys into .env.local yourself; Claude only tells you where they go.

Question 4 · Matching

Match each file to its job.

File Job
1. CLAUDE.md A. Your app’s keys, on your computer only
2. checklist.md B. What the app must do, agreed before coding
3. docs/spec.md C. The working rules Claude reads at the start of every session
4. .env.local D. Your progress, notes on problems, and history

1 → C, 2 → D, 3 → B, 4 → A.

Medium

Question 5 · Short answer

What does each part of npx create-next-app@latest salon-booking -e with-supabase do?

npx create-next-app@latest downloads and runs the newest version of Next.js’s app creator. salon-booking is the name of the new folder for the app’s code. -e with-supabase starts from the official example named with-supabase, which is already connected to Supabase and has sign-up and login pages. The command also makes the folder a Git repository with a first commit.

Question 6 · Scenario

Maria’s app needs an OpenAI key. Claude suggests adding NEXT_PUBLIC_OPENAI_KEY to Vercel. What should she say, and why?

No. Next.js copies every NEXT_PUBLIC_ variable into the JavaScript it sends to the browser, where anyone can read it, and an OpenAI key can cost her money. A secret key belongs only on a server: in a Supabase Edge Function’s secrets (as the task app does) or in a Vercel variable without the NEXT_PUBLIC_ prefix. The prompt’s rule “never put a secret key in a NEXT_PUBLIC_ variable” covers this.

Question 7 · Scenario

Sam’s café app has a stock_counts table. How should he test that its RLS policies work?

Sign up as two different test users, for example one in a normal window and one in a private window. Add rows as each user, then check that each user sees only their own rows and can’t change the other’s. A good answer also says he uses made-up data, and writes down in the README how he tested it.

Question 8 · Multiple choice

Halfway through, Sam wants to add a new column to his appointments table. What should he do?

  1. Add the column in the Supabase dashboard’s Table Editor
  2. Ask Claude to change the table directly in the database
  3. Update the spec, then have Claude write a new migration and apply it with the Supabase CLI
  4. Delete the Supabase project and start over

c. The spec should match what he builds, and every database change goes through a migration file, so the change is recorded in Git and can be applied again. Changing tables in the dashboard (a) or directly (b) bypasses the migrations, so the files no longer describe the real database. Starting over (d) is unnecessary.

Hard

Question 9 · Long answer

Why does the project require you to test on your computer before deploying to Vercel, and to test again after deploying?

On your computer (npm run dev), changes show up in seconds, errors appear in your terminal where Claude can read them, and nobody else sees a broken app. Fixing a problem there is faster and cheaper than on a live site. Deploying adds new things that can go wrong: Vercel’s environment variables, Supabase’s Site URL and redirect URLs, and the production build. So you test again online, with a new account, to catch problems that exist only there. A good answer separates “does my code work?” from “is the online setup right?”

Question 10 · Scenario

Maria’s spec says “users can book appointments”. In the middle of milestone 3, Claude offers to add reminder emails, a loyalty-points system and an admin dashboard “to make the app more complete”. What should she do, and how does the spec help?

Say no for now, and ask Claude to finish the main workflow. The spec defines what she agreed to build, and those features aren’t in it, so they would add work, new bugs and usage before her MVP works. If she wants one later, she adds it to the spec first (perhaps under “version 2”), after milestone 4. Her prompt also tells Claude not to add anything that isn’t in the spec without asking.

Question 11 · Scenario

Sam notices that a commit he pushed to GitHub yesterday contains his .env file with a Supabase secret key. He deletes the file and pushes again. Is the problem solved? What should he do?

No. Deleting the file creates a new commit, but the old commit, with the key in it, is still in the repository’s history on GitHub, where anyone who can see the repository can find it. He should create a new secret key in Supabase right away so the old one stops working, tell the instructor, and make sure .gitignore excludes the file. To prevent it, check git status before every commit, as the prompt tells Claude to do.

Question 12 · Long answer

The rules say “You are responsible for the code.” Why does that matter when an AI wrote most of it, and what habits from this page help you meet it?

The AI can make mistakes: wrong commands, missing RLS policies, a key in the wrong place, features nobody asked for. You approved each change, you publish the app, and its users trust you with their data, so the mistakes are yours. Habits that help: Manual mode, reading each command before you approve it; asking Claude to explain each step; a spec that you can check the app against; migrations and RLS tests; testing locally and online; small commits that are easy to undo; and the reflection, which makes you notice what the AI got wrong.

© 2025-2026 Y. Rosenthal. All rights reserved.