You've got a login, a dashboard, a pricing page and an "Upgrade to Pro" button. Someone in a group chat asks when you're launching. You're still checking whether Pro actually does anything besides changing the label next to the avatar.
That's exactly where I'd start. Then I'd have someone create an account and do what the app promises in its description. Without you leaning over their shoulder telling them where to click and which button not to touch yet.
You can build a solid product with AI today. You can also click through your own app ten times and keep testing the same comfortable path: your account, a bit of sample data, the preview already open. Everything else only shows up once real people use it.
You don't need to order a full audit right away. Check what happens when a user arrives from outside, saves their own data, comes back after a break or pays. On a plain website a lot of this doesn't apply. What's left is links, subpages, contact, and a phone that has to handle all of it.
First, get out of the editor
Open the published URL in a private window. Go straight to a subpage and refresh it. Create a new account, confirm the email address, go through a password reset. Check where you land after signing in through a third-party provider.
A test URL can be left behind in the auth configuration. Then a correctly written flow ends with a redirect to the wrong domain or to localhost, the local address on your computer. Watch the address bar after every redirect like that.
On a site without accounts, walk the path from landing to contact or checkout. Click "See the offer", open the linked file, send a test message and check that it actually arrives. If you have to tell someone "just start from the homepage, otherwise it breaks", you've found the first thing to fix.
"Done." Fine, show me the file
After an export, open the result. Check that your data is in it and that it respects the selected filter. Change the date range and compare both files. When you save a project, refresh the page, sign out and come back. Promising sync? Open the project on a second device too.
I'd spend more time on reports. A wrong result can look perfectly normal: a nice chart, two decimal places, a downloadable PDF. Say the database holds 5,000 orders, the app fetches the first 1,000 and calculates total revenue from those. The chart still renders. With five test orders you never even had a chance to notice the report is swallowing most of the data.
Ask the agent to check exactly what the summaries are calculated from and whether the export covers all results or just the open page of the table. Compare against a dataset where you know the answer. An empty list is useful too: without sample records you immediately see what the app shows a new user.
Then interrupt an operation. Turn off the network while saving, or simulate a service error on a test copy. What's left after a refresh? Did the entry disappear even though it said "Saved"? Did clicking again create two orders? Can you retry without retyping everything?
This test matters most when one action does several things at once: saves a project, uploads a file and starts a generation. Check with the agent what the app does when the first step succeeds and the second one fails. The result should be recognizable and recoverable, including after reopening the page.
Create a second account
In your own test app, create users A and B. On account A, add a private project. Copy its URL, sign in as B and try to open it, edit it or download an attachment. In a team app, run the same test between two organizations.
A's private data must stay out of B's reach. Check this even when B's project list is empty. The list can correctly hide other people's entries while the direct URL still opens them.
The agent should check permissions on the server request itself, including file downloads and exports. Have it also try calling a paid feature from a free account and an admin action from a regular one. These are tests on your own test data; you don't need real customers to run them.
The customer paid and closed the tab
They should get what they bought even if they never come back to the "Thank you" screen. If it's displaying that page that grants the plan, fix the integration before you start selling.
Base access on the transaction confirmation from the payment provider. If you use webhooks, the notifications sent to your server, account for redelivery and for events that arrive late or out of order. Two notifications for one purchase must not add two credit packs.
In test mode, buy a plan and check it after signing in again. Then test without returning to the site, with a failed payment and with a repeated notification. When a subscription is cancelled, compare the moment access is removed with what your offer promises. If you sell a full month, just clicking "Cancel renewal" shouldn't take away the days already paid for.
Give these rules to the agent before it makes fixes. Don't leave it to decide what you actually sold.
The user is on the free plan. You get the API bill
For image generation, file analysis or model calls, check who can trigger expensive operations. The server should verify the user and their quota on every request. Hiding the API key won't help if the function using that key accepts jobs from anyone.
Set a small limit on a test account. Use it up, try again, then test two simultaneous requests on the last remaining operation. Also try it while signed out. That's enough to start, without running an expensive load test.
Check file sizes and job length separately. Five calls a minute can be an expensive limit if each one processes a huge document. You need control over the user's quota, the request rate and total spending.
After a fix, go back to what used to work
A change to sign-in means re-checking an older account and the password reset. After a payment change, go back to the free plan and an existing subscription. The agent may touch shared code and fix one path at the expense of another.
Also run the main action on a phone. With the keyboard open, longer text and an empty list. Check that you can get to the end without hunting for a button that slid off the screen.
With a weaker model, split the work into areas: saving, permissions, payments. A stronger one can take a bigger scope. Either way, accept the work based on concrete results. "Permissions checked" doesn't say much. You want to know which account did what, what it got back and what happened after the fix.
A prompt to check your project
Paste it into an agent that has access to your project. First it should figure out what you built and what a user should be able to do. Then run the relevant tests, document the problems and repeat them after fixing.
Review this website or app before it is shown to users. Match the scope to the actual project. Do not invent bugs or missing features. Work on a local or test copy with test accounts. Do not deploy changes, modify production data, run real payments or send real messages. Use the available sandbox when testing external services. Do not reveal secrets in the report. 1. UNDERSTAND THE PRODUCT From the code, determine: the type of app, its main promise, user roles, how data is stored, integrations and deployment. Name the three most important user paths. Check existing tests and the results of available scanners. Mark areas that don't exist as not applicable. 2. CHECK THE OUTCOMES Walk the paths from entry to the actual result. Check buttons, links, search, filters, export and saving where present. Confirm the file contents, the database state or the test service, not just the success message. Compare normal data, no data and a larger dataset. Check pagination, completeness of statistics, refreshing and opening subpages directly. 3. CHECK ACCESS BOUNDARIES Use only your own test accounts: user A, user B and the relevant roles or organizations. Check reading, editing, files and export across accounts. Check server operations while bypassing the UI, including with no session and without the required plan. Account for intended sharing. Do not treat a hidden button as security. 4. CHECK MONEY AND INTEGRATIONS If present: check a confirmed and a failed payment, a repeated or late event, the correct access period after cancellation, and a customer who never returns to the site. Verify webhook signatures and protection against the same operation taking effect twice. Check server-side usage limits, concurrent requests and error handling. Distinguish public keys from secret ones. Do not run expensive load tests. 5. REPRODUCE AND DOCUMENT For each problem give: the scenario, expected and actual result, evidence and the cause in code or configuration. Separate confirmed bugs, risks that need a test and things not checked. Prioritize access to other users' data, data loss, payment errors, uncontrolled costs and anything blocking the main action. 6. FIX AND REPEAT Make minimal fixes for reproduced problems. Keep the design, existing safeguards and business rules. Do not disable validation or access control to make a test pass. Then repeat the identical scenarios and the three main paths, including on a narrow screen. Where a business decision is unclear, leave a specific question. Finish with a report: problem, fix, retest, evidence. List missing access and manual tests. Reading code is not a completed test. Without access to a browser, backend or sandbox, do not claim an area works. Emulation does not replace checking on a physical phone.
If the agent didn't have access to a browser, the server or test payments, the report should end with a list of things left to do. Go back to it before you let people in. Especially for the feature you want to charge money for.