Cursor + Supabase + Vercel: A Practical AI SaaS Stack

If you are building an AI SaaS MVP with Cursor, the stack that usually gets you to a sharable URL fastest is deliberately boring: Next.js on Vercel, Supabase for auth and Postgres, and a server-side model provider (commonly OpenAI). This article explains how the pieces fit, what each owns, and how to prompt Cursor so it builds toward that architecture instead of a pile of client-side demos.

For the full product path, see How to Build an AI SaaS MVP with Cursor. If you are choosing between backends, read Supabase vs Firebase for AI SaaS.

Architecture at a glance

                    ┌─────────────────────────┐
                    │     Browser (Next.js)   │
                    │  UI + auth session cookie│
                    └───────────┬─────────────┘
                                │
                    ┌───────────▼─────────────┐
                    │  Vercel (Next.js app)   │
                    │  RSC / Route Handlers   │
                    │  Server Actions         │
                    └───┬─────────────────┬───┘
                        │                 │
           ┌────────────▼──────┐   ┌──────▼────────────┐
           │     Supabase      │   │  Model provider   │
           │ Auth + Postgres   │   │ (OpenAI, etc.)    │
           │ RLS policies      │   │ server API key    │
           └───────────────────┘   └───────────────────┘

Request paths that matter:

1. Read/write user data — browser or server Supabase client with the anon key + user JWT; RLS enforces ownership.
2. Run AI — Route Handler / Server Action verifies session + ownership, then calls the model with a server-only key, then writes results to Postgres.
3. Admin/webhooks only — service-role key on trusted server paths; never in the client bundle.

Why this stack works with Cursor

Cursor (and similar coding agents) perform better when conventions are common and files have obvious homes.

• Next.js App Router gives clear places for UI (app/), server APIs, and middleware.
• Supabase has repetitive but teachable patterns: clients, auth.getUser(), RLS SQL.
• Vercel removes “works on my machine” deploy friction so you can test auth redirects early.
• One repo means Cursor can navigate UI → API → SQL without hopping services.

You are not choosing this stack because it is the only “serious” architecture. You are choosing it because it minimises glue code while you still do not know if the product matters.

Responsibility split

Next.js + Vercel

Owns:

• Rendering and routing
• Session cookies via server Supabase helpers
• AI orchestration endpoints
• Env var injection per environment (preview vs production)
• Rate limiting hooks / edge-friendly guards (implementation varies)

Does not own:

• Long-term durable business data (that is Postgres)
• Being your secret store for sharing keys with the browser

Supabase

Owns:

• Authentication
• Postgres + backups/ops basics
• Row Level Security as your tenancy boundary for MVP
• Optional storage/realtime when you truly need them

Does not own:

• Prompt logic or model routing (keep that in app code)

Model provider

Owns:

• Inference

Does not own:

• Your permissions model (never “trust the client to pass user id”)
• Your source of truth for outputs (persist in your DB)

Project shape Cursor should converge on

When you use Build a SaaS MVP, steer toward something like:

app/
  (marketing)/page.tsx
  login/ ...
  signup/ ...
  app/ ...                 # protected product UI
  api/ai/.../route.ts      # or server actions
lib/
  supabase/
    client.ts              # browser
    server.ts              # cookies / RSC
    admin.ts               # service role (rare)
  ai/
    provider.ts            # wrap SDK
    runGeneration.ts       # validate, call, persist
supabase/
  migrations/              # schema + RLS

The names can differ. The boundaries should not.

Environment variables without footguns

Typical set:

• NEXT_PUBLIC_SUPABASE_URL
• NEXT_PUBLIC_SUPABASE_ANON_KEY
• SUPABASE_SERVICE_ROLE_KEY (server only)
• OPENAI_API_KEY (server only)
• Later: Stripe secrets, analytics keys

Rules:

• NEXT_PUBLIC_* is visible to the browser — treat it as public.
• Preview deployments need their own auth redirect allowlist entries.
• Rotate any key that ever appeared in a client bundle or public repo.

Data and tenancy model

For most AI MVPs, user-id ownership + RLS is enough before teams/orgs:

• profiles tied to auth.users
• Primary resource table with user_id
• generations or ai_runs with FK to the resource, plus model/latency/error fields

Cursor can draft policies; you must prove them with two accounts. Policy mistakes are silent.

When you eventually need organisations, add an explicit membership model — do not fake “teams” by sharing passwords.

AI path design on this stack

Recommended flow:

1. User submits form in a Client Component (or progressive form).
2. Server Action / Route Handler runs.
3. supabase.auth.getUser() (server) — reject if missing.
4. Load resource with user-scoped client; reject if not found.
5. Validate input length and content type.
6. Call lib/ai wrapper with timeouts and token caps.
7. Insert run row (succeeded / failed).
8. Return data for UI render.

This structure makes it easy to add rate limiting and cost reduction without rewriting the product.

Local → preview → production

A sane progression:

1. Local — Supabase project (or local stack), .env.local, core loop works.
2. Vercel preview — every PR gets a URL; fix cookie/redirect issues here.
3. Production — separate env values; confirm RLS still holds; watch cost dashboards on day one.

Deploy before you “finish” the UI. Auth and env problems dominate first-beta delays.

What to avoid on this stack

• Calling OpenAI from the browser with a leaked key
• Using the service role in Client Components to “fix RLS”
• Skipping migrations and only clicking in the Supabase UI
• Building a custom auth because a tutorial looked cooler
• Adding Kafka / separate AI microservices before you have ten paying users
• Storing only the model output in memory — users will refresh

When to deviate

Choose a different stack when you have a concrete constraint:

• You already run Firebase deeply across mobile clients → see the comparison article before rewriting
• You need VPC-peered Postgres / enterprise networking on day one
• You are primarily a Python model shop shipping a thin UI (different default)

Until then, prefer speed-to-learning: Cursor implements this shape well, and you can migrate pieces later if the product earns the migration.

Prompting Cursor for stack fidelity

Paste constraints like:

Stack lock:
- Next.js App Router + TypeScript
- Supabase Auth + Postgres + RLS
- Deploy target Vercel
- Model calls only in server code
- One primary resource, one AI action
Refuse features that require new infrastructure services.

Then implement in thin slices using the prompt library. The stack is a scaffold for learning whether users care — keep it boring enough that your time goes into the workflow, not the wiring.