Your AI-built app can look finished and still fail its first real customer. A polished screen proves none of the hidden work. Check that sign-in protects private data and that each payment runs only once. Then check that uploads survive an update and that you can reverse a broken release.
This checklist turns those hidden risks into a short launch decision. Mark an item complete only after you have tested it and seen the result yourself.
What must work for your first customer?
Write down the shortest journey that delivers the product's value. It might be: sign in, create a project, upload a file, and share the result. This is your critical path—the flow you should check before every release.
Test it with a new account. Then try an empty field, an invalid value, a slow response, and a failed payment or email. The customer should always know what happened and what to do next.
Can the same app be published again?
An app should not depend on files or settings that exist only on your computer. Ask your coding AI to start from a fresh copy and install what the project needs. Then have it create the version meant for the public and report every failure.
How to check
- Publish from a clean copy of the project.
- In JustDeploy's Deployments list, confirm that the intended version has the Live badge. A Ready row alone is not enough.
- Review every warning instead of assuming it is harmless.
- Save the successful release ID so you can find its logs or return to it later.
Which settings must stay private?
Payment keys, database passwords, codes used to confirm messages, and other private access codes should live in the hosting platform's protected settings. These are often called environment variables. The project keeps only each setting's name; the platform supplies the real value when it publishes the app.
Check that no private value appears in browser code, shared files, screenshots, chat transcripts, or logs. Write down who can replace each key if it leaks.
Can one customer reach another customer's data?
A hidden button is not protection. Every request for a private project, invoice, upload, or report must check both who is signed in and whether that person owns the item.
How to check
- Use two different browsers or separate browser profiles. Sign in as test Customer A in one and test Customer B in the other. Two private windows in the same browser may share a sign-in.
- Create private data for both accounts.
- While signed in as B, open A's saved link and try to view, edit, delete, and download.
- Confirm that no private detail appears, even in the error message.
Will data and uploads survive an update?
Customer records belong in a database, and uploaded files belong in file storage that keeps them after an update. Anything a customer expects to find tomorrow should not live only in the app's temporary memory or local files.
Create a record and upload a file, publish a new version, then open both again. Keep test data separate from real customer data, and save a permanent file reference number rather than a download link that can expire.
What happens when an outside service fails?
Your app may depend on payments, email, AI, maps, or another company. Set a time limit for each request and show a useful message when the service is slow or unavailable. Protect payments and other one-time actions from accidental repeats.
Some services send messages back to your app; these are called webhooks. For a payment webhook, ask your coding AI to confirm that the message truly came from the payment service before trusting it.
Does the public address work like the preview?
Open the live HTTPS address in a private browsing window. Refresh a page other than the home page and run the critical path. Check that images and links do not point to localhost or a preview address.
If you use your own domain, update the return pages used after sign-in and the browser rules that remember a login. Update links in emails, preview cards on social apps, and the sitemap given to search engines too. They should all use the same public address.
Can you understand a failure without guessing?
Reproduce one harmless error and find it in the app's logs. A useful entry names the action, time, result, and a tracking number for the request. It must not copy a password, private key, or customer data that is not needed.
Customers also need a clear state for an expired session, empty result, timeout, or unavailable provider. A blank screen turns a small failure into a support request.
Could you recover from a bad update?
Identify the last successful release before launch. Know how to publish that version again, replace a leaked key, and restore data you cannot replace by hand. Test the recovery steps while the stakes are low.
Write down manual settings, including custom-domain records. Recovery should not depend on one person remembering what they clicked months ago.
What is the final launch check?
| Area | Evidence to collect |
|---|---|
| Release | Ready, live, and every warning reviewed |
| Customer journey | Passed at the public address with a new account |
| Privacy | Two-customer access test passed |
| Data | Records and files survived a new release |
| Recovery | Logs are readable and the last good release is known |
Keep this checklist short enough to use every time and strict enough to stop a risky launch. A product is ready when you can show the test result behind each check.
What should you read next?
- I Vibe-Coded an App. Now What?
- How to Add Login Without Exposing Customer Data
- Why Your AI App Works in Preview but Breaks Online
When the checks pass, follow the JustDeploy Quickstart to publish the app and verify its live address.