Part 2 — Building · 18 min read
When it breaks
Reading errors, escaping doom loops, and debugging without knowing how to code.
Something's broken, you don't understand the error, and the AI's third "fix" has made it worse. This is the moment most non-technical founders quit. It's also, genuinely, a solvable situation with a method — and the method isn't "know more about code".
First: stop
The instinct is to keep asking for fixes. That instinct is wrong, and it's how a small problem becomes a broken project. When something's not working after two attempts:
- Stop asking for fixes. Each speculative patch adds mess.
- Get back to safety.
git restore .— back to your last working commit. Yes, you lose the attempts. They weren't working. - Start a fresh session. The old one is full of failed approaches, and those actively make the next answer worse.
- Describe the original problem, not the pile of symptoms the failed fixes created.
Where errors actually live
Three places, and knowing which one to look in is half the battle:
| Where | How to see it | What shows up there |
|---|---|---|
| Terminal | The window running npm run dev | Build failures, server-side errors, database problems, crashes |
| Browser console | F12 or ⌘+Option+I → Console tab | Anything wrong in the browser: broken interactions, failed requests |
| Network tab | Same panel → Network | Requests that failed. Red rows. Click one to see what was sent and returned. |
How to describe a problem so it gets solved
The quality of the fix is almost entirely determined by the quality of the report. Five parts:
What I expected:
Clicking "Save booking" should close the dialog and show the new
booking in today's list.
What actually happened:
The dialog stays open. Nothing appears in the list. But if I
refresh the page, the booking IS there.
Terminal output:
[paste everything, raw]
Browser console:
[paste everything, raw]
What I've already tried:
- Restarting the dev server (no change)
- You suggested adding a refresh call, which didn't help and
I've since reverted it
Please find the root cause before changing anything. Explain what's
actually going wrong, then fix it.Notice the detail that cracks this one: "if I refresh, it IS there". That single observation tells you the save worked and the display didn't update — which is a completely different problem from "save is broken". You found that, not the AI. Observations like that are your actual contribution to debugging, and you're good at them.
Narrowing it down
When you don't know where the problem is, cut the space in half:
- When did it last work? If it worked this morning, your commit history tells you exactly what changed. This is the single best reason to commit often.
- Does it happen everywhere? One page or all pages? One browser or all? Logged in or out? Each answer eliminates half the possibilities.
- Is the data right? Look in the Supabase dashboard. If the data's correct there, it's a display problem. If not, it's a saving problem. Two completely different investigations.
- Does it work in a private window? If yes, it's cached data or a stale session — extremely common and extremely confusing when you don't know to check.
The problems you'll actually hit
| Symptom | Usually |
|---|---|
| Worked locally, broken live | A missing environment variable on the host. Your .env.local isn't deployed — you must add the values in the hosting dashboard by hand. |
| "Module not found" | A library isn't installed, or a file was renamed. Try npm install. |
| "Cannot read property of undefined" | Code expected data that isn't there yet — usually because it's still loading, or the item genuinely doesn't exist. A missing empty/loading state. |
| "Hydration error" (Next.js) | The server and browser rendered different things. Often dates, random values, or something that depends on the browser. |
| Data saves but doesn't appear | The page isn't refreshing its data after the change. |
| Works for you, empty for others | Row Level Security policies. Your account can see the rows; theirs can't. See Choosing a cheap stack. |
| Random logouts, especially on mobile | Session refresh not configured properly. |
| Styling looks wrong only sometimes | Cached CSS. Hard refresh, then check in a private window. |
| Everything broke after adding a library | Version conflict. Ask what it installed and whether there's a version that matches your project. |
When to stop and get help
Some things are genuinely beyond a solo non-technical founder with an AI, and recognising them early saves days:
- Anything where you've lost or corrupted real user data. Stop touching it. Get someone who knows what they're doing.
- Security problems you don't fully understand — especially anything where users might see each other's data.
- Bugs that appear only in production, only sometimes. These need proper tooling and experience.
- Anything you've spent more than a day on with no progress. A few hours of a freelancer's time is much cheaper than another lost week. See Your weekly rhythm for how to hire sensibly for this.
Something is broken and I need the actual cause, not a quick fix.
What I expected: [describe]
What actually happened: [describe precisely, including anything odd you noticed]
Terminal output: [paste everything]
Browser console: [paste everything]
What I already tried: [list, including anything you suggested that didn't work]
Please work through this properly:
1. First, tell me what you think is happening and why — before touching anything.
2. Tell me what evidence would confirm or rule out that theory, and how to gather it.
3. Only once you're confident, make the smallest change that fixes the actual cause.
4. Explain what was wrong in plain English, and why it produced this particular symptom.
5. Tell me whether this could be happening elsewhere in the app too.
Do not change more than one thing at a time. If you're guessing, say you're guessing.We've tried several times to fix this and each attempt has made things worse. I've reverted everything back to my last working commit, and I'm starting fresh.
The original problem, described from scratch: [describe as if we've never discussed it]
Before suggesting anything:
1. List every plausible cause you can think of, including unlikely ones.
2. For each, tell me the quickest way to rule it in or out.
3. Tell me which one you'd check first and why.
Then stop and wait for me to run the checks. Don't write any code yet.
I'd rather spend ten minutes diagnosing than another hour guessing.I'm a non-technical founder. Teach me to read errors in this stack so I need you less for the easy ones.
Take the 15 error messages I'm most likely to see in [your stack] and for each give me:
- What the message literally says, decoded word by word
- What it actually means in practice
- The two most common causes
- Where to look first
- Roughly how worried to be (harmless / annoying / serious)
Then teach me the general skill: how to find the useful line in a wall of output, how to tell my code's errors from a library's, what stack traces are and which parts to ignore, and which warnings I can safely skip forever.You just fixed [describe the bug]. Before I commit this, I want to be sure it's a real fix and not a workaround.
Tell me honestly:
1. What was the actual root cause?
2. What did you change, file by file, and why each change was needed?
3. Did you fix the cause or prevent the symptom? Be honest if it's the latter.
4. Did you remove, disable, or hardcode anything to make this work?
5. Is there error handling here that would hide this problem if it came back?
6. Could this same bug exist anywhere else in the app? Where should I check?
7. What should I click to verify the fix, including the case that was failing?
If you're not confident this is properly fixed, tell me now rather than after I've shipped it.Open your app. Dock the browser dev tools to one side. Deliberately cause three different errors: one server-side (break a database call), one client-side (call something that doesn't exist), one network (point a request at a wrong URL). For each, find where the error shows up.
You'll know it worked when you can predict which of the three places an error will appear in before you look. That prediction is most of debugging.
Next time something genuinely breaks, don't paste "it's broken". Write the full five-part report from this page. Time how long the fix takes. Then, for the following bug, deliberately do it lazily and compare.
You'll know it worked when you've felt the difference — usually a first-try fix versus three rounds of guessing. Save your five-part structure as a snippet you can paste.
Deliberately get yourself into a mess: ask for something hard, then reply with vague complaints four times until the code is a state. Now practise the escape: git restore ., /clear, and the doom-loop prompt above, describing the problem from scratch.
You'll know it worked when the fresh session solves it cleanly. This is the most valuable reflex in this entire guide, and you want it to be automatic before you need it at 11pm the night before a demo.