Short answer: write down three kinds of visitors, for example a first-time buyer on a phone, a returning customer, and someone comparing you with a competitor. For each, walk the path they would take on the live site, in a private window, and note every moment of doubt. Then ask Claude Code to turn those paths into end to end tests on a phone viewport and to fix the issues you found, one at a time. Unit tests tell you the code works; this tells you a stranger can use it.
Step 1: three visitors, in one line each
- "Dana, 34, found us from an Instagram ad on her phone, wants to know the price before she signs up."
- "Avi, returning customer on desktop, wants to change his booking."
- "Noa, comparing us with two competitors, looking for proof we are real."
Our guide to personas for AI-built apps explains how to write them.
Step 2: walk each path on the live site
Use the deployed URL, not localhost, in a private window, on a real phone for the mobile persona. For each step write down what you expected, what happened, and how long you hesitated. Look for:
- A first screen that does not say what this is or what it costs.
- Buttons hidden below the fold, under a cookie banner or a chat bubble.
- Forms with unclear labels or errors that do not say what to fix.
- Dead ends: a page with no next step.
Step 3: let Claude Code turn paths into tests
Prompt: "Write Playwright end to end tests for these three paths, on a 390 by 844 viewport and on desktop, against the staging URL. Do not submit payments or send emails to real addresses; stop before the final submit or use test accounts. Run them and show me the results."
Run them after every deploy. If a test fails, the path broke for a real visitor too.
Step 4: fix one finding at a time
Give Claude Code one finding per prompt, with the page, the step, what you expected and what happened. Small prompts give small, reviewable diffs. Our guide to turning bug reports into Claude Code fix prompts has a template.
Step 5: ask someone who did not build it
You know where every button is. A friend, a customer or a paid tester does not. Give them the persona and the goal, not instructions, and watch without helping. Session replay can show you the same thing at scale after launch, as explained in session replay before launch.
Step 6: keep the rules in CLAUDE.md
Add your test commands and rules to CLAUDE.md, for example "run the end to end tests before saying a change is done", so Claude Code follows them in every session.
Where Persqo helps
You can do all of this with Claude Code and a phone. Persqo does the stranger part for you:
- Paste the Persqo prompt into Claude Code and your app gets a Persqo admin page at /admin/persqo.
- Persqo drafts three visitors you can edit, runs a real browser session for each on desktop and mobile, and returns screenshots, a replay and findings. Each finding comes with a fix prompt for Claude Code.
- Persqo fills in forms but does not send them unless you opt in. There is no verification step for you: Persqo confirms the site is yours in the background, and it stops before payment.
- One click: on a Next.js or Vite app, the Persqo fix runtime the prompt adds applies the home page title and description, business and FAQ schema and llms.txt, each with Undo. Next.js shows them within a minute, Vite at your next build.
- Connect your repository and Persqo opens a pull request for file fixes such as llms.txt and robots.txt. You merge it.
More on Persqo for Claude Code.
Sources
- How Claude remembers your project, Claude Code docs, checked November 6, 2026
- Playwright: writing tests, Playwright docs, checked November 6, 2026
- Playwright: emulation, Playwright docs, checked November 6, 2026
Last updated: November 6, 2026.
Questions people ask
Are Claude Code's own tests enough before launch?
They are necessary but not enough. Tests check the behavior you thought of. A stranger brings a different phone, different words and no context. Add at least one walk-through of the main paths on the live site by someone who did not build it.
Should I ask Claude Code to write Playwright tests?
Yes, for the two or three paths that make you money, such as signup and checkout. Keep them on the live or staging URL, on a phone viewport, and run them after every deploy. Do not let them submit real payments or emails to real people.
What is a test persona?
A short description of a real kind of visitor: who they are, what they want, what device they use and what worries them. Testing as three different personas finds problems that one developer testing their own app never sees.