The Errors Your Users See and You Don't

Quick answer: every browser keeps a hidden log called the console, and when something on your page fails, it writes an error there instead of showing you a message. Apps built with AI tools often ship with errors in that log that the builder never sees, because the app looked fine in the preview. Those errors can mean a button silently does nothing, a section never loads, or a payment script fails on some browsers. You can check for them yourself in about five minutes by opening your browser's developer tools, and a FlawPilot Site Health check reports them for every page of your site under Best Practices.

The tricky part is that console errors are invisible by design. A visitor doesn't get a red warning box. They click "Sign up", nothing happens, and they leave. From your side, the app "works", because when you tested it, you tested the path that happened to work.

This is part 3 of our series on what vibe-coded apps miss. If you haven't read the overview, start with what a frontend developer would check in your vibe-coded app.

In short: a page that looks fine can still be broken underneath. The browser console tells you what failed, and checking it on every page, not just the homepage, is one of the cheapest quality checks you can do.

What It Looks Like

Console errors rarely announce themselves. Instead, they show up as small, confusing symptoms that are easy to blame on something else:

• A button that does nothing. The click handler crashed before it could run, so the form never submits.
• A section that stays empty. A list of products, a dashboard chart, or a pricing table that should load from your backend just never appears.
• A page that works once, then not again. Refresh it, navigate away and back, and part of it is gone.
• "It works for me." It works in Chrome on your laptop, but a customer on Safari or an older phone reports that checkout is broken.
• Missing images or fonts. A file the page asks for doesn't exist anymore, so the browser logs a "not found" error and shows a blank box or a fallback font.
• A browser warning about security. The page loads over HTTPS but quietly pulls an image or script over plain HTTP, and the browser blocks it or flags the page.

If you've ever had a user tell you "the button is broken" and you couldn't reproduce it, there's a good chance the answer was sitting in the console.

Why AI Tools Miss It

This isn't a case of the AI writing bad code on purpose. It's about how vibe coding works.

The preview is the happy path

When you build with an AI tool, you test by clicking around the preview. If the screen looks right, you move on. Nobody tells the AI to open the console, so errors that don't visibly break the screen in that moment go unnoticed. Many errors only surface in specific conditions: a slow network, a logged-out user, an empty database, a different browser.

Each prompt changes code the AI can't fully see

Over dozens of prompts, an AI tool rewrites components, renames things, and swaps libraries. Old code that referenced the previous version can stay behind. A component tries to read data that's now shaped differently, crashes, and the browser logs the error. The AI has no reason to look for it unless you describe the symptom.

Third-party scripts fail quietly

Analytics, chat widgets, payment forms, and embedded maps are often pasted in as a snippet. If the key is wrong, the domain isn't allowed, or the script is blocked, it fails in the console and the rest of the page carries on. You may not notice your analytics have been empty for weeks.

"Works on my machine" is still true

Your laptop has a fast connection, a modern browser, and you're probably logged in as the admin. Real visitors have none of those guarantees. Errors tied to permissions, caching, or browser differences simply never trigger for you.

Check It Yourself

You don't need to read code to do this. You only need to open the panel the browser already has and look for red.

• Open your live site in Chrome, not the AI tool's preview. The deployed version is what users get, and it can behave differently.
• Open developer tools. Right-click anywhere on the page and choose "Inspect", or press F12 (on a Mac, Cmd + Option + I). Click the Console tab.
• Reload the page with the console open. Errors that happen during loading only appear if the console is already watching. Red lines are errors. Yellow lines are warnings, worth noting but usually less urgent.
• Do the things a user does. Click your main buttons, open the menu, submit the signup form with fake details, go to pricing, log out and log back in. Watch for new red lines after each action. An error that appears right after you click a button is a strong sign that button is broken for someone.
• Repeat on your important pages. Homepage, pricing, signup, login, checkout, and the main screen people see after logging in. Errors on one page say nothing about another.
• Try a second browser. Open the same pages in Safari or Firefox, or on your phone. Something that's clean in Chrome can fail elsewhere.

Take a screenshot of any red lines you find, along with the page and the action that triggered them. That's exactly what a developer, or your AI tool, needs to fix it. Pasting the exact error text into your AI builder with "this error appears when I click Sign up on the live site" is far more effective than "the button is broken".

How FlawPilot Spots It

Checking six pages by hand is manageable. Checking every page of your site, every time you ship a change, isn't. That's where a FlawPilot Site Health check helps.

Site Health crawls every page of your site, not just the homepage, and runs a Lighthouse-based audit on each one. You choose whether it emulates a mobile or desktop visitor, since the same site can behave very differently on each. One of the four categories it scores is Best Practices, which covers the kind of problems this post is about, including:

• Errors logged to the browser console while the page loads
• Whether the page is served securely over HTTPS, and loads its resources securely too
• Use of deprecated browser features that browsers are phasing out and may stop supporting

How to read the report

• Best Practices score per page. Every page gets its own score next to Performance, Accessibility, and SEO, plus an overall score for the site. A page that scores noticeably lower than the rest is where to look first.
• Findings ranked by severity. Each finding is labelled Failing, Needs improvement, or Diagnostic. Start with Failing. Diagnostic items are reported for context and aren't a pass or fail on their own.
• Page screenshots. Each crawled page comes with a screenshot, so you can see which page a finding belongs to without guessing from a URL.
• "Not assessable" is not zero. If a category couldn't be measured for a page, the report shows it as not assessable rather than as a failing score. That's worth a look, but it's a different problem from a genuine failure.

Running it after each significant change gives you a quick before-and-after: if the Best Practices score drops on the pages you just touched, something new is probably logging errors.

One honest limit: an automated crawl sees what happens when a page loads. It doesn't fill in your forms or click through your checkout. Use the report to catch page-level errors across the whole site, and keep the manual "do what a user does" check from the section above for your most important flows.

What "Fixed" Looks Like

When a developer or your AI tool says the errors are fixed, here's how to judge it:

• The console is clean on load. Reload each key page with the console open. No red lines.
• The console stays clean when you use the page. Clicking buttons and submitting forms doesn't produce new errors.
• The fix addressed the cause, not the message. A quick "fix" sometimes just hides the error by catching it and doing nothing. The real test is whether the broken thing now works: the button submits, the section loads.
• Your Site Health Best Practices scores went up, and the Failing findings you started with are gone on the next check.

Urgent vs. cosmetic

Not every console message deserves the same attention.

Final Thoughts

The console is the browser telling you, in plain text, what went wrong. Vibe-coded apps often ship with that log full of problems, not because anyone ignored them, but because nobody opened it. The preview looked right, so the work felt done.

Five minutes with developer tools on your key pages will tell you more about the real health of your app than another hour of clicking around the preview. And when your site has more pages than you can check by hand, a site-wide scan that scores Best Practices on every page turns "I hope it works" into a list of specific things to fix, in order.