The four prompts I use when a build breaks (and I can't code)

I'm not a developer...BUT I build websites, portals and membership sites for clients with AI, and honestly, I couldn't write most of the code that runs them.

The first website I built this way, I opened the chat and typed, honestly, "I've never used Claude Code before, tell me what you need from me." It built the whole thing. Then something went wrong, because on every build something goes wrong, and a message came up on the screen that I didn't understand a word of.

That moment is where most non-technical people stop. The building is rarely what scares them off. The first error they don't understand is, along with the worry that if they touch anything they'll make it worse.

What changed for me was realising I didn't need to understand the error. Claude wrote the code, so Claude can read the error. My job is to ask the right questions in the right order, and that comes down to four prompts.

The four prompts

1. Explain it to me. What went wrong, in plain English, before anything gets touched.
2. Find the cause. Claude looks into it and shows you the evidence, instead of guessing and trying things.
3. Put it back. When the fixes are making it worse, go back to the last version that worked.
4. Write it down. Once it's fixed, record what broke so you never lose time to it again.

Most errors are sorted by the first two. The third is for the days when they aren't. The fourth is the one that makes your next build easier.

What you need before you start

• The Claude desktop app, with your project open in the Claude Code tab. If you built your site with the prompt I use to build a website, you're already set up.
• The error itself, either as copied text or as a screenshot.
• A few minutes to read what Claude tells you before you say yes to anything.

You don't need to know any code, and you don't need the terminal. If a fix needs something run, Claude runs it.

Where errors show up

Errors appear in one of three places. Sometimes they're in the Claude Code chat itself. Sometimes they're on the page you're building, as a blank white screen or a red box. And sometimes the page looks almost fine but something doesn't work, like a form that won't send, and the error is hiding in the browser's console.

The console is a hidden panel where the browser writes down everything that went wrong. In Chrome, right-click anywhere on the page, click Inspect, then click the Console tab. Anything in red is an error, and that red text is what you give Claude.

One thing to check before you paste

Error messages occasionally include a key, which is a long string of random letters and numbers that works like a password for one of your accounts. Before you paste an error anywhere, look for one. If it's there, take it out first. If a key has already gone into a chat, treat it as burned: go to that service's dashboard, delete the key and make a new one. Keys live in your .env file and nowhere else.

Prompt 1 - Explain it to me

Something's gone wrong. Here's the error: [paste it, or attach the screenshot]

Before you change anything, explain it to me in plain English. What does it
mean, what was happening when it went wrong, & is it serious or small?

Don't fix anything yet. I want to understand it first.

1. Copy the red text, or take a screenshot. On a Mac, Shift + Command + 4 lets you drag a box around just the error.
2. In the Claude Code chat, paste the text, or click the + button and attach the screenshot.
3. Paste the prompt above underneath it and send.

What comes back is a short explanation. Most of the time it's something small: a file it expected isn't there, a key it needs is missing from .env, or a page is asking for information that hasn't arrived yet.

"Don't fix anything yet" is the line that matters. Without it, Claude jumps straight in, changes three files, and you've no idea what was wrong or what it did about it. With it, you understand the problem before anything moves, and the next time you see that error you'll recognise it.

Prompt 2 - Find the cause

Now find the actual cause. Read the files involved & show me what's causing
it, with the evidence, before you change anything.

Then fix it in the smallest way you can, one change at a time. After each
change, tell me what you changed & how I can check it's worked.

If you're not sure what the cause is, say so rather than guessing.

Claude will open the files it needs and read them. It may ask your permission before it changes a file or runs something. Read the line that says what it wants to do, then approve it.

What you see is the cause, with the evidence underneath it. It'll be something like "the form is sending to a table called contacts, but the table in Supabase is called contact_submissions." Then one small fix, and an instruction such as "refresh the page and submit the form again."

"Say so rather than guessing" is there because Claude would rather try something than admit it doesn't know. When it's guessing, it changes things that were fine, and a small problem becomes a big one. Asking for the evidence first keeps it honest.

When it works on your computer but not on the live site

While you're building, your site runs on something called localhost. Only you can see it, because it's your workshop. Vercel is the shop window, the version the world sees. If something works in the workshop and breaks in the shop window, the cause is almost always a key that's in your .env file but was never added to Vercel's environment settings.

It works on my computer but not on the live site. Compare the two & tell me
what's different. Check the environment variables in Vercel against the
names in .env.example first. Don't show me any of the values.

Claude will tell you which name is missing. Then:

1. Go to vercel.com and open your project.
2. Click Settings, then Environment Variables.
3. Add the missing name, and paste its value from your .env file.
4. Click Deployments, then redeploy the latest one so the site picks it up.

Prompt 3 - Put it back

Some days, one fix causes a new error, the fix for that causes another, and you end up further from working than when you started. That's the point to stop fixing and go back.

Stop. This is getting worse, not better.

Tell me what you've changed since the last time it was working. Then put
everything back to that version, & check it works again before we do
anything else.

Once it's working, we'll try the change again, one small step at a time.

This only works if there's a working version to go back to. If your project is saved to GitHub, which it is if you followed the website post, Claude can put it back exactly as it was. So get into the habit of telling Claude to save a version every time something works:

This is working. Save this version to GitHub with a note saying what works.

It takes ten seconds, and it means you can't break the project beyond repair. Every good version is kept.

If you've been going round in circles in one chat for a long time, start a new chat instead. Click the + button, attach the project folder again, and tell it what you were trying to do and what you've already tried. A fresh chat isn't carrying everything that went wrong before, and it often spots the problem straight away.

Prompt 4 - Write it down

It's fixed. Add a short note to this project's README, under a heading called
"What broke": what the error was, what caused it, & what fixed it, in plain
English.

Then tell me if this is likely to happen on other builds. If it is, tell me
what to add to my build prompt so it doesn't.

The README is a plain notes file that sits in the project folder. Claude writes it; you never have to open it unless you want to.

The second half of this prompt is the part that pays off. Fixing an error once is useful. Changing your build prompt so the next site never hits it is how your builds get faster. It's the same idea as the "anything that broke while we were building it" line in the README of every template in my client build templates: you lose time to a problem once, you write it down, and you don't lose that time again.

The catch, and the fix

Claude will sometimes tell you something is fixed when it isn't. It believes it. It's changed the code, and on paper the change should work. But "it should work" and "it works" are different things.

The fix is that you check, every time, as if you were a stranger using the site for the first time. Refresh the page. Do the exact thing that broke. If it was the form, submit it with a real email address, then go and look for the row in Supabase and the contact in Mailchimp. I wrote the full testing checklist in Step 4 of the website post, and it's the same checklist whether the site is new or freshly fixed.

It's only fixed when you've seen it work.

What this looks like as a business

A client paying for a website isn't paying for a build that never breaks, because every build breaks somewhere. They're paying for someone who knows what to do when it does, and gets it over the line.

That's the part that doesn't show on the invoice. My templates are the difference between a four-hour build and a ninety-minute one, and every template in that library carries a note of what broke while we built it. Each error I've written down is one I don't meet again.

You don't need to be a developer to sell builds. You need to know what to build, and what to ask when it goes wrong.

Start with one

The next time something breaks, don't start fixing it and don't close the laptop. Paste prompt one, read what comes back, and only then tell it to go ahead.

If you haven't built your first site yet, that's where all of this starts: start here.