Pre-Launch Checklist

Use this checklist before real people use your site. Go through it with your AI assistant. For each item, ask your AI to check it and show you the result. Each item links to the guide that explains it.

Note: Your AI can check most of these for you. Paste this prompt, then work through the list below together.

We are about to launch. Go through the pre-launch checklist at
https://docs.insites.io/developers-guide/pre-launch-checklist
one item at a time. For each item, check my staging and production
instances, tell me if it passes, and show me the proof. Do not change
anything on production without asking me first.

Domain

• Your site runs on a production instance. A staging instance cannot have your own domain. See Staging vs. Production.
• Your domain is set up on the production instance, and you know which domain is the default. See Instance Domains.
• You have changed your DNS records to point at Insites. Insites does not change them for you. See Migrating to Insites.
• You checked every page and endpoint on the new domain before you switched off any old site.

Email Sender

• Every email sends from an address on a domain you control, not from a domain you do not own. See Creating an Email Notification.
• The reply address of every email goes to a mailbox that someone reads.
• You know that production sends every email to real people. Staging only sent to your test recipients. See Staging vs. Production.
• You sent one real test of each email from production and it arrived.

Staging and Production

• Everything passed on staging first, and production runs the same code. See Safety Rails for AI Builds.
• Every constant your site needs is set on production, with production values. A deploy does not copy constants from staging.
• API call notifications are on in production. Check that your outside services get the calls you expect. See Staging vs. Production.
• Before any production deploy, your AI tells you which instance is selected. See CloudShell Tools.

Pages and Search Basics

• Every page has a title and a description in its metadata, and the layout prints them. See Metadata.
• Your error pages, such as Not Found, match your design. See Custom Error Pages.
• If your old site used other addresses, they redirect to the new ones. See Redirects.
• Images and files are shown through the asset_url filter, so a changed file shows its new version. See Using Static Assets on Pages.

Sign-In and Roles

• Every page that shows private information has an authorization policy. A page with no policy is open to everyone. See Adding an Authorization Policy.
• Your admin area uses an admin role, not one shared password. See Admin Role Instead of a Shared Password.
• You tested sign-in from start to finish on production, with a real email address. See Passwordless Sign-In.
• Each person in your Insites account has the lowest role they need. A person who only looks needs Viewer. See Introduction to Console Users.

Security

• Every API key and password is a constant. None is in a page file, in your GitHub repository, on a page or in the logs. See Safety Rails for AI Builds.
• Your sign-in and your forms limit repeated attempts. Insites has no built-in limit for your own sign-in pages. See Rate Limiting by IP.
• Your public forms have spam protection. See Form Configuration Options.
• Upload fields for private files set acl: private. Without it, uploaded files are public. See Uploads.

Data

• After each import, the record count on the instance matches the count in your source file. See Importing JSON or CSV Data.
• The latest data is loaded into production, not only into staging.
• Staging holds test data, not copies of real customer data. See Staging vs. Production.

GitHub

• GitHub is connected to your production instance, with access to one repository only. See Insites GitHub App.
• The instance watches the right branch. A new connection watches main. If your repository uses another name, such as master, change it.
• Unfinished work goes to another branch, and only finished work is merged into the watched branch.

Rollback Plan

• You know how to undo a change: ask your AI to revert the commit. You know that reverting an older commit also removes every change after it. See Safety Rails for AI Builds.
• You can see the deploy history, so you know which deploy to undo. See CloudShell Tools.
• If you are moving from an old site, it stays running until the new one passes every check.
• You have the Insites support address and your account number ready. See When Your AI Gets Stuck.

Related

• Safety Rails for AI Builds
• Staging vs. Production
• Migrating to Insites
• What Insites Can Do
• When Your AI Gets Stuck