How to ship an AI-built app to production

Decide what production means

Production is the environment strangers reach, with data you cannot lose and behaviour you cannot quietly change. If a URL is public and a customer used it, that is production, whether or not you call it that.

Everything below assumes you have a separate staging environment. If you do not, that is the first thing to build. Testing on production is not testing, it is gambling.

Separate staging from production

• Two environments, two databases, two sets of credentials.
• A staging URL you can break freely, and a production URL you protect.
• No developer logging into production to “try something”.
• The same deployment process for both, so staging actually predicts production.

Move every secret out of the code

• Secrets live in the environment, never in the repository.
• Only values meant to be public are exposed to the client. Everything else stays on the server.
• Rotate anything that has ever been committed, because the history keeps it.
• Use different keys per environment, so a staging leak does not touch production.

Lock the data down

• Authorization is enforced on the server and in the database rules, not in the interface.
• Every table or collection has a rule that says who can read and write it.
• Storage and file buckets are private unless they are meant to be public.
• Backups exist, and you have restored one at least once.
• You know what you would do if the data leaked, because you have written it down.

Handle the unhappy paths

• A missing record, an empty list, a failed payment and a dead network each show something sensible.
• Errors are logged with detail on the server and shown to the user as a plain sentence.
• The app does not hang or loop when a dependency is unavailable.
• A form submitted twice does not create two records.

The pages and policies you cannot skip

• Terms of service and a privacy policy that describe what you actually collect.
• A cookie or consent notice where the law expects one, connected to a real choice.
• A contact route that reaches a person.
• A 404 page and an error page that look intentional.

Watch it, and be able to undo it

• Uptime or error monitoring that would tell you the site is down before a customer does.
• A rollback path: the previous version deployable in minutes.
• Logs retained long enough to investigate an incident.
• An owner for the alert, so it is not a channel nobody reads.

The final pass

1. 01

   Walk the product as a new user

   Sign up, use it, pay for it, delete something. Find the dead ends yourself.

2. 02

   Walk it as an attacker

   Call the API without a session and try to read data that is not yours.

3. 03

   Run an external review

   A black-box pass over the running site catches exposed secrets, missing headers, open rules and placeholder copy in one go.

4. 04

   Check the boring legal pages

   Confirm terms, privacy and consent match what the app really does.

5. 05

   Confirm monitoring and rollback

   Break something on staging and prove you can see it and undo it.

6. 06

   Launch, then re-check

   Re-run the review after the first quiet week, because real usage finds what the demo did not.