What to Check Before Anyone Can Use Your AI-Built App
Your app may look ready while still showing the wrong customer information, accepting an unconfirmed payment, or giving ordinary users staff powers. Run these practical checks before sharing it publicly.
before you start
Before inviting real people, test what a stranger, a customer, and a staff member can see and change. Repeat these checks whenever the app changes.
See what a stranger can reach
in plain words
Use the public app without relying on what you remember from building it.
You already know where every button is supposed to lead, so your mind may quietly fill in missing instructions or overlook an open page. A new visitor will not do that. Open a private window in Chrome, Safari, or another browsing app and visit the same public address customers will receive. Start while signed out. Try registration, entering an account, leaving an account, resetting a password, contacting support, and deleting an account. Record the page address, the account you used, what you expected, and what actually happened. Use invented names and harmless sample information rather than real customer details.
Next, create two ordinary accounts with different email addresses. Give them obviously different sample orders, messages, profiles, or projects. While using the first account, try to open the second account’s information, including by changing a number or name in the page address. Each person should receive only the information and actions intended for that person. The technical name is authorization: the app checks what an identified person is allowed to see or change. This check must happen when information is requested or changed; merely hiding a button does not provide protection.
- ▸Test while signed out and with two separate ordinary accounts.
- ▸Use only invented names and harmless sample information.
- ▸Save the page address and result of every surprising test.
common risk
A customer changes a number in a page address and sees another customer’s order, message, or profile.
what to do now
Complete the two-account test for every important kind of customer information before sharing the app publicly.
ask your AI
Review my entire app using two ordinary test users. Make each signed-in user able to view, create, change, and delete only records that belong to that user. Deny access to every other customer’s records, including when someone changes an ID in a page address or opens a saved address directly. Add automated tests for these rules and give me a plain-language list of every page and action you checked.
Keep passwords and payment keys away from visitors
in plain words
A visitor should never receive anything that can open customer information, send paid messages, or spend money.
An AI builder may place some app files on each visitor’s device so pages can appear and respond to clicks. Chrome or Safari must download those files, which means a curious visitor can inspect them even when they are not shown on the screen. Do not place a database password, payment key, email-service password, AI-provider key, or powerful access code in those downloaded files. The place that stores organized app information has the technical name database. A protected computer that performs work away from the visitor’s device is called a server. Passwords and powerful keys belong in protected settings used only by that computer.
Ask your builder to inspect downloaded files, browser-visible settings, error messages, forms, and activity records. It should search for passwords, payment keys, reset links, full payment-card details, identity documents, and codes that allow account entry. If a password or key was ever sent to visitors, moving it is not enough: replace it in the company dashboard that issued it, update the protected setting, and test the connected feature again. Developers call this rotation, which means cancelling the old password or key and creating a new one. Keep test payment settings separate from real payment settings so experiments cannot create real charges.
- ▸List every password, payment key, and powerful access code used by the app.
- ▸Replace anything that was ever included in a public page or downloadable file.
- ▸Keep testing settings separate from settings that affect real money and customers.
common risk
A real payment key is included in a file downloaded by every visitor, allowing another person to use the payment account.
what to do now
Ask the builder to identify where every password and powerful key is stored, then replace anything that visitors may have received.
ask your AI
Inspect every file and setting that a visitor’s browser can receive. Find database passwords, payment keys, email-service passwords, AI-provider keys, password-reset links, and account access codes. Move them into protected server-only settings. For anything that may already have been public, name the provider, explain exactly where I should replace it, and do not print the full value in your response or activity records.
Make sure ordinary users cannot control the app
in plain words
Removing a menu button is not enough; the app must refuse the action itself.
List the pages and buttons that can affect many people or money: user management, staff invitations, content publishing, price changes, refunds, subscription changes, customer exports, and service settings. Sign in with an ordinary test account and try each direct page address. Also try submitting the related form or action if your testing environment makes that safe. The app should refuse the request without revealing customer information. Repeat the test with each staff type. An owner may need every power, while support staff may need to view an order but should not necessarily change prices or invite another owner.
The simple rule is to decide permission when the action happens, not only when the page is drawn. The technical name is role-based access control: the app gives different allowed actions to roles such as owner, support worker, and customer. The computer doing protected work must enforce the decision because a visitor can alter or bypass what appears on a screen. Keep the number of powerful accounts small, use a separate owner account for rare administrative work, and remove former helpers promptly. Record the expected permissions in a short table so future AI-made changes do not quietly broaden them.
- ▸Try direct page addresses with an ordinary account.
- ▸Check refunds, exports, prices, publishing, invitations, and settings separately.
- ▸Write down what owners, staff members, and customers may do.
common risk
Customers cannot see the price-editing button, but someone who knows the page address can still change a product’s price.
what to do now
Test every powerful page and action with an ordinary account and record that the app refuses it.
ask your AI
Create a permission table for owner, staff, and customer accounts in my app. Cover user management, staff invitations, billing, refunds, exports, publishing, price changes, subscriptions, and settings. Enforce each permission on the protected server when the action happens, not only by hiding buttons. Add tests proving that an ordinary customer is refused when opening each page directly or sending the same request another way.
Confirm every file and payment before trusting it
in plain words
Uploaded documents and payment messages should affect an account only after the app checks them.
If customers can send photos, résumés, invoices, or identity documents, upload a harmless sample through the first test account. Try opening it through the second account and while signed out. Both attempts should be refused unless sharing was intentionally enabled. A long or hard-to-guess file address is not protection by itself. Set reasonable allowed file types and sizes, rename stored files when appropriate, and avoid showing a new file until required checks finish. The technical name is file access control: rules that decide which person or staff role may receive a stored file.
For payments, the app should not grant paid features merely because a browser reports success or returns to a thank-you page. The payment company should send confirmation directly to the protected computer running the app, and the app should verify where that message came from. The technical name for the incoming payment notice is a webhook, and developers call checking its proof webhook verification. Use the payment company’s test mode to try success, cancellation, failure, a repeated notice, and a delayed notice. Compare each result with the company’s dashboard. Repeated notices must not create repeated credits, orders, or refunds.
- ▸Test one harmless file with two accounts and while signed out.
- ▸Confirm that an unconfirmed payment cannot unlock paid features.
- ▸Test successful, cancelled, failed, repeated, and delayed payment updates.
common risk
A customer uploads an invoice, and anyone who receives its storage address can open it without entering an approved account.
what to do now
Complete one file-isolation test and the full set of payment tests before accepting real customers.
ask your AI
Review all uploaded-file and payment flows in this app. Allow each file to be opened only by its owner and specifically approved staff, even if another person knows the file address. Validate permitted file types and sizes. Grant or remove paid access only after a server-to-server payment update has been verified with the payment provider. Add tests for success, cancellation, failure, duplicate updates, delayed updates, and attempts to open another user’s file.
Plan how you will notice and recover from problems
in plain words
Know how to spot trouble, pause a risky feature, and return to a working version.
Real visitors will create combinations you did not try. Decide what deserves attention: repeated failed account entry, many password resets, unusual changes to customer accounts, payment errors, broken uploads, and customer reports. Keep enough history to understand an incident without recording passwords, full card details, reset links, identity documents, or account entry codes. The technical name is logging: keeping a record of important events. Give access to those records only to trusted people, decide how long to keep them, and create alerts for patterns that need a human response rather than for every harmless mistake.
Write a one-page recovery plan before opening registration. Name the person who can make urgent decisions, explain how to stop new registrations or pause payments, preserve a known working version, and document how to restore saved data. Test restoration with harmless sample information; an untested backup is only a hope. Review these checks again after important changes to accounts, payments, files, staff powers, or customer information. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need private code, and its outside findings complement rather than replace your own account, payment, file, and recovery tests.
- ▸Choose who receives reports and who can pause risky features.
- ▸Practice restoring harmless sample information from a backup.
- ▸Repeat public checks after every important change.
common risk
A change leaves customer details visible after sign-out on a shared computer, but nobody knows how to pause the affected feature or restore the last working version.
what to do now
Write and rehearse a one-page response plan before opening registration to the public.
ask your AI
Create a one-page launch response plan for this app. Include safe event records that never store passwords, full card details, password-reset links, identity documents, or account access codes; alerts for repeated account, payment, and upload failures; named steps to pause registrations, payments, and risky features; a backup restoration test using sample data; and exact steps to return to the last known working version. Finish with a recurring checklist for changes to accounts, customer information, files, payments, and staff powers.
Quick checklist
- 01Create two ordinary test accounts and confirm that neither can see or change the other account’s information.
- 02Open every customer page while signed out and record anything that remains visible.
- 03Confirm that an ordinary account cannot open staff, billing, refund, export, or settings pages.
- 04Look for browser-visible passwords, payment keys, email-service passwords, and access codes.
- 05Test password reset, sign-out, and account deletion from beginning to end.
- 06Upload a harmless sample file and confirm that only the intended account and approved staff can open it.
- 07Complete a test payment and confirm that paid access changes only after the payment company confirms the result.
- 08Write down how to pause risky features, restore working data, and return to a known working version.
FAQ
Do I need to know programming to run these checks?
No. Use two test accounts, a private browsing window, harmless sample information, and the paste-ready requests above. Ask your AI builder to explain every result in plain language.
Does an account-entry screen protect customer information by itself?
No. It may identify the person, but the app must separately check which information and actions that person is allowed to use.
What should I do if visitors may have received a payment key?
Remove it from public files, replace it in the payment company’s dashboard, save the replacement in the protected setting, and repeat payment tests. Treat the old key as unusable.
Can an outside check replace my own testing?
No. An outside check can find problems visible in the public app. You still need to test real account, file, payment, staff, and recovery journeys.