Prepare an MVP for Public Beta

Problem this prompt solves

A working demo on localhost is not a beta. Public users will hit expired sessions, empty error toasts, unbounded AI clicks, missing privacy links, and “contact me on Twitter” support. Preparing for beta means closing the gaps that cause account takeovers, bill shock, or trust loss — not redesigning the marketing site.

When to use it

• Core workflow works for you; strangers are about to try it.
• You have no rate limits, budgets, or support path defined.
• Env vars and debug flags may still be in a prototype state.
• You want Cursor to produce a punch-list and fix the highest-severity items in-repo.

Prepare this AI SaaS MVP for a public beta on Vercel + Supabase + OpenAI.

Work in two passes.

Pass A — Audit (write BETA_READINESS.md):
Score each area: Ready / Partial / Missing
- Auth & session hardening (middleware, redirects, logout)
- RLS on all user data tables
- Server-only secrets (OpenAI, service role)
- AI cost controls (rate limits, max_tokens, basic budgets)
- Input validation and size limits
- Error states and empty states in /app
- Observability (error tracking and/or structured logs)
- Analytics for signup + first successful generation
- Legal basics: privacy policy & terms links, clear data usage for AI
- Support path (email or form) and “beta” expectations copy
- Backup/export story for user data (even if manual)
- Performance: protected routes do not flash private data before redirect

Pass B — Implement the highest-severity Missing/Partial items that fit an MVP (do not build billing or teams unless already started):
1) Fix secret exposure or RLS holes immediately
2) Add or tighten rate limiting on AI routes
3) Add user-safe error handling for AI failures
4) Add a simple status/banner for beta + feedback email/link
5) Ensure .env.example is complete; remove dead debug bypasses
6) Add basic health checks or verify Vercel logs capture server errors

Constraints:
- Prefer fixing trust/safety over new features
- Do not invent a full status page or PagerDuty integration
- Call out anything you did not implement as explicit launch blockers

Finish with: “Ship / Ship with blockers / Do not ship” and a short justification.

Expected result

A BETA_READINESS.md audit, concrete fixes for the worst gaps (secrets, RLS, limits, errors, beta messaging), and a clear ship/no-ship call with remaining blockers listed.

Implementation notes

• Public beta still needs RLS — “friends will be nice” is not a control.
• Put a feedback mailto or form in the app shell; Twitter DMs do not scale when something breaks at 11pm.
• If you lack error tracking, at least ensure server errors log with a request/run id you can search.
• Disable or gate any seed/demo impersonation routes before sharing the URL.
• Confirm Supabase and OpenAI project limits match expected beta traffic.
• Ship with a waitlist mode if cost controls are not ready — vanity launch traffic is expensive.

Testing checklist

• Fresh user path: signup → first primary resource → first AI success on production/preview.
• Second user cannot access first user’s data via UI or API.
• AI abuse click-spam returns 429 before OpenAI spend spikes.
• Forced OpenAI failure shows a friendly error and leaves the app usable.
• Logged-out visit to a deep /app URL redirects without content flash.
• Privacy/terms links resolve; support/feedback path works.
• Production env vars present on Vercel; no NEXT_PUBLIC_ secret leaks in client bundle search.
• BETA_READINESS.md matches what is actually deployed.

Common mistakes

• Polishing landing-page animations while AI routes are unbounded.
• Leaving service-role keys in client code “just for the beta.”
• No privacy disclosure while sending user content to OpenAI.
• Calling it production-ready because the happy path worked once.
• Skipping analytics — you cannot tell if beta users activate.
• Ignoring email deliverability for auth magic links until launch day.