What to Do If You Don't Like What the AI Builder Made

Say what is wrong in one sentence and run an edit. An edit costs 3 credits and changes the existing build rather than replacing it, so wording, layout, colours and structure are all cheap to correct. A full rebuild at 6 credits is for when the whole direction was wrong, not for a headline you dislike.

The reflex most people have is to rewrite the original prompt and generate again from scratch. That is usually the expensive route, and it throws away the parts that were fine. This post sorts the common complaints by what actually fixes them.

What is the cheapest fix for each complaint?

Start by naming the symptom, because the right response varies more than people expect. A vague "make it better" spends credits without moving anything.

The pattern in that table is worth naming: almost everything is an edit. The cases that justify starting over are the ones where the description itself was wrong, not the ones where the output needs correcting.

Why does a specific complaint work better than a general one?

Because "I don't like it" contains no instruction. The builder has your original description and the current build, and nothing else. A general complaint makes it guess which of a hundred decisions you meant, and a guess costs you the same 3 credits as a correct instruction.

Compare two edits. "Make the hero more professional" could mean the photo, the headline, the colour, the spacing, or the font. "Replace the hero photo with a plain dark background, shorten the headline to six words, and move the button above the fold" changes exactly three things you can check.

The second one also gives you something the first cannot: a way to tell whether it worked. When an edit names specific outcomes, reviewing the result takes thirty seconds. When it names a feeling, you end up in a loop of adjustments where nobody can say when it is finished.

Batching is the other half of this. One edit that lists eight changes costs 3 credits; eight separate edits cost 24. Collect the whole list before you spend, then spend once. The full mechanics are in editing after generation.

What if it looks generic rather than wrong?

That is a different complaint and it has a different fix. Nothing is broken, the page is just not distinctive, and the reason is almost always that the description contained no distinguishing information.

A brief that says "a modern landing page for a consulting firm" describes ten thousand pages. A brief that names the audience, the one thing you want a visitor to do, the colours you already use, and one page you admire produces something with an opinion in it. The generator is filling a gap; what you put in the gap is up to you.

Two other levers help. Hi-Fi mode raises the finish level at double the price, which is worth it on a page a client will see. And starting from one of the 25 templates gives the build a structure with a point of view instead of a blank slate. The catalogue is walked through in the Zugo templates guide, and the broader question of sameness is covered in do AI sites look the same.

When should you rebuild instead of editing?

When the disagreement is about what the thing is, not how it looks. Three signals, and if two of them are true, stop editing.

Your description was wrong. You asked for a portfolio and you needed a shop. No sequence of edits reaches a different product cheaply, and a rebuild at 6 credits is less than three corrective edits.

You have run four or more edits and it is still not close. That is a brief problem wearing an output costume. Write the description again from scratch, including what you did not like about the last attempt, and build fresh.

The structure is wrong, not the content. A single page that should have been five is a rebuild as a platform, at 12 credits for the first three pages plus 3 for each after, rather than an edit that squeezes more into one page.

Before you rebuild, write the new description in a text file and read it out loud. If it does not describe the thing you want to someone who has never heard of your project, another build will not fix that either.

What if the result is not wrong but not enough?

Then the limit may be the tool rather than the brief, and that is worth recognising early rather than after twelve edits. Very specific business logic arrives through successive edits, not one prompt, and some products need a development team that a builder does not replace.

The exit is not a dead end. GitHub export puts the complete source in a repository under your account, and the project is yours. A developer can take it from there in the format they already work in, and everything you generated remains the starting point rather than wasted spend.

That is also the honest answer to "what if I stop liking the tool". You leave with the work. What travels and what stays behind is listed in exporting the code.

What should you check before blaming the build?

Two things, quickly, because both are common and neither is a generation problem.

First, whether it actually failed rather than disappointed. A build that does not open is a different situation with different causes, and it is walked through in why did my build fail. Every build is booted in a sandbox before delivery, so a build that fails to load is reported as a failure rather than handed over. That lowers the risk of receiving a blank page; it does not remove it.

Second, whether you are looking at the published version or an old tab. Reload the published address rather than judging a stale preview, and check it on a phone as well as a laptop, because a layout complaint often turns out to be a screen-width complaint.

What are the honest limits of iterating this way?

Editing converges on a good result when you know what you want and can say it. It does not converge when the goal keeps moving, and no builder can tell the difference between refinement and indecision.

There is also a floor on taste. A generator produces competent work from a competent brief and will not rescue a project with no point of view. If the page feels empty, the missing thing is usually a message rather than a design.

If you have a result you are unhappy with right now, the productive next step is to write down the three specific things that are wrong with it and spend one edit on all three. Open the project at zugo.dev, make that list first, and judge the outcome against the list rather than against a feeling.