Build an MVP with Claude Code: Idea to Deployed App in a Weekend

A weekend MVP with Claude Code is realistic for a non-developer, but not because the tool is magic. It is realistic because you do the three things a chat builder normally does for you: fix the scope in writing, choose a stack the agent already knows cold, and make it prove each piece works before you move on. This is the plan I use, in the order I use it. If you have never opened Claude Code, start with the non-developer's guide to Claude Code and come back.

Friday night: the one-page spec

Do not open a terminal yet. Open a blank document called SPEC.md and answer five questions in plain language:

1. Who is this for, in one sentence?
2. What one job does it do? (If you wrote "and", cut the second half.)
3. Which three screens does it need? Name them and say what is on each.
4. What does it store? List the nouns: users, listings, bookings. One line each with the fields you actually need.
5. What does "working" look like? Three or four sentences a stranger could check. "A new user can sign up, create a listing with a photo, and see it on the home page."

This is spec-driven development at its smallest useful size. The spec is where you fix mistakes cheaply: changing a sentence costs a minute, changing a built feature costs an hour of credits and confusion. If the scope keeps growing, the MVP scope cutter skill or the /scope-mvp command will argue you back down to one job.

Add one more section to the spec, Stack, and write exactly what is in the next step. Claude follows a written stack decision; it drifts when you leave it open.

Pick the stack Claude Code handles well

You want the boring combination, because boring means Claude has seen it thousands of times and guesses right:

If you have already prototyped in a builder like Lovable, its output uses the same Supabase-shaped backend, which is why the handoff to Claude Code works. If you are still deciding between a builder and an agent, Lovable vs Claude Code is the short version.

Saturday morning: scaffold and write CLAUDE.md

Install Claude Code (the install guide is ten minutes), create an empty folder, put SPEC.md in it, and start a session there. Your first prompt is not "build my app". It is:

Read SPEC.md. Scaffold a Next.js + TypeScript + Tailwind project that matches it.
Do not add auth or a database yet. When it runs locally, tell me the command to
start it and stop.

In its Manual permission mode, Claude Code asks before it runs commands or edits files, so you will approve the scaffold step by step (check the mode indicator in the session; if it says Auto, switch to Manual for your first weekend). Say yes; read what it is doing. Once the dev server runs, type /init. Claude Code writes a starting CLAUDE.md, the file it reads at the beginning of every session. Then edit it so it looks something like this:

# Project: Roomshare
 
## What this is
A booking board for a shared studio. The spec is in SPEC.md; read it before
changing any behavior, and ask me if the spec is ambiguous.
 
## Commands
- `npm run dev` starts the app locally
- `npm test` runs the tests; run it before you tell me a task is done
- `npm run build` must pass before anything is deployed
 
## Working with me
- I am not a developer. After each change, explain what changed in plain
  language and tell me exactly what to click to check it.
- Ask before adding a new dependency, service, or paid API.
- One feature per session. Do not refactor things I did not ask about.
 
## Safety rules
- Never put API keys or secrets in code. Use `.env.local` and tell me which
  variable to set. Never commit `.env.local`.
- Every Supabase table must have Row Level Security enabled with a policy
  before it holds real data.
- Never run `git push` or deploy without asking me first.

Keep it under 200 lines; Anthropic's docs say longer files reduce how reliably Claude follows them. The two rules that matter most for a non-developer are "explain what you changed" and "ask before adding a dependency", because those are the two places an unsupervised agent creates work you cannot see. CLAUDE.md best practices goes deeper if you want the reasoning.

Saturday: build in slices, with evidence

Work through the spec one screen at a time. The prompt pattern is the same each time:

Implement the "create listing" screen from SPEC.md. Write a test for the form
validation first, then make it pass. When done, show me the test output and
tell me the URL to open.

The important word is show. Claude Code will sometimes say "done" when it means "I wrote code that I believe works". Require the evidence: test output, a running server, a screenshot if the desktop app is showing you one. This is the whole discipline of testing AI-generated code compressed into one habit, and it is what separates a weekend that ends with a demo from one that ends with a folder of half-working screens.

When something breaks, paste the error and the words "what changed since it last worked?" before "fix it". The first question makes Claude read its own diff; the second makes it guess.

Saturday afternoon: auth and data with Supabase

Create a Supabase project in the browser and copy the project URL and the public (anon) key into .env.local. Then give Claude Code eyes on the database by adding the Supabase MCP server:

claude mcp add --scope project --transport http supabase "https://mcp.supabase.com/mcp"

Run /mcp in the session to authenticate. Supabase's own docs recommend scoping the server to one project and using read-only mode for anything unattended; for a weekend build on a fresh project, project scoping is enough, but do not point it at anything holding real customer data.

Now the prompt:

Add Supabase auth (email + password) and the tables from SPEC.md. Write the
schema as a migration I can read. Enable Row Level Security on every table and
write policies so a user can only read and write their own rows. Explain each
policy in one sentence.

Row Level Security is the one line you cannot skip. Supabase's guidance is blunt: enable RLS on every table in an exposed schema, because a table without it is readable and writable by any role with a grant on it, and your public key is in the browser. Ask Claude to explain each policy in a sentence, and if you cannot follow the sentence, ask again until you can. You are the last reviewer.

Sunday: deploy

Push the repository to GitHub (ask Claude to set up the remote and the first push; it will ask before pushing if you set the rule above). Then import the repo into Vercel. Vercel builds a deployment on every branch push and turns merges to the production branch (main by default) into the live site, with every other branch getting its own preview URL. Add your Supabase URL and anon key as environment variables in the Vercel project settings; never upload the .env.local file.

If you built inside Replit with Replit Agent instead, the equivalent is a Replit deployment: Autoscale for a normal web app, Static for a site with no server, and the platform hosts it for you. Either way, the first deploy is a preview you click through, not the URL you send to customers.

Sunday evening: check before sharing

Five checks, ten minutes, in this order:

1. Logged out. Open the live URL in a private window. Every private page should redirect to sign-in.
2. Second user. Sign up with a second email. Create data. Confirm the first account cannot see it, and vice versa. This is your RLS test.
3. Secrets. Ask Claude: "Search the repository and the built output for anything that looks like a key or token. List every hit." The anon key is expected; a service-role key anywhere in the app is a stop-the-launch finding.
4. Build. npm run build passes locally and the Vercel deploy is green.
5. Phone. Open the three core screens on your phone. Fix the one that is broken (there is always one).

Then send the link to five people, not five hundred. The best next step after the first feedback is usually the technical cofounder agent reviewing the repo for what will hurt at month three, and the wider field of tools worth adding is in the best AI tools for founders. What you have at the end of the weekend is a real repository, a real database, and a real URL, which is the point: it can grow instead of being rebuilt.