Built an app with AI? Great. This is the most important thing to do before real users see it

You can build a working app in an evening with Claude Code, Lovable, Base44, or Cursor. The preview looks finished. The button you always click works. Then you send the link to one real person and they get stuck on a screen you have not opened in days.

That gap is the thing to close before anyone else sees the app. A test where someone who did not build the app tries to do the first real job, and you keep a record of what happened. You need one clear job, a few different visitors, and a report you can act on the same day. Then you turn that report into a fix you can paste back into the tool that wrote the code.

The builder is a weak first tester

You know the password you set. You know which button is real and which one is leftover from a prompt you tried last night. You know that the empty state is temporary. A new person knows none of that.

When you test your own app you walk the path you remember. You start on the right page. You skip the sentence that confused you yesterday because you already learned what it means. The app feels obvious because you are supplying the missing instructions from memory.

A new visitor supplies nothing. They read the first screen, pick a button, and stop when the next step is unclear. If signup fails, they do not open the database to check. They leave.

So the most important thing to do before real users see the app is to run the first job as a stranger. Treat your own memory as off limits. If a step only works when you already know the trick, the step is not done.

Pick the one job that matters this week

An app can do ten things. A first test should do one.

Write the job in a single sentence a stranger could attempt. "Create an account and add the first meal" is a job. "See if the app is good" is not. "Check the UI" is not. A job has a start, a finish you can point at, and a way to tell those two apart.

Good first jobs for an app you built with AI usually look like this:

• Create an account with an email and land on a screen that proves the account exists.
• Finish the first setup step, such as naming a project or adding one item.
• Find the price, or find a clear way to start, without guessing which plan is real.
• Recover when something is empty, such as a list with no rows, and still see what to do next.

Pick the job a real person must complete before your app has any chance of being useful. For a meal planner, that might be "sign up and save one dinner." For a booking page, "choose a time and leave a name." For a client portal, "open the latest file." You are testing the door, not the whole building.

If you cannot say what done looks like, you will not know whether a test passed. Write the done state before you open the app. "I can see my email in the header" is a done state. "It feels smooth" is not. A report that says the visitor never reached that screen is the one that decides whether you can invite someone tonight.

What you are looking for

You are looking for the first place a stranger cannot continue. That place is more useful than a pile of small opinions.

Watch for these, in this order:

• The first screen does not say what the app is, or what to do next.
• A button looks tappable and does nothing, or it opens a blank page.
• Signup asks for a field the visitor cannot fill, hides the error, or says success when no account was created.
• The page after signup does not prove that anything happened.
• On a phone-width screen, a button sits off to the side, or the page scrolls sideways.
• The words on the screen use a name you invented in a prompt, and a new person cannot tell what it refers to.
• A link in the header goes to a page that returns an error.

Write down the stuck step in three lines, even if a tool will also record it. What the visitor tried. What the screen showed. What should have happened. Those three lines are the seed of a fix prompt. The guide on turning bug reports into Claude Code fix prompts shows how to shape them so an editor obeys them.

Do not wait for friends to be the test plan

It is tempting to send the link to three friends and ask what they think. Friends are kind. They also share some of your context. They will say it looks great, then message you later because the signup email never arrived. That message is useful, and it arrives after you have already spent the ask.

A structured pass before that ask gives you a cleaner favor to request later. You will have watched the path through a visitor who is not you. The breaks that are simple to reproduce can already be gone. When a friend does try the app, their notes are about the product.

A practice session does not replace a real customer. A practice visitor does not have your customer's patience, their data, or their reason for showing up. It does catch the breaks that stop a real customer from ever becoming one: the signup that fails, the page that overflows a phone, the button that leads nowhere. Repeat the pass after any large edit. A later prompt can move the signup button while "only" changing an empty state.

How to run the pass by hand

You can do this yourself. The tool version is the same method with a better record. Open a private window, signed out, and start from the public URL. Make the window about as narrow as a phone for one pass. Try the job, and say the next click out loud before you make it. When you get stuck, write what you tried, what the screen showed, and what you expected. Then try a second goal, such as finding the price.

That notebook is already a test report. The weak part of doing it only by hand is you. You still know too much, and you will not keep the recording.

How to run the same pass in Persqo

Persqo runs that method with visitors that are not you. You paste the public URL. You do not verify the domain. Persqo reads the public page and drafts three visitors. Each visitor has a name, a role, a goal, a sense of how comfortable they are with software, and a device. You can edit the goals. You accept once. Then each visitor gets a real browser and tries the goal.

They can click and sign up the way a new customer would. If the goal is about signup and the page has an email field, the visitor fills it and submits the form. You may see the test address visitor@example.com in your user list. That is a real signup on your app, done by the session, not a picture of a form.

They will not pay. They will not send a text. They will not message a real person, delete an account, or change a password that is already in use. If the path reaches a page that asks for payment, the visitor stops before paying. You still learn that a new person can get as far as the paywall. You do not learn whether a card charge works. That is a later check, with a test card you control, if you even take payment yet.

You get a report when the run finishes. The serious problems come first. Each one can include a screenshot of the screen where it happened. You can watch a session replay of what the visitor did. When the run records video, that replay is a video. Otherwise you still get a replay you can watch click by click, plus the screenshots. You also get a fix prompt written so you can paste it into Claude Code or Cursor. The copy button is labeled for those editors. If you built the app in Lovable or Base44, paste the same prompt into that chat. The prompt is steps and a goal. It does not care which editor runs it.

The draft is editable on purpose. A page that says "Start free" may produce a visitor whose goal is to sign up, a visitor who looks for the price, and a visitor who follows that main button. The names and the exact wording come from your page, so they will not match a sample you saw in a tutorial. Read them. If a goal is vague, rewrite it until you could tell a pass from a fail. Then accept once. The guide on creating user personas is the longer version of that edit.

A worked pass on a meal planner

Here is the method on a made-up app, so you can see the shape before you do it on yours. This is an example you can copy as a pattern. It is not a report from a real customer.

The app is a meal planner built in Lovable. The home page says "Plan dinners without the mental load" and has a button labeled "Start free." You have been clicking that button while signed in as yourself. You have never finished signup in a private window.

The job you write: "Create an account and save one dinner." The done state: a screen that shows the account, with a way to add a dinner.

You paste the URL. The draft comes back as three visitors, because Persqo drafts three. You change the signup goal so it says "Sign up and reach a screen that shows the new account." You leave the price goal and the "Start free" goal. You accept once.

The signup visitor finds the email field. The label is missing, so the report notes an unlabeled field. The visitor still fills the email, because the field is an email input, and fills a test password if the form asks for one. The visitor clicks the create button. In this example the app shows a small note that says "Check your email" and then sends the visitor back to the home page, still signed out, because the confirmation page was never built. The goal is not reached. The report says the visitor got stuck and names the page. A screenshot shows the note. The replay lets you watch the click and the return to the home page.

The third visitor taps "Start free" on a phone-width screen. The button is partly off to the right because a row of logos does not wrap. The report calls out the overflow, with a screenshot. You do not need ten phones to see a page that scrolls sideways. One phone-width browser session is enough to prove the layout is wider than the window.

None of these findings require you to guess. Each one has steps, a page, and a picture. The fix prompt names the visitor, the goal, and the findings, and it tells the editor to patch the site so this visitor can finish the goal, without adding a way to skip payment, and without throwing away the current design.

What to do with the report before you invite anyone

Read the report from the top. The serious items are first. For each one, answer a single question: does this stop the job?

If it stops the job, copy the fix prompt and paste it into the tool you used to build the app. Then check the fix the way you found the bug. Run the same goal again. Do not declare it fixed because the code looks right in the editor. The visitor either reaches the goal this time or gets stuck again. The second report is your before-and-after.

A few habits keep the fix from becoming a new bug:

• Tell the editor which page to change, and tell it to leave the rest of the layout alone.
• Do not ask it to skip signup, hide the error, or pretend a payment happened.
• After the patch, click through once in a private window yourself. The replay is evidence. Your own eyes still help.
• If the second run gets stuck in a new place, fix that place before you add a feature.

When the main job completes for the visitors you accepted, you have done the thing this guide is about. Then send the link to one real person and ask them to try that same job. You will learn about wording and whether the idea is wanted. You will not be using them to discover that the create button goes nowhere.

If the run finishes without a clear pass or fail, tighten the goal and run it again before you change the layout.

What this pass will not decide

Three sessions will not tell you if people want the app, what to charge, or which headline is clever. They will not finish a real card payment or read a live inbox the way your customer will. If signup depends on a confirmation email, watch the session until the screen that says the mail was sent, then check the mail with an inbox you control. The practice session shows whether your app reached that screen.

The pass will not judge pages a public visitor cannot open. It starts from the URL you paste and stays on that site. If a page is behind a login and the public test is not enough, you can later give Persqo a test account. You can skip that until the public path is solid.

Skip the vanity list for tonight. A logo polish, a new illustration, or another feature on the far side of signup can wait. Those changes hide the door. Test the door. The pre-launch checklist is there when you want the longer list, after this first job is real.

A plan for the next hour

If you only have an hour, spend it in this order.

1. Write the one job and the done state.
2. Paste the URL and read the three drafted visitors. Edit one goal so it matches your sentence.
3. Let the sessions run. Do not sit beside them and help.
4. Read the stuck goals first. Copy the fix prompt. Paste it into Claude Code, Cursor, Lovable, or Base44.
5. Run the same goal again. If it is reached, write down what you changed in one sentence.
6. Only then send the link to one person, and ask them to try that job.

That is the most important thing to do before real users see an app you built with AI. The app can be rough. The first job cannot be a secret that only you know how to finish.

Questions people ask