Build a SaaS MVP in a Week with Claude Code

What you're building

You're shipping a single-purpose SaaS app that solves one painful problem for one type of person. Not a platform. Not a suite. One workflow that someone will pay nine, nineteen, or forty-nine dollars a month to keep using. Think transcript cleanup for podcasters, weekly client reports for freelance designers, or a niche CRM for dog trainers. The narrower the audience, the faster you ship and the easier you sell. A wide product needs marketing to find users. A narrow product can be sold one DM at a time, which is the only sales channel that works on day one.

By the end of the week you'll have a working web app with email and password auth, a Postgres database, a Stripe subscription, a paid dashboard, and a public landing page on a real domain. You'll have written the spec in plain English, let Claude Code generate most of the code, reviewed each commit, and pushed to production through Vercel. The output is not a prototype. It's a thing your first customer can actually use, with real billing and real data, deployed to a URL you can put in your Twitter bio without flinching.

The week is achievable because the boilerplate is now a five-minute generation. What remains are decisions: what to build, who it's for, what to charge, which corners to cut. Your job is to make those quickly and let Claude turn each into code.

What you need before you start

You need a Claude account with Claude Code installed, a GitHub account, a Vercel account, a Supabase project, and a Stripe account in test mode. You need a domain you already own or one you can buy on day one. You need to be comfortable reading TypeScript even if you can't write it from scratch. You don't need to know React deeply. You don't need to know SQL. Claude will write both, but you have to be able to spot when something looks off, because the model occasionally invents a function name or imports a package that doesn't exist.

Mentally, you need a specific user in your head. When you can't decide between two features, you ask which one that user opens the app to do. The answer is usually obvious. If it isn't, the person isn't sharp enough yet, and the right move is to talk to three potential customers before writing more code.

• Claude Code installed and authenticated on your laptop
• Node 20 or later, pnpm or npm, and Git configured
• A blank GitHub repo connected to Vercel
• A Supabase project with the connection string handy
• A Stripe test key and one product with a monthly price
• A one-sentence description of the problem you're solving

Day one: the spec and the skeleton

Open Claude Code in an empty folder and describe the product in five sentences. Tell it the user persona, the single workflow, the data model in plain English, and the pricing. Ask Claude to scaffold a Next.js 15 app with the App Router, Tailwind, and shadcn/ui. Let it install dependencies. The first commit should be a homepage with your headline, a pricing section, and a login button. Do not skip the homepage. Customers land there before they land in the product, and a landing page that looks half done shrinks conversion before any feature ships.

Once the skeleton runs, ask Claude to add a SPEC.md file at the repo root with the user stories, data model, and route map. This file becomes the source of truth Claude reads at the start of every session. When you forget what you decided on Tuesday, this is where you look. The club at claudecodeclub.ai has a public starter SPEC template you can crib from on day one. Update SPEC.md every time a decision changes, before you change the code, so the document stays ahead of the codebase rather than behind it.

Day one also includes the small design decision that pays back every other day: pick one accent color, one heading font, one body font, and a spacing scale. Put them in tailwind.config.ts so every component Claude generates uses them. The product looks intentional from screenshot one.

Day two and three: auth and the database

Use supabase-js for auth and the database. Ask Claude to wire up email and password sign-in with a confirmation flow and a forgot-password page. Have it generate the SQL migration for your core tables and run it through the Supabase SQL editor. Pick uuid primary keys, add created_at and updated_at columns by default, and enable row-level security on every table from the first migration. Skipping RLS now means a security audit later, and that audit is the kind of work that derails an entire week when you should be talking to customers.

Build the dashboard shell next. A sidebar, a top bar with the user's email, and one empty page per route. Wire up the data fetching with server components and a typed Supabase client. Test the auth round-trip: sign up, log out, log back in, hit a protected route while signed out, get redirected. If any of those fail, fix them before moving on. Auth bugs found on day two are five minutes to fix. Auth bugs found on day six are a four-hour rabbit hole because they sit underneath every other feature you've built.

Add a Postgres trigger that creates a profile row when a new auth user signs up. The trigger saves a whole category of bugs later, because every other table can join to a guaranteed profile row. Write the trigger as part of the same migration as the users table.

Day four: the core workflow

This is the only part of the app that matters. Pick the one user action that defines the product, the thing they'll do every week, and build it end to end. Form, server action, database write, result view. Nothing else. No settings page, no team management, no analytics dashboard. If a feature isn't on the critical path to the user's first 'oh that's useful' moment, cut it. The features you cut are not gone forever, they're just not in v1, and the conversation you have with your first customer will tell you which one to add first.

Spend the morning on the form and the validation, the afternoon on the server action and the database write, and the evening on the result view. Wire the loading state, the empty state, the error state, and the success state for the single workflow before you call it done. Forty percent of an MVP's perceived quality comes from those four states being handled gracefully on the one feature that matters. The rest of the app can be a little rough because the user spends ninety percent of their time on this one screen.

Choices to make along the way

Supabase versus Neon versus Planetscale: Supabase gives you auth, storage, and Postgres in one console, which is why it wins for week-one MVPs. Neon is faster if you already know how to wire auth yourself. Planetscale is overkill until you have real traffic. Stripe versus Lemon Squeezy versus Polar: Stripe is the boring correct answer in most countries. Lemon Squeezy handles VAT and sales tax for you, which matters more than you think if you're selling internationally on day one.

Next.js versus Remix versus a Vite SPA with Hono: Next.js plus Vercel is the lowest-friction path to a deployed app. Remix is cleaner conceptually but has fewer one-click integrations. A Vite SPA with a Hono backend is faster to run locally but you'll spend a day on deploy config. Pick Next.js unless you have a specific reason not to.

Day five: billing and the paywall

Stripe Checkout for the upgrade flow, Stripe Customer Portal for cancellations and card changes, and a webhook that writes the subscription status to a subscriptions table. Ask Claude to scaffold all three. Test the webhook with the Stripe CLI before you deploy. Then add a middleware check that gates your one core route behind an active subscription. Free trial or no free trial is a marketing question, not a code question. Ship without one for week one and add it later if conversion is bad.

The webhook is where most billing systems break, because it runs in a different lifecycle from the rest of the app and errors are silent unless you watch for them. Have Claude write the handler with idempotency built in, keyed on the Stripe event id, so a webhook retry never double-applies a subscription change. Log every event to a webhook_events table with the raw payload and the result. When a customer says their subscription didn't activate, you have one place to look.

Day six: ship it

Push to GitHub, connect to Vercel, set every environment variable, and deploy. Point your domain at Vercel. Set the production Stripe key. Run through the full flow on the live site: sign up, pay, use the product, cancel, sign up again. Find the broken thing because there will be one broken thing. Fix it. Push again. The club at claudecodeclub.ai costs nine dollars a month and includes a deploy-day checklist that catches the things you'd otherwise miss on a Saturday at 11pm.

How to test it

Don't write a test suite this week. Write a manual test script in TESTING.md with the ten flows that have to work: sign up, log in, password reset, paid checkout, downgrade, the core workflow happy path, the core workflow with bad input, logged-out access to protected routes, webhook delivery, and a dashboard refresh. Run the script before every deploy. After launch, write Playwright tests for the two flows that broke in production. That's the right time to invest in automation, when you know exactly which flows are fragile in the real world rather than guessing up front.

Do not let Claude generate a test suite proactively in week one. It will produce dozens of unit tests that mock the database and assert nothing meaningful, and you'll spend Friday afternoon deleting them. Tests that test the mock are worse than no tests at all because they make you think you have coverage when you don't. Save automation for after the product has users.

How to extend it

Once you have a paying user, the next features write themselves. They'll tell you. Resist building anything they didn't ask for. The natural extensions are usually a second core workflow, a Slack or email notification, an API key for power users, and a basic team feature. Do them one at a time. Each should ship in a day or two with Claude Code now that the foundation is in place.

Common gotchas

Forgetting row-level security on Supabase tables is the biggest one. Forgetting to set the Stripe webhook signing secret in production is the second. Letting Claude install three different state libraries in the first week is the third. Pick one approach for forms, one for data fetching, one for styling, and tell Claude in your SPEC.md to stick to them. Otherwise you'll spend day seven untangling a Frankenstein of zustand, jotai, and TanStack Query glued together with useState calls.

Another quiet gotcha is environment variables that work locally and silently fall back to defaults in production. Use t3-env or zod to fail loudly on startup when a required variable is missing. A loud failure at deploy time beats a silent fallback that routes real payments to a test Stripe account for two days before anyone notices.

The other gotcha is scope. A week is enough to ship a real product if the product is small. It is not enough to ship two products glued together. If you find yourself on Thursday adding a second workflow because the first one feels too thin, that's the moment to stop adding and start selling.