First production checklist for vibe-built apps

What “production” means here

Production is the live version other people use — not the preview on your laptop. The bar is higher: privacy, reliability, and the ability to fix things when they break.

You do not need enterprise bureaucracy for a hobby. You do need a short gate when the app holds other people’s information, takes money, or would embarrass you if it leaked.

When to use this checklist

Use it when any of these become true:

• Someone who is not you will create an account or enter personal details
• You will process payments or store card-adjacent data
• The app is advertised publicly (ads, Product Hunt, your clients)
• You would be upset if the database appeared on the open internet

1. Identity and access (logins)

Authentication means “who is this user?” If the app has private pages, every sensitive action should require a real session — not a hidden URL.

Then check authorisation: user A must not open user B’s records by changing an id in the address bar or in a request. That bug class is common in AI-generated apps (sometimes called IDOR — see the glossary).

• Create two test users and try to view each other’s data on purpose
• Log out and confirm private pages bounce to login
• If you use a database product with “row level security,” confirm it is on and tested — defaults are often too open in demos

2. Secrets and configuration

API keys and passwords must not live in front-end code that any visitor can download. They belong in environment variables (settings outside the code) on the server or host dashboard.

If a key was ever pasted into a chat or committed to GitHub, rotate it (create a new one, delete the old) in the provider’s dashboard.

• Search the project for sk-, api_key, secret, password patterns
• Confirm .env files are not published publicly
• Use separate keys for test vs live when the provider allows it

3. Data you collect

List every field you store about people. If you do not need it, do not collect it. Write one plain paragraph on the site about what you collect and why — even a short privacy note helps trust.

Australian context: if you handle personal information, learn whether the Australian Privacy Principles apply to your situation (not legal advice — start from official OAIC material and/or a professional).

4. Failures, backups, and boring reliability

What happens when the network fails mid-save? When the user double-clicks submit? When the database is empty on first run? AI demos love happy paths; production is full of empty states.

Know how you would restore data if the host ate your database. A manual export once a week is better than “we never thought about it.”

5. Payments (if any)

Stay in test mode until the flow is boringly correct. Never log full card numbers. Prefer a known provider (e.g. Stripe) over hand-rolled card handling.

Webhooks (server-to-server notifications) must verify signatures. If that sentence is new, do not go live with payments until you understand it or have help.

6. A one-hour pre-launch drill

Set a timer and run:

• Fresh browser / incognito: sign up, core action, log out
• Second user: confirm isolation of data
• Mobile width: forms and buttons usable
• Turn off Wi‑Fi briefly: do you show an honest error?
• Scan for secrets one more time
• Write down how to contact you if something breaks

Related on this site

Production hardening goes deeper on failure modes. How to test prompts explains how to trial AI output before you trust it. The Australia page flags privacy and AUD context without replacing professional advice.