AI SaaS Production Readiness Checklist

Use this checklist when an AI SaaS MVP is moving beyond a personal demo. It is intentionally practical: each item should map to something you can verify in the product, repo, or provider dashboard.

For narrative context, read How to Take an AI MVP From Prototype to Production. For launch-day sequencing, see From AI Prototype to Public Beta.

How to use it

• Work in order: Product → Security → AI → Cost → Privacy → Reliability → Analytics → Growth → Legal
• Mark items done only when verified (two-account tests, curl calls, deploy dry-runs)
• Turn leftovers into a punch list; fix in small Cursor sessions rather than one “make it production” rewrite

---

Product

• [ ] One primary user job is stated on the landing page in plain language
• [ ] A new user can complete the core loop without a screenshare
• [ ] Empty states explain the next step (not only a blank table)
• [ ] Error messages tell the user what to do next
• [ ] Non-goals / beta limitations are documented (model mistakes, unsupported file types, etc.)
• [ ] Onboarding requires only the fields needed for the first success
• [ ] “Happy path” screenshots or a Loom exist for support and your future self
• [ ] Feature flags or config can disable incomplete experiments without redeploying the whole app (when applicable)

Security

• [ ] Model provider API keys are server-only (not in client bundles or NEXT_PUBLIC_*)
• [ ] Database service-role / admin keys are server-only and unused in browsers
• [ ] Authentication required for all AI and mutation endpoints
• [ ] Authorisation checks ownership/tenancy on every read/write of user data
• [ ] Row Level Security (or equivalent) proven with two real accounts
• [ ] Security headers and HTTPS are in place on the production domain
• [ ] Dependency audit run recently; critical issues addressed or explicitly accepted
• [ ] Debug routes, test login backdoors, and seed admin panels are disabled in production
• [ ] Webhook endpoints (billing, etc.) verify signatures
• [ ] Secrets differ across local / preview / production and can be rotated
• [ ] File uploads (if any) validate type/size and are stored outside the web root with access controls

AI

• [ ] AI calls go through a single server-side module (not copy-pasted SDKs in many routes)
• [ ] Inputs are validated and size-capped before provider calls
• [ ] Output token limits are set per action type
• [ ] Timeouts are defined; hung requests do not block forever
• [ ] Each run persists status (queued / succeeded / failed) and enough metadata to debug
• [ ] Model name / prompt version label is stored with outputs
• [ ] Double-submit / retry behaviour is safe (idempotency key or equivalent)
• [ ] Agent/tool loops have a hard max step count
• [ ] Kill switch exists to disable generations quickly
• [ ] Failure UX distinguishes user mistakes vs provider outages vs rate limits
• [ ] Prompt injection / untrusted document content is treated as untrusted input in instructions

Cost

• [ ] Cost per successful action estimated from real or sample runs (calculator)
• [ ] Per-user rate limits on expensive AI routes
• [ ] Daily/monthly generation caps for free or beta tiers
• [ ] Default model is cost-appropriate; upgrades are explicit
• [ ] Caching or reuse policy defined for identical requests (or consciously rejected)
• [ ] Alerts or a daily check on provider spend
• [ ] Spike scenario (10× usage) reviewed; product still survivable
• [ ] Client cannot choose arbitrary models/parameters that bypass server policy

Privacy

• [ ] Privacy notice explains what is stored and what is sent to model providers
• [ ] Retention period for prompts, outputs, and logs is decided
• [ ] User deletion / export path exists or is manually runnable with a documented process
• [ ] Error trackers / analytics tools configured to avoid careless PII/prompt sprawl
• [ ] No training-on-user-data claim is made unless it is true and intentional
• [ ] Staff access to production data is limited and auditable at MVP scale (even if that means “only founders”)
• [ ] Secrets and personal data are not pasted into third-party chat tools as a support habit

Reliability

• [ ] Production deploy is reproducible from the main branch
• [ ] Database backups enabled; restore steps known at a high level
• [ ] Migrations are reviewed before apply; destructive changes have a plan
• [ ] Provider outage messaging is ready (status copy, not only stack traces)
• [ ] Long jobs use async patterns if they exceed HTTP timeout comfort
• [ ] Uptime or synthetic check on the marketing site + authenticated health of a critical API (lightweight is fine)
• [ ] Rollback path practiced once (redeploy previous build)
• [ ] Rate-limit and quota responses are load-tested manually (scripted burst)

Analytics

• [ ] Signup event tracked
• [ ] First primary resource created tracked
• [ ] AI action started / succeeded / failed tracked
• [ ] You can answer “what % of signups reach first success?” in under 10 minutes
• [ ] Cost metrics can be joined to usage (even in a spreadsheet at MVP stage)
• [ ] No wall of vanity events that nobody reads

Growth

• [ ] Waitlist or signup path works on mobile
• [ ] Referral/feedback channel exists (form, email, or community)
• [ ] Launch assets match the real product (no features that are not shippable)
• [ ] Support inbox or alias monitored during launch window
• [ ] Rate limits sized so a launch spike does not look like a total outage
• [ ] “Beta” expectations set where quality is still variable

Legal / compliance (baseline, not legal advice)

• [ ] Terms of use published (acceptable use, AI limitation of liability language as appropriate)
• [ ] Privacy policy published and consistent with actual data flows
• [ ] Cookie/analytics consent pattern matches your jurisdictions and tooling (as applicable)
• [ ] Copyright / user content ownership for inputs & outputs addressed at a basic level
• [ ] If you process sensitive categories (health, minors, etc.), escalate beyond this MVP checklist before marketing broadly
• [ ] Vendor DPAs / data terms reviewed at a glance for your model and hosting providers
• [ ] Abuse contact or process for reporting harmful outputs exists

---

Suggested scoring for go / no-go

Do not open public signup if any Security item around keys, authz, or tenant isolation is open.

Do not run a launch post if Cost caps and AI kill switch are open.

Be cautious if Privacy promises and logging reality disagree.

Ship a closed beta when Product happy path, Security basics, AI persistence, and Cost caps are done — even if Growth polish is thin.

Turn gaps into work

Paste incomplete items into Cursor with production readiness review and security review. Ask for a prioritised punch list mapped to files, then clear items in order of user harm and financial risk — not in order of visual polish.

Production readiness is not a trophy. It is the minimum respect for strangers who trusted your URL with their data and your invoice with their curiosity.