FlawPilot
From the blog

Your App Looks Great on Your Laptop. Have You Opened It on a Phone?

Quick answer: apps built with AI tools usually look right on the screen they were built and previewed on, which is almost always a laptop. On a phone, the same app can have text that runs off the…

Virendra PatilSecurity research22 Oct 202610 min read

Quick answer: apps built with AI tools usually look right on the screen they were built and previewed on, which is almost always a laptop. On a phone, the same app can have text that runs off the edge, buttons too small to tap, menus that never open, and pages that scroll sideways. You can check this yourself in about ten minutes with your own phone and your browser's built-in device preview. A FlawPilot Site Health check in Mobile mode then scans every page the way a phone sees it, so you find the broken pages you didn't think to open.

For most products, a large share of visitors arrive on a phone, often from a link in a message, an email, or social media. That first visit is where people decide whether your product feels trustworthy. A layout that falls apart on a small screen doesn't look like a minor bug to them. It looks like a product nobody finished.

The hard part is that you rarely see it. You build on a laptop, you test on a laptop, and the AI tool's preview window shows you a laptop-shaped page. Everything looks done, so you ship.

This is part 1 of our series on what vibe-coded apps miss. If you're new to the series, start with the overview of what a frontend developer would check.

In short: "It looks good" only means it looks good on the screen you tested. Open every important page on a real phone before launch, and run a mobile scan to catch the pages you forgot.

What it looks like when mobile is broken

Mobile problems rarely crash anything. The app still loads. It just becomes awkward, confusing, or impossible to use. Here's what founders and their users tend to notice:

  • The page scrolls sideways. You swipe up to read, and the whole page wobbles left and right because something is wider than the screen. Often it's a table, an image, or a long line of text with no spaces, like a URL or email address.
  • Text is tiny or cut off. Headings get clipped, or body text is so small people pinch to zoom, which then breaks the layout further.
  • Buttons are hard to hit. Links and buttons sit so close together that a thumb taps the wrong one. Icons with no label are a guess.
  • The menu doesn't work. The navigation collapses into a hamburger icon on small screens, but tapping it does nothing, or the menu opens behind other content.
  • Pop-ups trap people. A modal or cookie banner is taller than the phone screen, so the close button is off-screen and can't be reached.
  • Forms are painful. The keyboard covers the field you're typing into, the wrong keyboard appears (letters instead of numbers for a phone field), or the submit button hides under the keyboard.
  • Things overlap. A fixed header or chat widget covers the content or the main call-to-action button.

Any one of these can be the reason a visitor leaves without signing up, and they won't send you a bug report on the way out.

Why AI tools miss it

This isn't the AI being careless. It's about what the tool can see and what it's asked to do.

It builds for the preview it's shown. Most AI app builders show a desktop-width preview by default. The AI and you are both judging the result in that one window. If it looks right there, the request is "done".

Prompts describe the happy path. You ask for "a pricing page with three plans side by side". The AI does exactly that. Three side-by-side cards are great on a laptop and cramped on a phone, unless someone also said what should happen on small screens. Nobody did, so the AI guessed, or didn't think about it.

Fixes pile up in one place. Every time you ask the AI to tweak a layout, it adjusts the code for that one change. Over many rounds, sizes get fixed to exact pixel widths, which look perfect at one screen size and overflow at another. Each change is fine on its own. Together they break the small-screen layout.

Real devices behave differently from previews. A browser window shrunk to phone width is useful, but it isn't a phone. Real phones have on-screen keyboards, notches, browser toolbars that appear and disappear, and touch instead of a mouse. Hover effects, which many AI-generated designs rely on, simply don't exist on a touchscreen.

A frontend developer handles this by habit. They design for small screens first, then check at a few common widths before calling anything finished. AI tools don't have that habit unless you ask for it.

Check it yourself in ten minutes

You don't need to read code for this. You need your phone, your laptop, and a list of your most important pages.

  • List the pages that matter. Your homepage, signup or login, pricing, the main screen people use after logging in, and checkout or payment if you have one. These are the pages where a broken layout costs you the most.
  • Open each one on your real phone. Not the preview, your actual phone, using the live link. Scroll the full length of every page. Watch for sideways wobble, clipped text, and anything overlapping.
  • Tap everything important. Open the menu, then close it. Tap every main button. Open and close any pop-up. Fill in and submit a form, watching where the keyboard lands.
  • Try it in your laptop browser's device preview. In Chrome, right-click the page, choose Inspect, and click the small phone-and-tablet icon at the top of the panel. You can now switch between common phone sizes. Try a small one too, since many people still use phones with compact screens.
  • Turn the phone sideways. Landscape mode is a quick way to spot layouts that only work at one exact size.
  • Ask someone else to try it. Hand your phone to a friend and ask them to sign up. Don't help. Where they hesitate or tap the wrong thing is where your layout is failing.

Write down each problem with the page name and what happened. That list is exactly what you'd hand to a developer, or paste back into your AI tool as a specific fix request.

How FlawPilot spots it

Checking by hand works for your five most important pages. The trouble is that most apps have more pages than you remember: old landing pages, settings screens, help articles, pages the AI generated for a feature you no longer use. Those still exist, and people still land on them.

FlawPilot's Site Health check crawls every page of your site and scores each one. You can run it in Mobile mode, which emulates a phone, or in Desktop mode. The same site often scores very differently on the two, which is exactly the gap this post is about.

Here's what you get from a Site Health report and how to read it:

What the report showsWhat it means for you
Scores per page for Performance, Accessibility, Best Practices, and SEOYou can see which specific pages are weakest on mobile, instead of one average that hides the bad ones
An overall score for the whole crawlA quick read on where the site stands, useful for comparing before and after a fix
Page screenshotsYou can see what each page actually looked like during the check, without opening it yourself
Findings ranked Failing, Needs improvement, or DiagnosticStart with Failing. Those are the problems most likely to affect real visitors
Mode shown on every reportYou always know whether a score was measured as mobile or desktop, so you don't compare the wrong numbers

A useful habit: run Site Health once in Mobile mode and once in Desktop mode, then compare. Pages that score well on desktop but poorly on mobile are your mobile problem list, already sorted for you.

One thing worth knowing: if a score shows as "not assessable", that's different from a zero. It means that category couldn't be measured on that page, not that the page failed.

Automated checks and your own thumb test work best together. The scan finds every page and flags measurable problems. Your manual check catches the human things, like a button that technically works but is confusing to find. You can run a FlawPilot scan on your site to see where you stand.

What "fixed" looks like

When you hand this to a developer, or ask your AI tool to fix it, here's how to tell the work is actually done:

  • No sideways scrolling on any page, at any common phone size.
  • Text is readable without zooming, and nothing is cut off.
  • Buttons and links are easy to tap with a thumb, with enough space between them.
  • Menus, pop-ups, and forms all work by touch, and every pop-up can be closed on a small screen.
  • The mobile Site Health scores move up on the pages that were failing, and the Failing findings list gets shorter.

Ask for the fix to be checked at more than one screen size. A fix that only makes things work on your phone can easily break them on a different one.

Urgent or cosmetic?

Not every mobile issue needs fixing tonight. A simple way to sort them:

PriorityExamplesWhy
Fix nowSignup, login, or checkout doesn't work on a phone. A pop-up can't be closed. The main button is hidden or unreachable.People literally can't become customers
Fix this weekSideways scrolling, clipped headings, buttons too close together on key pagesIt still works, but it looks unfinished and loses trust
Fix when you canSlightly awkward spacing, a less-visited page that's a bit crampedWorth tidying, but it isn't costing you signups

Frequently asked questions

It means the app was built to adapt to different screen sizes, not that every page was checked at every size. Responsive layouts still break in specific places, especially after many rounds of edits. The only way to know is to look on a real phone and scan every page.

Final Thoughts

Your laptop is the one screen your users are least likely to see your product on first. Vibe-coded apps are built and judged in a desktop preview, so mobile problems are not a sign you did something wrong. They're simply the part nobody looked at.

The fix starts with looking. Open your key pages on a real phone, tap through the things that make you money, and write down what breaks. Then run a mobile scan so the pages you forgot about get checked too. Once you've done that, your product will hold up on the small screen where most people meet it first.

How FlawPilot helps

FlawPilot finds security and quality issues in your AI-built app and shows you how to fix them. It checks your deployed site across security, performance, infrastructure, and SEO, and scans your source code for vulnerabilities, hardcoded secrets, and vulnerable dependencies.

Every finding is prioritized and explained in plain English, with the actual fix: the configuration change, DNS record, security header, or code change needed. For supported findings, AI-powered guidance adds step-by-step instructions and suggested code fixes.

Connect your Git provider to scan your repository alongside your live site, so application findings, code vulnerabilities, secrets, and dependency issues all land in one place.

It fits your existing workflow too: a REST API for scores and findings, an embeddable security badge, and an MCP server so tools like Claude, Cursor, or ChatGPT can read your findings and help you work through them.

The boundaries are clear: the public website scan reads only publicly accessible signals, with no agent or credentials required, and source-code scanning is opt-in and read-only. Fixes are never applied or merged without your review.

Vibe Coded App ReviewMobile Responsive DesignAI App BuilderMobile UsabilityFrontend Checklist

Verify your AI-generated app is production-ready.

117 security checks in 60 seconds - free, no account needed.

Scan one page

Enter a URL - no account, no install.

Run a Site Health check

Requires a free account

Crawls every page we can reach and scores each one, so a slow template deep in the site stops hiding behind a healthy homepage.

Scan your source code

Requires a free account

Connect a Git provider to check for vulnerabilities, secrets, and risky dependencies.

Featured on