Pre-release checklist for vibe-coded apps

This is the emptiest place. Login is usually built well; the boundary after login is often skipped. Create two accounts, then paste the address of data created by A into B's browser. If it opens, the screen was only hiding it. Open an admin URL directly from an ordinary account, and check whether the back button revives the previous screen after logging out. Walk the flows that can transfer an account — password reset and email change — separately. Where several roles exist, check each combination once.

Normal input is already covered by the act of building, so it is not what to test here. Submit with required fields blank. Put zero and a negative number in a quantity. Set a date in the past. Put a very long string and an emoji in a name field. Watch not whether the screen blocks it but whether the request is blocked when it reaches the server. An app validated only on screen accepts anything sent directly. Send the same request twice in quick succession and see whether two payments or two applications appear. If there is file upload, try one that exceeds the format and size limits.

External model calls, SMS, maps, translation — anything billed per call turns usage into an invoice. Count how many calls leave when a single screen opens. Calls repeated on every refresh, code that retries forever after a failure, and paths reachable by users who are not logged in are the three places money leaks. Set a ceiling per user and per day, and decide what to show when that ceiling is reached. A billing alert set in advance means you find out from a notification rather than from the invoice.

Cut the external integration and walk the same screen again. When nothing happens or the page goes blank, users repeat the action, and that repetition generates more charges and duplicate records. Check whether error messages expose internal paths or database statements. For flows that must not break midway — payment, saving — interrupt them and see what state remains when you start again. Check that failed requests are recorded in the log. What the user sees and what the log records are decided separately.

Write down what is collected in the order the screens ask for it. Delete anything collected but never used. Confirm where names, contact details, and payment information are stored and in what form, and whether personal data is mixed into values sent to external services. If the app sends conversation history to an external model, look at what travels with it at least once. Include whether there is a path that deletes the data when someone closes their account. Check whether uploaded files open for anyone who knows the URL.

Deployment is a verification target of its own, not a final gate. Search for access keys and passwords left in the code or the repository. Check whether debug screens opened for development and test accounts are still there. Confirm that test payment settings have been switched to live, that the domain and certificate are attached, and that there is a way back to the previous version when something breaks. If the failures here are scattered across several groups, read that as the scope for outside verification rather than something to patch alone.