Production Readiness Review

Problem this prompt solves

“It works on my machine” hides production failures: missing indexes under load, no timeouts on model calls, silent RLS gaps, and zero alerting when the AI route starts returning 500s. A readiness review should produce severities and patches — not a vague pep talk about best practices.

When to use it

• You are moving from private alpha to paying or public users.
• You want a structured audit before a marketing push.
• Incidents already happened (outages, bill spikes) and you need a systematic pass.
• You want Cursor to fix P0 issues and document P1/P2 follow-ups.

Perform a production readiness review of this AI SaaS (Next.js App Router, Supabase, Vercel, OpenAI or similar).

Method:
1) Inspect the repo: auth, RLS/migrations, AI routes, env usage, error handling, tests, CI, logging, and deploy config.
2) Produce PRODUCTION_REVIEW.md with findings grouped by:
   - Security & privacy
   - Reliability & performance
   - Cost controls
   - Operability (logs, alerts, runbooks)
   - Data integrity & migrations
   - UX failure modes
3) Rate each finding P0 / P1 / P2 with: evidence (file paths), risk, and recommended fix.
4) Immediately implement safe P0 fixes in code (secrets exposure, broken authz, missing RLS on sensitive tables, AI routes without auth, obvious infinite retry spend).
5) For P1 items, implement only if small; otherwise leave a concrete issue list.
6) End with a go/no-go recommendation for production traffic.

Review checklist (cover each explicitly):
- Secrets only on server; no service role in client
- Middleware + server authz on sensitive actions
- RLS enabled and policies reviewed for every business table
- Zod/validation on AI inputs; timeouts; max_tokens
- Rate limiting / budgets on expensive routes
- Idempotency or dedupe strategy for paid AI actions
- DB indexes for primary list queries
- Migrations reproducible on empty project
- Error tracking or structured logs with ids
- Graceful AI provider failures
- Backup/export assumptions documented
- Dependency/license or debug routes that should not ship

Do not rewrite the product. Do not expand scope into new features. Be specific and evidence-based.

Expected result

A PRODUCTION_REVIEW.md with severity-rated findings, P0 fixes applied in the codebase, and an explicit go/no-go for production traffic.

Implementation notes

• Evidence beats opinions — cite routes and SQL policy names in the review doc.
• P0 means “exploitable or wallet-draining,” not “nice to have refactor.”
• If you cannot verify RLS from SQL in-repo, say so and treat “unknown policies” as P0 until checked in Supabase.
• Timeouts on AI calls should be lower than your serverless max duration.
• Add a runbook section even if short: how to rotate OpenAI keys, how to disable generations via env.
• Re-run the review after fixes; stale markdown is worse than none.

Testing checklist

• All P0 code fixes have a manual or automated verification step recorded in the doc.
• Authz regression: user B cannot mutate user A resources.
• AI route without session fails closed.
• Rate limit or budget still engages after refactors.
• App boots with production-like env on Vercel preview.
• Migration apply on a clean database succeeds.
• Error path for provider outage is exercised once.
• No secrets committed; .env.example updated for any new vars.

Common mistakes

• Writing a generic checklist with no file references.
• Fixing style nits while an AI route is public.
• Declaring go-live while RLS status is unknown.
• Treating TypeScript compile success as production readiness.
• Adding complex infra (K8s, multi-region) instead of timeouts and alerts.
• Closing the review without a no-go option — optimism bias.