Check Your AI-Built App Before Customers Use It

Begin at the same public address a customer uses. Open the app in a new private browsing window so an old sign-in does not affect the test. Visit the welcome page, account-entry page, customer area, payment screens, forms, downloads, and help pages. Press every important button with safe test information. Write down what each action is supposed to show, save, send, delete, or charge. This gives you a visible map of the app before you examine how it was built.

Why does this matter? AI builders can leave behind an older page, an unfinished form, or a button that still performs a real action. A page does not become harmless just because it is missing from the menu. Developers call all the places where someone can interact with an app its attack surface. You do not need to memorize that term. The useful idea is that every reachable page or action needs a clear purpose, an expected result, and a check showing who should be able to use it.

Create two test accounts, such as Sam and Riley, and give them clearly different sample bookings, documents, and profile details. Sign in as Sam and try every normal action: view a record, edit it, delete it, and download it when downloads are offered. Sign out, repeat the checks as Riley, and confirm that Riley never receives Sam’s information. Also try opening an administrator page with a normal customer account. Use only invented test information, never a real customer’s records.

Signing in proves who is using an account, but it does not automatically prove that the person may use every record. The app must check the person and the requested item together each time information is viewed or changed. The technical name is authorization. A hidden button is not enough because someone may reach the same action another way. Ask the AI builder to explain the rule for each customer record, order, file, and administrator task, then make it create repeatable tests for those rules.

Trace what happens when someone starts a payment, cancels it, completes it, refreshes the page, or closes the window. Use the payment company’s test mode if one is available. A paid feature should remain locked until the payment company confirms that payment succeeded. The same principle applies when the app sends email, resets a password, or receives a form: delayed or repeated messages should not create extra orders, receipts, credits, or account changes.

Payment companies and other services often send an automatic notice to the app after an event. The technical name is a webhook. The app should verify where that notice came from and should safely recognize a notice it has already processed. Developers call that repeated-safe behavior idempotency. Actions that cost money or can be repeated quickly also need sensible usage boundaries. The technical name for one such boundary is a rate limit. It can reduce accidental loops, repeated clicks, and automated misuse without blocking ordinary customers.

Check the files and settings delivered when someone opens the public app. A visitor may not see their contents on the screen, but the browser can still receive and store them. A database password can open customer information. A payment key can create charges or refunds. An email access code can send messages from your account. A storage access code can open uploaded documents. These items must stay in the protected part of the app that performs work away from the visitor’s device.

A password or key that proves the app may use another service has a technical name: credential. Some developers also call particularly powerful credentials secrets. Public display settings, such as a business name, are different, but you should ask the AI builder to classify each setting instead of guessing. If a powerful password, payment key, or access code reached visitor downloads, moving it is only the first step. Replace it with a newly created one, update the protected setting, disable the old one, and test the related service again.

Before requesting a change, write down what must remain true. For example, customers see only their own bookings, paid access follows confirmed payment, and visitors cannot download a database password or payment key. Save a known working version and record how to return to it. Ask for one focused change at a time. After the AI builder finishes, have it explain what changed, which pages or actions may be affected, and which earlier checks should be repeated.

Keep a short review note containing the date, requested change, test accounts, pages checked, and results. Developers call repeating previously successful checks regression testing. This routine should continue for as long as the app changes. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need access to code that is not publicly delivered. That outside view complements, but does not replace, your two-account, payment, password, key, and access-code checks.