AI SaaS launch checklist
43 checks to run before an AI product meets real users, in 7 groups. 25 are blockers: spend limits, abuse controls, prompt injection, evals, and billing. Tick them off here, then download the list as markdown.
Spend limits and cost alerts
0 / 7Rate limits and abuse
0 / 7Prompt injection and data safety
0 / 7Evals and output quality
0 / 6Billing and payments
0 / 6Monitoring and operations
0 / 5Accounts, legal, and launch day
0 / 5The full checklist
The same checks as the tool above, as plain tables. Each one says why it matters and links the primary source where there is one.
43 checks in 7 groups. 25 are marked blocker: do not launch until they are done. Sources checked 2026-10-13.
| Check | Level | Why it matters |
|---|---|---|
| Set a hard monthly spend limit on every model provider account. | Blocker | A bug or an abuser can spend a month of budget in an hour. Both Anthropic and OpenAI let you set your own cap below the account limit. Anthropic rate and spend limits |
| Use separate keys and workspaces (or projects) for production, staging, and evals, each with its own limit. | Blocker | A runaway eval job should not take production down with it. Anthropic workspaces and OpenAI projects both take their own spend and rate limits. Anthropic rate and spend limits |
| Enforce a usage quota per user and per workspace in your own database, checked before each model call. | Blocker | Provider limits protect your account, not your margin. Only your own quota stops one free user from using what ten paying users pay for. OWASP LLM10:2025 |
| Send spend alerts at about 50% and 80% of the monthly budget to a channel someone reads. | Should | Alerts only help if someone sees them. OpenAI supports spend alerts and email thresholds on the limits page. OpenAI production best practices |
| Handle the provider spend-cap error as its own case, with a clear message to users and a page to your team. | Blocker | On Anthropic the spend-cap 429 has no retry-after header and retries keep failing until the next month or a higher limit. Check error_code enforced_spend_limit_reached. Anthropic rate and spend limits |
| Log input, cached, and output tokens for every call, with user ID, tenant ID, and feature name. | Should | When the bill jumps, you need to find the heaviest user and feature in one query, not by guessing. |
| Cap input size and max output tokens per feature. | Should | OWASP lists input size limits as the first defence against unbounded consumption. A pasted 300-page PDF should not reach the model by accident. OWASP LLM10:2025 |
| Check | Level | Why it matters |
|---|---|---|
| Rate limit every endpoint that calls a model, per user and per IP. | Blocker | OWASP LLM10 says to "apply rate limiting and user quotas to restrict the number of requests a single source entity can make." OWASP LLM10:2025 |
| Rate limit sign-up, login, password reset, and email sending. | Blocker | These are the first endpoints scripts hit. Unlimited sign-ups also mean unlimited free-tier AI usage. |
| Decide what a free account must prove before it can call a model: verified email, CAPTCHA, or a card on file. | Blocker | A free tier with no gate is a free model API for anyone with a script. |
| Put a timeout on every model call and a step limit on every agent loop. | Blocker | OWASP: "Set timeouts and throttle processing for resource-intensive operations." An agent that loops forever bills forever. OWASP LLM10:2025 |
| Read provider rate-limit headers and back off with jitter, using retry-after when it is sent. | Should | Anthropic returns retry-after and anthropic-ratelimit-* headers. Retrying at once makes a 429 storm worse. Anthropic rate and spend limits |
| Protect the payment form from card testing: Stripe Checkout or Payment Element, login before paying, and limits on cards per account. | Blocker | Stripe says card testers use your publishable key to try stolen cards, and the declines hurt your approval rate after the attack ends. Stripe card testing guide |
| Run long AI jobs on a queue, not inside a web request. | Should | A queue gives you retries, a concurrency cap, and a place to see stuck work. A held-open request gives you none of those. |
| Check | Level | Why it matters |
|---|---|---|
| Give the model only the tools and data the feature needs, scoped to the current user and tenant. | Blocker | OWASP LLM01: "Restrict the model's access privileges to the minimum necessary for its intended operations." OWASP LLM01:2025 |
| Require a human to approve anything that sends, pays, deletes, or changes another person's data. | Blocker | OWASP: "Implement human-in-the-loop controls for privileged operations." No current method fully prevents prompt injection. OWASP LLM01:2025 |
| Mark uploaded files, web pages, and emails as untrusted data inside the prompt. | Blocker | OWASP: "Separate and clearly denote untrusted content to limit its influence on user prompts." OWASP LLM01:2025 |
| Enforce the tenant boundary in the database query, never in the prompt. | Blocker | Injected text can override a prompt instruction. It cannot override a WHERE clause in your query. |
| Keep API keys out of client code and the repo, store them in a secret manager, and set an expiry. | Blocker | OpenAI recommends environment variables or a secret manager, an expiry date on project keys, and regular rotation. OpenAI production best practices |
| Run moderation on input and output where users can see each other's content. | Should | OpenAI's moderation endpoint is free and its omni-moderation-latest model takes text and images. OpenAI moderation guide |
| Read each model provider's data retention and training terms, and name the providers in your privacy policy. | Should | Business customers will ask. A clear answer before launch saves a lost deal later. |
| Check | Level | Why it matters |
|---|---|---|
| Build a set of real inputs with known-good answers, and run it before every release and every prompt change. | Blocker | Without it, a prompt edit that fixes one case can quietly break ten others. |
| Pin a dated model version, and re-run the evals before you switch. | Blocker | An alias that moves to a new model can change outputs, token counts, and cost on a day you did not choose. |
| Add hostile and odd inputs to the eval set: injection attempts, empty input, huge input, other languages. | Should | Real users and scripts send these in the first week. |
| Validate structured output against a schema before your code uses it. | Blocker | A missing field should become a retry or a clear error, not a crash three steps later. |
| Decide what users see when the model fails or times out: a fallback model, a retry, or a plain message. | Should | Every provider has outages. A blank screen reads as a broken product. |
| Add a thumbs-down or report button that saves the request ID. | Should | The best new eval cases come from the outputs users reject. |
| Check | Level | Why it matters |
|---|---|---|
| Verify Stripe webhook signatures using the raw request body. | Blocker | Stripe: "Without verification, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access, or modifying records." Stripe webhooks docs |
| Dedupe webhook events by event ID, and do not depend on their order. | Blocker | Stripe: "Webhook endpoints might occasionally receive the same event more than once" and it "doesn't guarantee the delivery of events in the order that they're generated." Stripe webhooks docs |
| Give every usage event an idempotency key, such as your request ID. | Blocker | Your app will retry a failed send. Without a key, the retry bills the customer twice. Stripe meter events docs |
| Test the unhappy paths in test mode: declined renewal, cancel, downgrade while over the new limit, refund. | Should | Demos only test the happy path. These cases turn into support tickets and disputes. |
| Write down what happens to access when a payment fails, and how long the grace period is. | Should | If the code and the support reply disagree, you get a dispute. |
| Decide who handles sales tax and VAT before your first sale outside your home country. | Should | Stripe Tax, a merchant of record, or your accountant can all work. Deciding after the sales come in costs more. |
| Check | Level | Why it matters |
|---|---|---|
| Turn on error tracking for client and server, with alerts that reach a person. | Blocker | Launch week is when you find the bugs. You want to hear about them before users email you. |
| Trace each model call: request ID, model, latency, tokens, cost, user, and tenant. | Blocker | This one log answers "why is it slow", "why is it expensive", and "what did the user see". |
| Run backups and test one restore before launch. | Blocker | Teams often learn a backup is broken on the day they need it. A test restore finds that out early. |
| Add an uptime check that exercises the main AI feature, not just the home page. | Should | The home page can be up while the model call behind the product fails. |
| Write a one-page runbook: provider outage, spend spike, leaked key. | Should | At 2 a.m. nobody should have to work out how to rotate a key from scratch. |
| Check | Level | Why it matters |
|---|---|---|
| Make account deletion and data export work end to end, including stored prompts and files. | Blocker | Users in the EU have a right to erasure under GDPR Article 17. Stored prompts and uploads count. GDPR (EUR-Lex) |
| Publish terms and a privacy policy that name the AI providers that process user data. | Blocker | Users and business buyers read this before they upload anything sensitive. |
| Tell users when they are dealing with AI output, and check if the EU AI Act transparency rules apply to you. | Should | Clear labels set expectations and cut support tickets about wrong answers. |
| Give new users a sample or demo so they see the AI work before they bring their own data. | Should | A new user with an empty workspace has nothing to try the AI on. |
| Name who answers the support inbox during launch week, and how fast. | Should | Early users ask a lot of questions. Someone needs to own the replies. |
What it covers
The checks that are different for a product built on a language model: spend that scales with use, users who can make your app spend money, prompts that can be hijacked, and output that can change when the model changes. Plus the billing and operations basics that every SaaS needs on day one.
What it leaves out
Marketing, pricing, and product-market fit. Industry rules such as HIPAA or SOC 2. Load testing for your own traffic levels. If you handle health, finance, or children's data, add the checks your regulator asks for.
Questions clients ask
Short answers, no sales language. If yours isn't here, ask an engineer directly.
Ask us anythingWhat should I check before launching an AI SaaS?
Start with the 25 blockers: hard spend limits on every model account, a usage quota per user, rate limits on AI and sign-up endpoints, least-privilege tools with human approval for risky actions, an eval set you run before each release, verified and deduplicated Stripe webhooks, error tracking, and a tested backup restore.
What is the difference between a blocker and a should?
A blocker is a check that can cost you money, customer data, or trust in your first weeks if you skip it. A should is a check that makes the product better and the team calmer, but can follow soon after launch.
Is my progress saved?
Yes, in this browser only, using local storage. Nothing is sent to us or anyone else. Use the download button to keep a copy or share it with your team.
Can I use this checklist in my own docs?
Yes. Download it as markdown and paste it into your repo, wiki, or issue tracker. A link back is welcome but not required.
Launching an AI product?
We build AI SaaS products end to end, with spend limits, evals, and billing in from the first version. An engineer replies, not a sales team.