Most people who try your app the first time will be on a phone. Most people who build an app with Claude Code, Lovable, Base44, or Cursor do it on a laptop, inside a preview that is wide and already signed in. That is why the first real user says "the button is cut off" about a screen you were proud of an hour ago.
You do not need ten phones to catch that class of bug. You need a small set of widths, a signed-out start, and one job you can finish or fail. This guide is the method. It also shows how to run it as phone-sized browser sessions that sign up on their own, with screenshots, a replay, and a fix prompt you can paste back into your editor.
Buy a second phone later if you want. Do not wait for a collection before you look at a narrow window.
What actually changes when the screen gets narrow
A phone is not a shrunk laptop. The layout has to reflow, and several things that were fine in a wide preview break in predictable ways.
Sideways scroll. A row of logos, a pricing table, or a long word in a button is wider than the window. The page gains a horizontal scrollbar, or the edge of the button simply sits off to the right where a thumb will not find it. This is the single most common launch bug in AI-built layouts, because a prompt likes to place things in a row.
The button under the fold. On a laptop the hero shows the heading and the button together. On a phone a tall image pushes the button below the first screen. People who do not scroll never see the action. Your preview frame often starts scrolled to the interesting part, which hides the problem.
The covered submit. A sticky header or a chat bubble sits on top of the create button. In a wide window there was room. In a narrow window they occupy the same spot.
The tiny tap. Links in a footer sit on top of each other, or a text link is so small that the miss taps the wrong one. You can see this without a device lab: if you cannot comfortably tap it with a thumb in mind, it is too small. A practical check is whether the control has padding, not whether it matches a poster.
The vanishing label. Placeholders disappear while typing. On a phone the keyboard covers the hint you were going to scroll back to. A label that stays visible above the field survives the keyboard. A placeholder does not.
The menu that does not close. A full-screen menu opens and the close control is off the screen, or the page behind it still scrolls in a confusing way. Test open and close at a narrow width, not only the look of the icon.
The column that never stacks. The builder showed three cards in a row. On a phone they stay in a row and shrink until the words break one letter at a time, or they overflow. Stacking is the fix. You have to look at the narrow width to know the prompt forgot it.
The input that iOS zooms. Some phones zoom the page when a field's text is tiny. A width check will not always reproduce the zoom. If your fields use a readable text size, you avoid the worst of it. If a real phone on your desk zooms, that is a one-device check worth doing once, not a reason to own ten.
None of these require a different phone per brand. They require a narrow window and a task.
A small set of widths
Use this set. Stop there until these three are clean.
- Narrow, about 390 pixels wide and a tall phone height. This is the width to treat as "a phone." Do the first screen, the signup, and the first job here.
- Wide, the laptop window you already use, roughly 1280 pixels wide. This is where you build. Keep it so you notice if a mobile fix breaks the wide layout.
- Middle, only if your layout changes columns on tablets. Something around 768 pixels wide is enough to see a stuck two-column design. Skip it if your app is a single column at every size.
You can set a narrow width in desktop browser tools, or you can just make the window skinny. The number does not need to be magical. If the page works at a truly narrow width and at your laptop width, you have covered the gap where AI layouts fail.
Do the same job at narrow and wide. A screenshot of the home page at both sizes is not a test. A finished signup at both sizes is a test.
When you resize, reload the page. Some layouts measure the screen once and then stick. A window you drag narrower after load can lie. Start the visit at the width you mean.
What to do at the narrow width
Run this list signed out.
- Load the public URL. Confirm you are not already in the app.
- Look for sideways movement. Scroll. If the page moves left and right, find the row that is too wide.
- Find the main button without knowing where you put it. If it is below a tall image, decide whether the image should shrink.
- Open the menu. Tap each link that a first visitor needs. Close the menu.
- Start signup. Type in every field. Check that labels remain. Submit.
- Finish the first job, or write down the first screen that makes it impossible.
- Repeat the signup once at laptop width so you know the wide layout still works.
Write three lines when something fails: what you tapped, what the narrow screen showed, what you wanted. Those lines are the mobile bug report. Add the width you used. An editor that "makes it pop on mobile" with no width and no stuck step will rearrange the hero and leave the overflow.
A useful note sounds like this. "At 390 pixels wide, on the home page, the row of four logos does not wrap. The Start button is cut off on the right. Please stack the logos and keep the button fully on screen. Leave the desktop row as it is if it already fits at 1280." That is enough for Claude Code or Cursor. It is also enough for Lovable or Base44.
Let a phone-sized visitor do the job
Doing this by hand is the skill. Doing it only by hand is how you skip it on a tired night. Hand the narrow pass to a visitor who is not you.
Paste the URL. Persqo drafts three visitors. Each one has a device. You will often see a mix of phones and a laptop. Read the devices before you accept. If every draft is a laptop, edit one to a phone. If you have never checked a phone at all, make two of them phones. Edit the goals so one is signup, one is the price or the way to start, and one is the main button. Keep the goals able to pass or fail. The persona guide is the editing step. Accept once.
A visitor whose device is a phone, including the drafts that say iPhone or Android, gets a real browser at a phone size, 390 by 844. They click in that window. They can sign up like a new customer if that is the goal: test email, test password when the form asks, then the signup button. They will not pay or send a text. A visitor whose device is a laptop gets a wide window for the visit and is also checked at that same phone width, with a screenshot, so an overflow on the narrow layout is still recorded.
The report names overflow when the page is wider than the window. It attaches a screenshot. You can watch the replay and see the visitor miss a button that was off to the side, or scroll past a control the wide layout kept on screen. When the recording is video, you watch video. Either way you are looking at the session, not at a resized marketing mock.
The fix prompt includes the visitor and the device, so the editor sees that the bug was found at phone size. Paste it into Claude Code or Cursor. Add the sentence "keep the wide layout working" if you are worried the patch will smash the desktop. Run the same phone visitor again after the patch. Tick the phone pass only when that second run reaches the goal and the overflow note is gone.
This does not use your handset. It does not install anything on a phone. It also does not claim to be every phone. It is the width check, done in a real browser, with a signup that actually submits, and with a record you can watch. That is the part worth automating. The replay guide shows how to watch the narrow session without getting lost in the scrubber.
What a real phone still adds
Be honest about the gap so you do not pretend the width check is a device lab.
A physical phone adds the real keyboard, the real share sheet, the way a particular browser draws form controls, and the way a date or file field behaves. It adds text-message signup if you use that, which a practice visitor will not complete, because it will not send a text. It adds "add to home screen" and the safe areas around a notch if your header collides with them. It adds a flaky hotel network. The width check does not.
For a solo launch, cover the gap like this. Run the phone-width sessions until signup and the first job are clean. Then borrow one real phone, any recent one, and do the same job once in its browser. If you have an iPhone and you can borrow an Android, or the other way around, do the job once on each. Two real phones, one time, after the width is clean, beats ten phones used as a reason to delay.
If that single real phone finds a keyboard covering the button, fix that, and add a line to your notes. You still do not need a matrix of operating system versions for an app you built last weekend.
If you already own one phone, use it for the inbox check too. Open the confirmation email there, in a browser that is not signed into your builder. That single path, email link on a real phone, catches a class of bugs the width check is not supposed to catch.
A worked pass on a habit tracker
Made-up app, real method. You built a habit tracker in Lovable on a laptop. The preview's phone frame looked fine because you were signed in and the preview scrolled to the habit list.
You paste the public URL. You set the goals: phone visitor signs up and sees an empty habit list with a way to add one; laptop visitor finds what the app costs or how to start; phone visitor follows the main "Start" button. You accept.
The first phone session's screenshot shows the Start button half off the right edge. The logos under the heading are in a row that does not wrap. The report flags the overflow. The replay shows the visitor tapping where the button should be and hitting the edge of a logo instead. Signup never starts.
You paste the fix prompt and add "stack the logo row below 400 pixels wide, and keep Start fully visible." You do not ask for a new illustration. The second phone run reaches the form. A new screenshot shows the email label missing and the sticky header covering the last field. Second prompt, only the form. The third run creates the test account and shows an empty list with an add button.
The laptop visitor's phone-width check, the extra narrow screenshot on the wide session, confirms the home page no longer overflows. You borrow one phone from a friend, do the job once, and notice the keyboard covers the add button on the empty list. One more prompt: keep the add button visible above the keyboard area by letting the page scroll. You stop. You do not order a tray of devices.
The checklist version of these lines lives in the pre-launch checklist. Signup-specific breaks, including the ones that only show when the window is narrow, are in the signup guide.
Habits that keep mobile from rotting
AI edits regress. A prompt that adds a testimonial row will put it in a horizontal line because that is what you asked for on desktop. After any prompt that adds a row, a bar, or a new hero, rerun the phone visitor. The goal stays the same. The pixels are what changed.
Keep one screenshot of the clean narrow home page and one of the clean signup. When a later run flags overflow, compare. You will see the new row immediately. Put both screenshots' descriptions in the prompt if the editor cannot see your files: "a new row of quotes sits beside the button; stack it."
Do not "fix mobile" by hiding the signup button on small screens. That is a launch bug with extra steps. The narrow layout should complete the same job as the wide one. If a feature is not ready on a phone, remove the control everywhere, not only where it overflows.
You can ship a phone-friendly first version without owning a museum of hardware. Two widths, one borrowed phone, and a phone-sized visitor who signs up for real will show you the breaks that make a first user leave. Run that before you invite them.
Questions people ask
Is a narrow browser the same as an iPhone?
No. A phone-width browser shows layout, overflow, tap size, and whether signup can be completed in a narrow window. It does not show the exact keyboard of one brand of phone, a carrier text message, or a date picker that only exists on a physical device. For a first launch, the narrow window catches the bugs that stop people.
How many widths do I need?
Start with two. A narrow window about the width of a phone, and the laptop width you already build on. Add a middle width, around a small tablet, if your layout switches columns there. You do not need a device for every year of every brand.
Will Persqo use my phone?
No. A visitor marked as a phone uses a real browser at a phone size. A visitor marked as a laptop uses a wide window and is also checked at a phone width so sideways scroll is hard to miss. You watch the screenshots and the replay from your own computer.
What if the builder preview has a phone frame?
Use it as a sketch. Then run the same screen signed out, at a narrow width, starting from the public URL. Previews often stay logged in and often hide the page scroll. The bugs that matter live outside that frame.
Which mobile bugs should I fix before launch?
Fix sideways scrolling, a main button that is off the screen or covered, a form that cannot be submitted, and text that overflows the button. A tight margin can wait. A door that cannot be opened on a phone cannot.