Build a SaaS MVP with Cursor

Problem this prompt solves

Most Cursor sessions that start with “build my SaaS” produce a demo UI with no durable data model, weak auth boundaries, and an AI call wired straight from the client. You need a scaffold that is intentionally narrow — one primary workflow — but shaped like something you can ship to early users on Vercel without rewriting the foundations.

When to use it

• You have a validated idea (or a short PRD) and want Cursor to scaffold the first vertical slice, not a marketing site.
• You are starting greenfield on Next.js App Router + Supabase + Vercel and want consistent file layout from day one.
• You need auth, a core user-owned resource, and one AI-powered action wired through a server route before you polish UI.
• You want the agent to ask clarifying questions once, then implement — not invent a 12-feature roadmap.

You are helping me build a focused AI SaaS MVP. Stack: Next.js (App Router, TypeScript), Supabase (Auth + Postgres + RLS), Vercel deployment. Do not invent a large product — implement one primary user workflow end to end.

Before coding, ask only the questions you still need:
1) Product name and one-sentence value proposition
2) Primary user persona
3) The single core workflow (input → AI processing → saved output)
4) Whether email/password, magic link, or OAuth (Google) is preferred for auth
5) Any hard constraints (EU data residency, no client-side OpenAI keys, etc.)

Then implement a vertical slice with this structure:
- App Router layout with marketing landing (minimal), /login, /signup, /app (protected)
- Supabase clients: browser client, server client (cookies), and service-role client only for trusted server paths
- Auth: sign up, sign in, sign out, session refresh; protect /app with middleware
- Data model: a profiles table (id references auth.users) and one primary resource table owned by the user (e.g. projects or documents) with created_at, updated_at, and status
- RLS: users can only read/write their own rows; no anon write access to business tables
- Core AI action: a Route Handler or Server Action that validates the session, checks ownership, calls OpenAI with the server-side API key, stores the result, and returns a typed response
- UI: simple, accessible forms and a list/detail view for the primary resource — no design-system sprawl
- Env: document NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, OPENAI_API_KEY in .env.example
- README: local setup, Supabase migration/SQL to run, and Vercel env vars

Constraints:
- Never expose OpenAI or service-role keys to the client
- Prefer Server Components for reads; use client components only for interactive forms
- Keep the MVP scope ruthless: one resource type, one AI action, happy-path + basic error states
- After implementing, list manual test steps and known follow-ups (billing, rate limits, observability) without implementing them unless I ask

Expected result

A runnable Next.js app with Supabase auth, RLS-backed ownership for one core resource, a server-side OpenAI call that persists results, protected /app routes, .env.example, and a README that gets you from clone → local → Vercel without guessing the architecture.

Implementation notes

• Paste the prompt after you have a one-page PRD or answers to the five clarifying questions — Cursor produces tighter code when the workflow is named.
• Apply the SQL/RLS in the Supabase SQL editor (or as a migration) before testing auth-gated CRUD; empty tables with no policies look “broken” in the UI.
• Use the anon key in browser/server user clients and reserve the service role for admin/webhook paths only — never import service role into client bundles.
• Start with one model (e.g. gpt-4o-mini) and a hard max_tokens; optimise cost after the workflow works.
• Deploy to Vercel early with preview env vars so cookie/auth redirect URLs match your real domains.
• Resist adding teams, billing, or admin panels in the same Cursor session — ship the vertical slice first.

Testing checklist

• Sign up a new user and confirm a profiles row is created (trigger or upsert on first login).
• Create the primary resource while logged in; confirm it appears only for that user.
• Open the same resource URL in an incognito session — expect redirect to login, not a data leak.
• As a second user, attempt to read/update the first user’s row via the UI and via the API — both must fail under RLS.
• Run the AI action with a valid session and confirm the output is stored and reloaded on refresh.
• Unset OPENAI_API_KEY briefly and confirm the server returns a controlled error, not a stack trace to the client.
• Verify middleware blocks /app when the session is missing or expired.
• Deploy a Vercel preview and complete login + one AI action against the hosted URL.

Common mistakes

• Asking Cursor to “build the whole SaaS” — you get shallow screens and no ownership model.
• Calling OpenAI from a Client Component with a NEXT_PUBLIC_ key — keys leak and costs explode.
• Skipping RLS because “it’s just an MVP” — every table without policies is public to the anon key.
• Using only the service-role client for user CRUD — you bypass RLS and teach the app the wrong trust model.
• Shipping without .env.example and redirect URL docs — the next session (or teammate) cannot reproduce auth.
• Mixing marketing pages and app shell in one layout without a clear /app boundary — auth UX becomes inconsistent.