How to brief an AI website builder, with a worked example
A brief for an AI website builder names the buyer, the offer, the proof you can publish and one action, and keeps design references apart from business facts.
4 min read
In this note
Give the builder a five-part launch brief
Write down the person the page must help, the problem they recognise, what you actually offer, the material you can publish, and what the visitor should do next. Put any design reference on its own line. If a price, result or customer name is undecided, write 'unknown' beside it. A builder will lay out the page, but it can't check a business fact you never gave it.
Here is a brief for an invented appointment tool: 'Audience: reception teams at small clinics. Problem: phone calls interrupt staff when patients confirm visits. Product: a confirmation link sent after a booking; do not claim it integrates with every calendar. Proof: one working screen recording, no customer quotes yet. Action: request beta access. Reference: use the clear step-by-step product explanation on the supplied site, not its words or images.' The limit on integrations and the missing quotes matter as much as the design reference, because they tell the builder what to leave out.
Treat the first output as a draft
Read the first output against the brief, sentence by sentence. Does the hero name the clinic team and the confirmation job? Did the builder make a selling point of the calendar integration you didn't confirm, or invent a satisfied customer? Does the beta button lead to an address or form you control? Turn each mismatch into a specific edit. 'Remove the unsupported integration claim' is easier for a builder to carry out, and for you to check, than 'make the copy more trustworthy'.
Then open the same page on your phone and follow the main action. If the first screen is a decorative illustration and the offer sits several swipes down, ask the builder to swap the order. Submit the form yourself and check that it arrives.
Start from a template, not a blank prompt
A template settles section order, spacing, image balance and what each component is for, so you don't have to decide them again. Pick one whose sections answer your buyer's questions. A developer tool needs code and a working quickstart. A consulting service needs people, engagement stages and an enquiry form. Write down what you want to keep from a reference before you ask the builder to use it.
Replace the source company's words, screenshots, claims and customer material with your own. If you can't fill a testimonial row truthfully, delete the row. Use the reference for the order of your page, and keep every word, image and claim your own.
Keep the page editable after launch
The launch-day page will change once real visitors use it. Keep the copy, sections, images and links where you can reach them, in files or in the builder's controls. Before each change, save the last version you know is correct. If an edit breaks the phone layout, restore that version and fix the one component that failed instead of rebuilding the page.
Store the approved brief next to the site. The next person who edits it can see which statements came from you, which assets are cleared for use and which gaps still need a decision.
Put the brief into practice
A launch page should make the buyer, promise, proof, and next action obvious. iter0 uses this same standard when it turns a brief or reference site into a builder-ready page.
Start your launch build