Why does fixing one thing sometimes break another?

Because a vague instruction invites broad changes. Asking for a fix "wherever this happens" lets the builder touch code it did not need to. This prompt narrows the work to the specific failure and asks for confirmation that nothing else changed.

What if the same fix fails several times?

Stop sending corrections. After about three failed attempts you are usually patching the wrong thing, and each patch makes the next diagnosis harder. Describe the desired end state of that whole section in one fresh message instead.

What should I tell the builder when something breaks?

The exact wording of any error message, what you clicked, what you expected, and what happened instead. "It doesn't work" produces guesses that change working parts of the app. Precision is the whole difference between a small fix and a rebuild.

Fix & Improve

Debug exactly what is broken

Turn the exact error you can see into a small, tested fix without rewriting working parts of the app.

Time: ~15–30 minutes, depending on whether the error can be reproduced Difficulty: Beginner Works with: Base44 / Lovable / v0

When to use this

The moment a page, button, form or connection stops working and you can describe exactly what happened.

Before you start

The exact page, actions, error wording and expected result. Copy the message rather than summarizing it.
Your device, browser, login role and whether the problem happens every time.
The last change you remember, even if it seems unrelated.
A screenshot or short recording with names, payment details, passwords and connection keys removed.
A test record instead of irreplaceable customer data whenever possible.

The prompt

Something is broken in this app. Here is exactly what I see.

Page or screen: [PAGE NAME OR ADDRESS].

Exact steps: [STEP 1], then [STEP 2], then [STEP 3].

Exact visible error message: [PASTE THE COMPLETE ERROR, OR WRITE NO MESSAGE].

What happened instead: [DESCRIBE THE WRONG RESULT].

What I expected: [DESCRIBE THE RIGHT RESULT].

Where it happens: [PHONE OR COMPUTER], [BROWSER], [EVERY TIME OR SOMETIMES], [LOGGED OUT / NORMAL USER / ADMIN].

Last change before it broke: [CHANGE, OR I DO NOT KNOW]. I have attached [SCREENSHOT OR SCREEN RECORDING, IF AVAILABLE] with private information removed.

Reproduce the problem before changing anything. Inspect the visible page and the diagnostic logs, which are records showing what happened behind the scenes. Explain the likely cause to me in plain language and separate what you observed from what you are guessing.

Make the smallest fix that addresses the cause. Do not redesign the page, replace a working feature, delete stored information, reset the app's data, remove security checks or change unrelated files. If a destructive step or a new paid service seems necessary, stop and ask me first.

After the fix, repeat my exact steps and test one nearby action that could have been affected. Show me what changed, what you tested, and anything you could not verify. Keep the repair surgical and the explanation calm.

Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.

Build it on

Start free with Base44 Read Review: Base44

Start free with Lovable Read Review: Lovable

Start free with v0 Read Review: v0 by Vercel

How we make money

What this creates

A repeatable description of the failure
A plain-language explanation separating evidence from guesses
The smallest targeted repair
A retest of the exact broken path and one nearby path
A clear list of anything the builder could not verify

Check it worked

Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:

Following the same steps no longer produces the error or wrong result
The page, button or form now does the specific thing you expected
The nearby action that worked before still works after the repair
No customer record, booking, order or uploaded file was deleted to make the error disappear
You receive a short explanation you understand and a truthful note about anything not tested

Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.

Next steps

Capture an intermittent failure

When the problem happens only sometimes

Add temporary, privacy-safe diagnostic records around [BROKEN ACTION] so we can compare a success with a failure. Record timing, the step reached and a safe error reason, but never passwords, API keys, payment details or full private messages. Tell me how to reproduce the issue and how we will remove the extra diagnostics afterward.

You'll know it worked when: The next failure leaves enough safe evidence to diagnose instead of guess.

Prevent the same break later

After the cause is fixed

Add a small repeatable test for this exact rule: [DESCRIBE WHAT MUST KEEP WORKING]. The test should fail if the original problem returns and should not use real customer data or send real payments or messages. Run it now and tell me how to run it after future changes.

You'll know it worked when: A safe test passes now and will flag the original problem if it returns.

Improve the message customers see

When the technical fix works but the failure message is confusing

Replace only the customer-facing error for [FAILED ACTION] with a calm message that says what happened, whether their information was saved, and what they can do next. Keep the useful technical detail in private diagnostics for the owner, not on the public screen.

You'll know it worked when: Customers get a helpful next step without seeing private technical details.

Watch out for

Paraphrasing hides clues. "It crashed" is much less useful than the complete message and the click immediately before it. Paste the exact text and preserve its line breaks.
Screenshots can leak secrets or customer data. Remove passwords, API keys, payment details, addresses and private messages before attaching them.
Intermittent bugs need patterns, not guesses. Record the time, account role, device and repeated attempts; do not accept a fix based on one successful retry.
Hiding the error is not fixing the cause. The expected action must succeed and saved information must remain correct; removing the warning alone is a failed repair.
Preview and live behavior can differ. If the bug happens only on the published domain, say so and make the final verification there with safe test data.

Platform notes

Lovable can use browser testing and inspect visible and behind-the-scenes evidence when asked to reproduce a problem. Base44 provides diagnostic records for private actions and external connections, but the useful evidence depends on reproducing the exact action. v0 can inspect preview and published-app records, while problems that happen only after publication may also require Vercel's diagnostic records. On every platform, an exact error and repeatable steps are more useful than asking it to "fix everything."

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Related playbooks

Related prompts

debugging errors testing repair

Last reviewed: 2026-07-27