← All guides

Production checklist for an AI-built SaaS

A prototype becomes a product at the point where somebody pays for it and expects it to be there tomorrow. This is the list of what sits in between, grouped so you can hand it to someone.

8 min read · Updated September 2026 · Vibestruct

Use this as a working document rather than a wall of requirements. Mark each line done, not applicable, or later — the “later” pile being an explicit decision is most of the value.

Security

• No secret keys in anything the browser downloads
• Every key that was ever public has been rotated
• Secrets held in the host’s environment configuration, not in the repo
• Dependencies installed from known sources, with a lockfile committed
• HTTPS everywhere, with HTTP redirected
• User input validated on the server against an explicit schema
• Output escaped where user content is rendered
• Rate limiting on anything that sends email, costs money or can be brute-forced

Authentication and permissions

• Sessions issued and verified by the server
• Every data-touching request re-checks who is asking
• Roles read from the server’s record of the user, never from the client
• Password reset and email verification flows actually tested end to end
• A deliberate cross-account read attempt returns nothing
• Admin functionality reachable only by admins, verified server-side

Data

• A real database, with a schema you could explain
• Access rules enabled and scoped on every table
• Automated backups running, with a known retention window
• A restore tested at least once, on purpose
• Migrations applied through a repeatable process rather than by hand
• Personal data you hold is data you can justify holding, and can delete on request

Payments

• Entitlement granted by a verified provider webhook, not by a success page
• Webhook signature checked against the signing secret
• Duplicate webhook deliveries handled without double-granting
• Failed payment, cancellation and dispute each have a defined outcome
• Test and live keys are not interchangeable by accident
• Someone receives an alert when a payment path errors

Infrastructure and deployment

• Separate environments for live and for everything else
• Separate databases and separate keys per environment
• Deployment is repeatable and does not depend on one person’s laptop
• A way to roll back a bad release
• Custom domain, valid certificate, sensible caching
• Build and deploy triggered from version control

Reliability

• Uptime monitoring with alerting that reaches a human
• Error reporting with enough context to debug from
• Errors shown to users say something true and useful
• Long operations cannot leave data half-written
• Third-party outages degrade the product rather than breaking it
• Logs exist, and you can search them

The boring operational half

• A terms of service and a privacy policy that match what the product does
• A support address someone actually reads
• Domain and certificate renewals not resting on one forgotten account
• More than one person able to reach the hosting, database and payment accounts
• A written note of what runs where — the thing you will want in six months

What this list is not

It is not a standard, and nothing here certifies anything. It is the set of things that, in our experience, separate an application that survives its first hundred paying users from one that generates an incident. Your product may need more — regulated data, in particular, changes the picture considerably — and it may legitimately need less.

The useful move is to go through it once, honestly, and decide. Most founders find that the list is shorter than they feared and that the top of it is more urgent than they thought.