Cursor Prompts for Building a Complete SaaS MVP

Cursor is most useful when you stop asking it to “build my SaaS” and start giving it session-sized jobs with stack constraints, acceptance criteria, and explicit non-goals. This article is a playbook for sequencing prompts from the Cursor prompt library so you end up with a complete-enough AI SaaS MVP — not a pile of disconnected demos.

Pair this with the longer build guide: How to Build an AI SaaS MVP with Cursor.

Principles before prompts

One outcome per session. “Add Supabase auth with protected routes and a profiles row” beats “set up the backend.”

Constraints beat vibes. Name the stack (Next.js App Router, Supabase, Vercel), ban client-side provider keys, and forbid scope creep (teams, billing, admin) until you ask for them.

Verify before the next prompt. Run the app. Create a user. Confirm RLS. A green UI with broken policies wastes every following session.

Keep a living brief. Paste your one-sentence product, primary workflow, and “out of scope” list at the top of each prompt. The AI PRD Generator is a fast way to produce that brief.

Phase 1 — Scaffold the vertical slice

Start with Build a SaaS MVP.

Ask Cursor for:

• Landing + /login + /signup + protected /app
• One user-owned resource
• One AI action stubbed or wired through a server path
• .env.example and a README with local + Vercel steps

Acceptance check:

• You can sign up, land in /app, create the resource, and see it listed after refresh
• No OpenAI or service-role keys appear in client bundles

If the scaffold invents five modules, stop and restate: one resource, one AI action.

Phase 2 — Auth that will survive real users

Use Supabase Auth as a dedicated session even if the scaffold “included auth.”

Focus the prompt on:

• Browser vs server Supabase clients
• Middleware protection for /app
• Session refresh behaviour
• Redirect URLs for local and Vercel preview/production
• Profile creation on first login (trigger or upsert)

Acceptance check:

• Logged-out users cannot open protected pages
• Two browsers / profiles do not share sessions accidentally
• Sign-out clears access to /app

Auth bugs found in beta are disproportionately expensive. Fix them before you invest in prompt engineering for the model call.

Phase 3 — Schema and RLS

Run Supabase schema with your actual resource names from the PRD.

Require:

• Ownership columns (user_id)
• Timestamps and status fields
• RLS policies for select/insert/update/delete
• An AI runs / generations table if outputs should be audited or re-shown

Acceptance check:

• User A cannot read User B’s rows (prove it with two accounts)
• Failed AI runs still leave a row you can inspect
• Migrations or SQL are saved in the repo, not only in the Supabase UI memory of whoever clicked last

Phase 4 — Real AI integration

Use OpenAI API integration.

The prompt should force:

• Server-only API key
• Session + ownership checks before any provider call
• Input validation and size limits
• Persistence of outputs and errors
• Typed responses for the UI

Acceptance check:

• Turning off the API key fails gracefully in the UI
• Repeating the action produces a new run record (or a deliberate idempotency rule you chose)
• Token/cost metadata is stored when the provider returns it (or estimated consistently)

This is also the moment to decide default model and max_tokens. Optimise later with evidence; do not start on the most expensive model “just in case.”

Phase 5 — Abuse and cost guardrails

Public URLs attract scripts and curious friends with expensive habits.

Sequence:

1. Add rate limiting on AI routes (per user and optionally per IP).
2. Reduce OpenAI API cost — smaller defaults, tighter prompts, caching, truncation policies.
3. Optionally add model routing once you have quality tiers (draft vs final).

Acceptance check:

• A tight loop of requests hits a limit with a clear error
• Cost calculator assumptions (AI SaaS Cost Calculator) match your caps (max input size × runs/day × users)

Phase 6 — Analytics and learning loops

Use Add analytics to instrument the funnel that matters:

• Signup
• First resource created
• AI started / succeeded / failed
• Return usage

Avoid painting the codebase with dozens of events. You want to answer: Do people reach a successful AI outcome, and what does that cost?

Phase 7 — Billing only when the loop is real

When the workflow is sticky enough to charge for, use Stripe subscription billing.

Rules that keep this phase sane:

• Gate expensive AI actions on entitlement server-side (never only in the UI)
• Verify webhooks
• Define what happens on cancel, past_due, and trial end before you write pricing copy

If you add Stripe earlier than a working AI loop, you will polish checkout for a product nobody finished using.

Phase 8 — Production and security reviews

Before inviting strangers:

• Prepare MVP for public beta
• Production readiness review
• Security review for AI SaaS

These prompts work best when you ask Cursor to inspect the repo and produce a punch list, then you fix items in small follow-up sessions. Do not ask for a rewrite of the application “to be production grade” in one pass.

Cross-check the punch list against the human-readable AI SaaS production readiness checklist.

Suggested calendar for a solo builder

A realistic sequencing pattern (adjust to your pace):

1. PRD + scaffold
2. Auth hardening + schema/RLS proof
3. AI path + persistence
4. Rate limits + cost caps
5. Analytics
6. Deploy + feedback from 5–20 users
7. Billing (optional) + beta checklist

The prompts are reusable; the calendar is not sacred. What matters is verification gates between phases.

Common prompt failures (and fixes)

Failure: Cursor builds a component library and marketing site, then stalls on data.
Fix: Restate the vertical slice; forbid new pages unrelated to the core loop.

Failure: AI works in local demo with a key in .env.local exposed to the client.
Fix: Demand a server-only path and a quick grep for key prefixes in client components.

Failure: RLS “done” but tables are queried with the service role from the browser path.
Fix: Ban service role outside trusted server/admin/webhook handlers.

Failure: Infinite refactors of folder structure.
Fix: Freeze structure after scaffold; only change files tied to the current outcome.

How to write your own follow-up prompts

When library prompts are not enough, structure custom ones the same way:

1. Context (product + stack + current branch state)
2. Goal (one outcome)
3. Constraints (security, scope, style)
4. Implementation notes (files/patterns to prefer)
5. Acceptance checks (how you will verify)
6. Non-goals

Example skeleton:

Product: [one sentence]
Stack: Next.js App Router, Supabase, Vercel
Goal: Add per-user daily cap for AI generations and show remaining quota in /app
Constraints: server-side enforcement; no new dependencies unless required
Non-goals: billing, teams, email notifications
Acceptance: 3rd call in a test day returns 429; UI shows remaining count

Keep the library next to the build

Bookmark the hub at /cursor-prompts and move linearly when you can. Jumping randomly from billing to schema to landing-page copy is how MVPs stall.

Your advantage is not secret prompts. It is discipline: small sessions, hard acceptance checks, and a product brief Cursor cannot ignore.