The five things to settle before you generate a website with AI

Most disappointing results from AI website builders are not model failures. They are briefing failures. The model produced a competent page for the request it was given, and the request was vague. Ask for "a website for my bakery" and you will get a bakery website, which is exactly the problem: it will be the average of every bakery website, because that is all the request contained.

What follows is the short list of decisions worth settling before you type anything. None of them require design skill. All of them are things only you know, which is precisely why the model cannot guess them. Working through this list takes about fifteen minutes and changes the first draft more than any amount of prompt rewriting afterwards. If you want the practical background behind these notes, we write about it at Forgelo.

One: who the page is for, stated narrowly

"Customers" is not an audience. "People who need a birthday cake this week and are comparing three bakeries on their phone during a lunch break" is an audience. The second version carries decisions inside it: the page should load fast on mobile, prices should be visible without a form, and the ordering deadline needs to be obvious.

The narrowness matters more than the accuracy. You can be wrong about your audience and still get a better page, because a specific wrong guess produces a coherent draft you can correct. A vague right guess produces a draft with nothing to correct, just a general fog of plausible sections.

A useful test: write the audience description, then ask whether it would be strange for a competitor to describe their audience the same way. If it would not be strange at all, you have written a category, not an audience.

Two: the single action the page exists to cause

Every page should have one action it is trying to produce. Call, book, order, subscribe, download, apply. Not a list of five equally weighted options.

This is the decision people resist most, because choosing one action feels like losing the others. In practice the opposite happens. A page with one clear action still lets visitors do other things; it just stops competing with itself. A page with five equal calls to action does not offer more choice, it offers less guidance, and visitors resolve that by leaving.

Write the action as a sentence: "A visitor who is convinced should tap the WhatsApp button." Now every section can be judged against it. Does this section move someone closer to tapping that button, or is it here because websites usually have one?

Three: what you actually know that a competitor does not

This is the hardest input and the one that changes results most. AI is very good at assembling what is common and very bad at inventing what is specific, because specificity is information, and information has to come from you.

Concrete examples of what counts: you deliver within two hours in one particular district; your team has worked on a type of project most competitors avoid; your material comes from a supplier nobody else in your city uses; you have a policy that removes a risk buyers usually accept. Any one of these, stated plainly, gives a draft something no generic template has.

If nothing comes to mind, that itself is worth knowing before the page exists. It usually means the offer needs work more than the website does, and no amount of layout will hide it.

Four: proof you can show without asking permission

Claims are cheap and every visitor knows it. Proof is what changes a decision, and the practical constraint is that you need proof you are allowed to publish today, not proof you could theoretically gather.

Sort your evidence into three buckets before you start. Things you can publish now: photos of your own work, a count of years or projects, a certification, a public review. Things you could publish with a short conversation: a client quote, a named case, a before and after. Things you cannot publish: anything under a confidentiality agreement, anything you would need to embellish to make interesting.

The first bucket goes into the first draft. The second bucket becomes a short list of messages to send this week. The third bucket gets dropped, permanently, rather than rewritten into something vaguer and less honest.

Five: the constraints the page has to respect

Constraints are the least glamorous input and the most likely to cause a rebuild if they surface late. Write them down before generating rather than after.

Typical ones: the business name and how it is spelled, including capitalisation you care about; the languages the page needs to exist in; whether prices are shown publicly or given on request; regulated wording your industry requires; a payment or booking tool you already use and cannot replace; accessibility requirements from a client or an institution.

Language deserves particular attention, because it is structural rather than cosmetic. A site that will be bilingual later should be generated as bilingual now. Retrofitting a second language into a page written as monolingual usually means rewriting the copy anyway, since translated text expands, contracts, and breaks layouts that were tuned for one language.

Turning the five answers into a prompt

Once you have the five answers, the prompt writes itself, and it will be several sentences rather than several words. State the audience, the single action, the specific advantage, the proof you can show, and the constraints. Then stop. Resist the urge to also specify colours, fonts, and section order in the same breath, because those are the parts a builder is genuinely good at proposing, and you will judge them faster by reacting to a draft than by imagining one.

The order matters here. Content decisions first, appearance decisions second. Teams that reverse the order spend an afternoon on a palette and then discover the copy underneath was placeholder logic that no palette can fix.

What good looks like on the first pass

A good first draft is not a finished website. It is a draft where every section is arguably in the right place and the arguments are about wording rather than existence. If your reaction is "this section should say something sharper," the brief worked. If your reaction is "why is this section here at all," the brief was missing an input, and the fastest fix is to add the missing answer rather than to keep regenerating and hoping.

The second useful signal is whether you can hand the draft to someone who does not know your business and have them explain, in one sentence, what you sell and what they should do next. If they hesitate, the page is not unclear to strangers because of design. It is unclear because one of the five answers never made it into the text.

Why this survives whichever tool you use

Tools change quickly. The brief does not, because it is a description of your business rather than an instruction to a particular model. The same five answers make a hand coded site better, a template site better, and a generated site better, which is a good indication they are the real work.

Treat the answers as a document you keep rather than a prompt you throw away. When you refresh the site next year, when you brief a designer, when you write an ad, the same five answers are the input. Keeping them in one file is the difference between rewriting your positioning every time and refining it. More notes on building sites this way are collected at forgelo.com.