Check your AI-built app before customers use it
Check who can see and change information, where passwords and payment keys are kept, and how your app behaves when visitors make ordinary mistakes.
before you start
Test every important change with made-up information before customers, payments, or real records are involved.
Write down what every screen should do
in plain words
Start with the screens and actions you recognize, then compare that simple plan with what the AI created.
Open your app and visit every screen you can find. For each one, write a sentence describing its job, such as welcoming a visitor, collecting a booking, showing an order, or letting the owner change business settings. Add who should be allowed to use it: everyone, a signed-in customer, a staff member, or only the owner. This list gives you a clear expected result before you begin testing. Without it, an unexpected screen can look correct simply because the AI made it look polished.
Next, complete the most important journey from beginning to end with made-up information. Create a test account, perform one harmless action, leave the app, return, refresh the page, and sign out. Record each screen you expected and what actually happened. Developers call this sequence a user flow. You do not need to study the app's written instructions to review it. You are checking whether the visible experience follows the rules of your business and whether every step has a clear purpose.
- ▸Describe each screen in one sentence.
- ▸Write who should be able to view it and use its actions.
- ▸Use invented names and test records instead of customer information.
common risk
An owner-only settings page appears for every signed-in customer because the AI was never told exactly who should use it.
what to do now
Create a one-page list of screens, purposes, and allowed people before accepting another AI-generated change.
ask your AI
Review every screen in this app. In plain language, list the screen name, its purpose, who should be allowed to open it, what information it shows, and what each button changes. Identify any screen or action where the intended person is unclear. Do not change the app yet; give me the review first.
Check what each person can see and change
in plain words
A missing button is not enough; the app must refuse an action when the wrong person tries it.
Test with at least two new accounts. Give one account the ordinary customer role and use the other only where a different person is useful. Sign in with each account and check profiles, orders, bookings, messages, downloads, and owner settings. Each person should see only the information intended for that person. Also test while signed out. Saving a page address or returning with the back button must not let someone reopen information that should require the correct account.
The app needs to decide again whether the current person may perform each important action, even if a button is hidden. The technical name is authorization: the app's decision about whether this person may view, create, change, or delete this particular item. Ask the AI builder where that decision is enforced when the action is received. A visual rule that merely hides a button is not the same as refusing the action. Record the exact account, screen, item, and result whenever something unexpected happens.
- ▸Test as a signed-out visitor, an ordinary customer, and an owner when those roles exist.
- ▸Try the same important action with an allowed account and a refused account.
- ▸Confirm that one customer cannot open or change another customer's records.
common risk
A customer cannot see an edit button, but reopening a saved page still lets that customer change another person's booking.
what to do now
Make a small table of important actions, who may perform them, and the result you observed with each test account.
ask your AI
Review every action that views, creates, changes, downloads, or deletes information in this app. For each action, state who should be allowed to use it, where the app refuses the wrong person, and how I can test that refusal with two made-up accounts. Flag any action that is protected only by hiding a button.
Keep passwords and payment keys out of public downloads
in plain words
Anything sent to a visitor's device can be inspected, even when it does not appear on the screen.
An app sends instructions and information to the device that opens it. The program used to open websites is technically called a browser. A visitor may inspect what that program received, including text that the page does not display. Therefore, a password, payment key, or access code that can open customer records, send email, change stored files, or spend money must never be included in those downloadable instructions. Making the text difficult to notice does not protect it.
Ask your AI builder to list every password, payment key, and access code, explain what each one unlocks, and say whether it can reach a visitor's device. The protected part of the app should use those items without sending them to the visitor. If one was included in a public download, removing it is only the first step. Replace it through the company that issued it, because someone may already have copied the old one. Use separate test keys for test payments whenever the payment company provides them.
- ▸Name every password, payment key, and access code and what it unlocks.
- ▸Check whether any of them can be downloaded by a visitor.
- ▸Replace an exposed item instead of merely deleting it from the next version.
common risk
A powerful payment key is included in the checkout screen's downloadable instructions, so a visitor can copy something that can create charges.
what to do now
Have the AI builder move each powerful password, payment key, or access code to the protected part of the app, then replace anything that was publicly downloadable.
ask your AI
Find every password, payment key, and access code used by this app. For each one, tell me exactly what it unlocks or can spend, whether any visitor can receive or download it, and which protected part of the app should use it instead. If one may have been public, give me a safe replacement checklist, including where I must replace it with the issuing company. Do not print the full values in your answer.
Test mistakes that real visitors make
in plain words
Repeated clicks, missing information, interrupted payments, and refreshed pages should have clear and predictable results.
People double-click buttons, lose their connection, close tabs, refresh pages, and return later. Test these ordinary situations with made-up records and payment test settings. Before each test, write what should happen. Then click Save twice, refresh after submitting a form, leave a booking unfinished, go back during checkout, and submit missing or unusually long information. Check whether the app explains the problem clearly and whether a completed action appears the correct number of times.
Pay extra attention to anything that changes money, stock, bookings, messages, or customer information. The app should inspect information before accepting it and should reject results that do not make sense. The technical name is validation: checks performed before information is saved or an action is completed. Error messages should tell the person what to fix without showing another customer's information, passwords, payment keys, access codes, or the app's protected instructions. Keep a written test list so you can repeat it after the AI changes the app.
- ▸Try a repeated click, a refresh, an interrupted action, and missing information.
- ▸Confirm that one intended payment, booking, or message produces one result.
- ▸Read every error message as if you were an unfamiliar visitor.
common risk
A slow response makes a visitor click Pay twice, and the app creates two orders because both attempts are accepted.
what to do now
Create a repeatable mistake test for every action that changes a payment, booking, message, stock count, or customer record.
ask your AI
List every action in this app that creates or changes a payment, booking, order, message, stock count, or customer record. For each one, explain what should happen after a double-click, refresh, lost connection, unfinished attempt, missing information, and unusually long information. Then give me exact beginner-friendly test steps using made-up records and payment test settings.
Review small changes and keep checking
in plain words
Small changes are easier to understand, test, undo, and watch after the app becomes public.
Before publishing an AI-generated change, ask for a plain-language summary. It should say which screens changed, which people are affected, what information is read or changed, and which tests prove the expected behavior. When practical, publish one focused change at a time. Keep the last working copy and written steps for restoring it. If several unrelated changes are mixed together, you may not know which one caused a broken sign-in, missing booking, repeated charge, or exposed customer record.
Your review continues after the app becomes public. Open the public version after every important update and repeat its main visitor journey. Check reports from customers and investigate behavior that changed without a clear reason. The technical name for regularly watching important behavior is monitoring. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need to see your private code. This outside view supports your routine, but you should still test who can perform actions and where passwords, payment keys, and access codes are kept.
- ▸Request an explanation and test plan before publishing each important change.
- ▸Keep the last working copy and restoration steps.
- ▸Repeat the main public journey after publishing.
- ▸Continue checking over time instead of treating review as a one-time task.
common risk
A small change to a profile form also affects a shared sign-in rule, and new customers can no longer finish creating an account.
what to do now
Accept each important AI-generated change only after you understand its purpose, complete its test plan, and know how to restore the last working version.
ask your AI
Summarize the latest app changes in everyday language. For every changed part, list the affected screens, people, and information; give me exact tests to run before publishing and after publishing; and explain how to restore the last working version if a test fails. Also identify which public behaviors I should continue checking each week.
Quick checklist
- 01List what every screen should do and who should use it.
- 02Complete the main journey with a new test account.
- 03Try important actions with an account that should be refused.
- 04Confirm that each test account sees only its own information.
- 05Keep passwords, payment keys, and access codes out of anything visitors can download.
- 06Check that error messages do not reveal customer information or internal instructions.
- 07Repeat, cancel, refresh, and leave important actions unfinished.
- 08Ask your AI builder to explain every change and provide a test plan.
- 09Recheck the public app after every important update.
FAQ
Do I need to understand programming to use this routine?
No. Begin with screens, people, customer information, payments, and actions you already understand. Ask the AI builder to explain where each rule is enforced and how you can test it.
Should I use real customer information while testing?
No. Use invented names, new test accounts, harmless sample records, and payment test settings. Delete the test records when they are no longer needed.
What should I do if a password or payment key was publicly downloadable?
Stop using it, replace it through the company that issued it, place the replacement in the protected part of the app, and confirm that visitors cannot receive it.
How often should I repeat the routine?
Repeat the relevant checks before and after every important change, especially changes involving sign-in, payments, customer information, owner actions, or downloadable files. Continue checking the public app over time.