How to Read Error Messages:Any Error in 30 Seconds
How to read error messages when your AI-built app breaks: open the browser console, decode the first line and the file name, and fix errors in 30 seconds.
How to read error messages: you are not stuck — you just cannot see the error. Every time your AI-built app "mysteriously" breaks, it writes an exact explanation of what went wrong to the browser console. Open the console with one keyboard shortcut, read the first line and the file name, and you can decode almost any error in 30 seconds — no engineering degree required.
This is the single highest-leverage skill for a non-technical founder building with AI. Not because you will fix every error yourself, but because the difference between "it's broken, help" and pasting the exact error into Claude is the difference between an hour of guessing and a 30-second fix.
How to open the browser console
The console is the backstage of your website. If your app is a theatre performance, the console is where you see the stagehands, the cues, and the exact moment something falls over. Opening it:
- Chrome: Cmd + Option + J on Mac, Ctrl + Shift + J on Windows — or right-click anywhere, choose Inspect, then click the Console tab
- Firefox: Cmd + Option + K on Mac, Ctrl + Shift + K on Windows
- Safari: enable the Develop menu first (Settings, Advanced, "Show Develop menu"), then Cmd + Option + C
Two tabs matter. Console shows errors and logs — start here whenever something is not working. Network shows every request your app makes to servers — use it when login fails or data will not load: refresh the page, look for red rows, click one to see details. And no, you cannot break anything by looking. The console is read-only by default.
How to read error messages: the anatomy of an error
Error messages look intimidating because they are written for developers who know the jargon. But they have a fixed structure, like a medical diagnosis — technical terms, an exact location, and enough information to fix the problem. Four parts, always in the same order:
- The error type. The category: a TypeError means you are using something the wrong way, a ReferenceError means you are using something that does not exist, a SyntaxError means the code has a typo, a NetworkError means the app cannot reach a server.
- The description. The specific problem in one line — "Cannot read property of undefined" means the code tried to use data that is not there yet.
- The location. A file name, a line number, and a character position. This is the most useful part: it tells you exactly where to look.
- The call stack. The chain of function calls that led to the error. You usually only care about the first lines that mention files you recognise — the rest is internal library code you can ignore.
The 30-second method: read the first line for what went wrong, find the first file name you recognise for where, and ignore everything mentioning library internals.
Red, yellow, gray: what the colours mean
The console colour-codes everything by severity, which tells you what deserves your attention:
- Red = error. Something broke right now and the app cannot continue. Stop and fix it.
- Yellow = warning. It works today but might break later or perform badly. Fix it when you can — warnings will not stop your app.
- White or gray = information. Normal logs. Some libraries are just chatty. Ignore them.
A console full of messages is not automatically bad. Focus on the red ones, note the yellow ones, and ignore the rest.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →The six errors you will actually see (decoded)
Building a SaaS with AI tools like Claude and Supabase, the same handful of errors accounts for nearly everything. Here is the plain-English translation:
| The error | In plain English | First thing to try |
|---|---|---|
| Cannot read property of undefined | The code is using data that has not loaded yet | Add a loading check before the data is used |
| 401 Unauthorized | You are not logged in, or your session expired | Log out, log back in, try again |
| 403 Forbidden | You are logged in but lack permission | Check your role and the database security policies |
| 404 Not Found | The page or endpoint does not exist | Check the URL spelling; confirm the route exists |
| Network request failed | The app cannot talk to the server at all | Confirm the dev server is running and the URL settings are right |
| Row violates security policy | The database security layer is blocking the operation | Check you are authenticated and the policy allows this action |
Status codes follow one rule: anything in the 200s means success, 400s mean you did something wrong (bad data, not logged in, no permission, wrong address), and 500s mean the server itself broke. That one rule decodes the entire Network tab.
What to paste when you ask AI for help
Here is where reading errors pays off. When you hand an error to Claude, the quality of the answer is decided by what you paste. Three things, every time:
- The full error message — including the file name and line number, copied straight from the console (right-click the message, Copy)
- The code around the error — roughly five lines before and after the line the error points to
- What you were doing — one sentence: "I was trying to load the profile page after logging in"
With those three things, AI fixes most errors on the first attempt. Without them, it guesses — and a guessing AI is how you end up in the mess described in the signs AI is confidently wrong. If the same error keeps coming back, or you are stuck in a scenario rather than a single error, the follow-up post walks through the ten most common AI building problems and their fixes.
Errors are not the enemy. They are the app telling you exactly what it needs. The founders who ship are not the ones who never see red text — they are the ones who stopped being afraid of it.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →Frequently asked questions
Do I need to understand code to read error messages?
No. You need to recognise the four parts — type, description, location, call stack — and copy them accurately. The error type and description are close to plain English once you have seen the common ones, and the location is just a file name and a line number. AI does the rest.
Can I break my app by using the browser console?
No. Developer tools are read-only by default — you are looking backstage, not rearranging the set. You can open the console, click through tabs, and copy messages without any risk to your app or your data.
Which errors should I fix first?
Red errors that block core flows: network errors, authentication errors, database errors, and anything that produces a blank screen. Yellow warnings can wait. Gray information logs need no action at all — they are just the app narrating its day.
What if the console shows no errors but the app still misbehaves?
Check the Network tab for red rows — a failed request does not always throw a visible console error. If the network is clean too, the data is probably being filtered out rather than failing: wrong account, inactive records, or a draft flag. That scenario and nine others are decoded in the common AI building problems guide.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.