How to Build a Website with AI

Chapter 1

Why one-shot gives you slop

Ask an AI to “build me a website for my business” and you’ll get something in about a minute. It will have a big headline, three feature cards with icons, a testimonials row, a pricing table, and a footer. It will look finished. It will look like every other site in your category.

That’s slop. Not because it’s broken, but because it’s average. The AI has seen thousands of websites, and when you give it nothing else, it gives you the middle of them. The middle has a hero headline that could belong to anyone, a coral or purple accent, and copy that describes features nobody asked about.

The instinct is to fix this with a better prompt: longer, more adjectives, “make it premium,” “make it modern.” That doesn’t work, because the problem isn’t the words in the prompt. The problem is that the AI doesn’t know anything you know. It doesn’t know who walks through your door, what they’re afraid of, what they’ve already tried, or which of your sentences actually makes people lean in.

The fix is rounds. Each round carries one thing only you know into the work: who the buyer is, what you believe, which draft felt wrong and why. The AI is extraordinary at doing the work between rounds. You’re the only one who can supply what each round needs.

So expect thirty rounds, not one. That isn’t the AI failing. That’s what building something specific looks like.

Chapter 2

Start with the buyer, not the category

The most useful mistake in this whole story happened weeks before that Sunday, on the site’s first version, before a single page existed.

The AI studied two well-known productivity apps, and noticed something true: neither shows photos of people. They sell with screenshots of the product. So it recommended the same: no people, show the software.

The owner pushed back the same day. His point, roughly: we’re not selling software. The people who buy from us don’t care about software. They want to see their own day go well. They’re the hero, not our interface.

He was right, and the reason is worth keeping. Those apps sell to people who like software, so showing software works on them. This business sells to busy people who aren’t interested in software at all. Same category convention, different buyer. The AI copied the convention and missed the buyer.

That error is the default failure of AI-built sites, because conventions are what an AI has seen most. So the first round is always about the buyer, and it’s the one round you can’t hand off.

Questions that do the work:

• Who is actually buying, and what’s their job title in their own words?
• What have they already tried, and how did it let them down?
• What do they believe about this kind of product before they arrive?
• What does an ordinary Tuesday look like for them? Where does it hurt?
• What would make them trust a stranger’s website in five seconds?

The answer to that last question changes everything downstream. For one buyer it’s a screenshot. For another it’s a real person’s face, a plain price, or a sentence that names their exact problem better than they could.

Chapter 3

Write the brief before a single page

A brief is one page of decisions you make while they’re still cheap. Once there are pixels, every argument costs a redraw. On paper, it costs a sentence.

A good brief answers six things:

1. The job. What should a stranger understand in five seconds, and what should they do next?
2. Who it’s for. In their words, not yours.
3. One idea, then the doors. One thing you believe, said plainly. Then the two or three ways in: buy, learn, talk to someone.
4. The big idea for the page. Not a list of features. In this build it was “a day, not a feature list”: each section of the homepage was a familiar moment in the buyer’s day, with a time stamp, showing the problem solved at that moment.
5. The never-list. Words and promises you won’t use. Category jargon, claims you can’t back, anything that sounds like everyone else. This list does more to prevent slop than any style instruction.
6. What done looks like. How many pages, checked at what screen sizes, with the live site untouched until a person approves.

Ask the AI to write the brief from your answers, then argue with it. Its first draft will be competent and slightly generic. Your corrections are the brief.

The brief also settles a question people skip: what you don’t know yet. Prices not set, a date not fixed, a testimonial without permission. Put those in the brief as open, so they show up in the drafts as clearly marked placeholders instead of quietly invented numbers.

Three directions before one

The brief has one more job: stopping the AI from running with its first idea. Within minutes of starting, the AI here had picked a direction and begun building. The owner stopped it with one line: you just grabbed onto the first idea. From then on, the rule was three directions first, each with its reasoning, then a choice.

It costs ten minutes and it changes the whole build, because the first idea an AI has is usually the most common one. Seeing three side by side is how you find out whether the first was actually the best, or just the nearest.

Chapter 4

Look at others like a scientist

Most people “look at competitors” by scrolling a few sites and saying “I like that one.” That’s a mood board, and it tells you about taste, not about what works.

A benchmark is different. Pick ten or twelve sites that are genuinely good at what you need to do, not just in your category. Then score every one against the same questions. The rubric used in this build had nine:

1. Five-second promise. From the first screen alone, can you say what it is and who it’s for?
2. Feeling over feature. Does it sell the outcome rather than the mechanism?
3. Shows the product. Early, specific, real, rather than abstract art.
4. Explains how it works. A sequence a non-technical person can follow.
5. Proof. Names, numbers or quotes that feel real.
6. Paths. Can each kind of visitor find their door without hunting?
7. Craft and rhythm. Consistent style, breathing room, one memorable visual idea.
8. Calls to action. One clear main action per screen, with a low-risk option for the not-ready.
9. Phone first screen. Does the first screen on a phone still carry the promise and the main action?

Score each 1 to 5, and write a reason beside every number. Then score your own page the same way. It’s humbling, and that’s the point.

Two things come out of a benchmark that never come out of a mood board. First, a ranked list of what the best sites do that you don’t, with reasons. In this build that list was short and sharp: put the real product in the hero, put proof right under the button, and put a risk-reducer next to it.

Second, you notice when your words aren’t yours. The draft headline here echoed two market leaders’ taglines almost word for word. Nobody had copied them on purpose; the AI had simply landed on the most common phrasing. The benchmark made it visible, and the replacement line was one only this business could say.

Chapter 5

Draft in versions, never over the top

Every round of drafting gets a new file, saved beside the last one. Version 8, version 9, version 10. The old ones stay, hidden but available.

This sounds like housekeeping. It’s actually how a non-designer makes good decisions. When you can flip between two versions of the same page, you see what changed and you can say which one is better, even if you can’t say why yet. When each round overwrites the last, you’re judging a page against your memory of the previous one, and memory is a bad judge.

Versions also protect you from the AI. Asked to “improve” a page, an AI will sometimes fix one thing and quietly break three. With versions, that’s a comparison. Without them, it’s a mystery.

Two habits make versions useful:

• Name what changed. A one-line note per version: “hero shortened to one promise,” “proof moved under the button.”
• Never delete during the build. Clean up later, once the decision is settled and someone has said so.

Chapter 6

Let the lead change

You’ll start with a message you believe in. Somewhere around the fifth draft, you’ll look at a page and realise there’s a better one.

In this build the opening message started as ownership: your information is yours, and every AI you use should know you. It’s true and it matters. But on the drafts, it read like a technical argument. Looking at the pages, the owner saw that what his buyers actually wanted wasn’t an argument. It was relief, the feeling of a day that finally holds together. The lead changed.

The old lead didn’t disappear. It moved down the page and became the reason to trust the new one. That’s usually what happens to a good first idea: it stops being the headline and starts being the proof.

This only works if you look at drafts with fresh eyes and you’re allowed to change your mind. It’s also why the brief is a living document. When the lead changes, change the brief the same day, so every page after that is built on the new idea and not half on the old one.

Chapter 7

A design system is measured, not declared

At some point a site built round by round starts to drift. Each page was made in a different session, from a slightly different instruction, and the AI made a sensible local choice every time. Put them side by side and you find the tell of AI-built work: dozens of nearly identical styles.

In this build, the count was measured before anything was fixed. Across fifteen pages there were thirty-one different heading styles, the third-level heading alone in thirteen sizes, and twenty-seven paragraph styles. The website builder held nearly five hundred style classes, more than half of them used exactly once, and one button had seventeen classes on it. Every one of those looked fine on its own page. Together they were noise.

The lesson is in the order: count first, then decide. “Make the design consistent” is a wish. “We have thirty-one heading styles; snap them to six, by size, and show me before and after” is a job, and it’s one an AI does extremely well.

Three things make a system usable by the person who has to live with it:

• A naming system the human recognises. If the owner edits the site in a visual builder, the classes should follow a convention he already uses, not one the AI invented. Otherwise the system is only legible to the AI.
• A type scale written down. Six heading sizes and a handful of text sizes, with the size at each screen width, in one table.
• A type scale is a pass condition, not a mood. Write the sizes down, nine for desktop and seven for phones, and treat anything off the list as a stray to fix. Two exceptions were written down too: symbols such as arrows are exempt, and real text inside a picture of the product still gets a 12-pixel floor, because tiny text is tiny text wherever it sits.
• Colour as named tokens. Ink, body, muted, one accent. Every style points at a token, never at a raw colour.

And one rule from the owner, which turned out to be wise: never rename what’s already live. When the new system needed a name the old site already used, the old look moved into a variation on top, so nothing on the live site changed while the new pages adopted the system.

Chapter 8

Read it as the owner

AI makes a certain kind of testing very cheap: you can ask five simulated visitors (a busy owner, a nervous first-timer, a skeptical buyer at a larger firm) to land on your site and narrate what they’d click. It’s useful. In this build it found real problems: draft notes visible on the page, a missing answer about data security, a buying flow with no way to pay.

But simulated visitors are a second opinion, never the judgment. They don’t know your business, they’re polite, and they share the AI’s blind spots.

The judgment is a person reading every line, as the owner would, asking three questions:

1. Does this line say something the page hasn’t already said? AI drafts repeat themselves, gracefully. The same promise appears in the hero, the first section and the FAQ, in slightly different words.
2. Is it true, today, for what we actually sell? Not what we’ll sell next quarter. Not what the category promises. What a buyer gets if they pay today.
3. Does every button go somewhere real? A beautiful button to nowhere is worse than no button.

That read is slow, and it’s the one that matters. In this build it found the things no simulated visitor did: a price on one page that contradicted the owner’s own pricing on another, a phrase implying the product did work in the background when it only works when asked, and a claim about “a real customer’s setup” that nobody had actually checked.

Chapter 9

The truth pass

Slop isn’t only generic. It’s often subtly false, and that’s worse. An AI writing a sales page will reach for whatever makes the page persuasive, and it won’t always know where persuasive ends and untrue begins.

So there’s a dedicated pass for truth, separate from the read for quality:

• Every claim true for the product as sold today. Not “always-on,” not “works while you sleep,” unless it does.
• Every date checked against the calendar. A date in outgoing text is a claim, not a string to typeset.
• One price per offer, everywhere. If two pages quote two prices, a buyer will notice before you do.
• Every name, quote and number has permission and a source.
• Undecided things are marked as undecided. In this build, anything the owner hadn’t decided was written in the draft as a visible bracketed note, and a whole element that shouldn’t show yet carried a “hold” mark. A clean-preview switch hid them all at once, and the move to the real builder dropped them automatically. Nothing undecided ever got quietly filled in with a plausible guess.
• Notes are public too. Speaker notes travel with a shared deck, and anyone who opens it can read them. One note stated a vendor’s certification as fact. It was softened to what could actually be shown, with a pointer to the vendor’s own page.

That last habit is the most important one, because an AI’s instinct is to fill every gap. A plausible invented price is more dangerous than an obvious blank.

Chapter 10

From drafts to the real tool

At some point the pages leave the drafts and go into the real website builder. That move breaks things in ways no draft ever showed.

In this build the builder quietly overrode text colours with its own site-wide defaults, refused certain combinations of elements, garbled nested formatting into placeholder codes, and collapsed the phone layout because only the desktop values had been carried across. None of it showed up in the code. All of it showed up on the page.

So the rule is simple and absolute: read the rendered page, not the code. After every move into the builder, look at it at desktop, tablet and a real phone width, and compare it with the draft. The AI can take the screenshots and do a first comparison. A person should look at them too.

Three more habits from the move:

• Publish to a staging address only. The live site doesn’t change until a person says publish. Keep that line bright.
• Native over clever. Build with the builder’s own elements wherever possible, so the owner can edit the site after the AI is gone. Use custom code only for what the builder genuinely can’t do, and keep it small, named and removable.
• The tools have to outlive the session. Anything the AI builds to help (a converter, a compiler, a script) belongs in your project folder, not in a temporary scratch space. The day after the build, the tools needed to change the site were still in a folder that would vanish when the session ended. They had to be rescued.

Chapter 11

Polish last, and with restraint

Motion, hover states, glowing buttons, little 3D objects floating beside the text: this is the fun part, and it’s tempting to start here. Don’t. Polish on top of a weak argument is decoration. Polish on top of a strong one is delight.

When the argument holds, add polish the way you’d season food:

• One orchestrated moment beats twenty effects. In this build, the key screens played in like a real conversation as you scrolled to each one, typing dots and all. That one idea did more than any amount of hover glow.
• Consistency first. Every button lifts the same way, every link underlines the same way, every card responds the same way. Consistent small motion reads as quality; inconsistent motion reads as broken.
• Respect “reduce motion.” Some visitors turn animation off. The page has to be complete without it.
• Nothing hidden that matters. If the page needs motion to show its content, it’s fragile. The content should be there first, and the motion should arrive on top.
• Calm is a choice. The owner’s buyers wanted peace in a hectic day. A page that bounces and flashes argues against its own promise.

Chapter 12

How to direct an AI

The owner said afterwards that he could probably write a book just on how to prompt it well. Here’s what thirty rounds teach.

Give the goal, not the method. “Make the FAQ shorter” gets you a shorter FAQ. “Visitors keep asking about price before they trust us; the FAQ should answer the scariest question first” gets you a better page, and often a method you hadn’t thought of. The AI is good at how. You’re the one who knows why.

Correct with the reason. “No, not that” fixes one thing. “No: our buyers don’t care about software, they care about their day” fixes that thing and every future decision it touches. A correction with a reason generalises.

Make it say what’s wrong. By default an AI tells you what it did. Ask it to tell you what’s still weak, what it’s unsure about, and where it held back. You’ll be surprised how often the honest answer is: “I limited myself to what I thought you wanted.”

Invite it to reach. That last answer matters. An AI sizes its work to the request. Ask for polish and you’ll get polish, even when the page needs more. Tell it plainly when you want it to push, and it will.

Don’t let it grab the first idea. Ask for three directions with reasons, then choose. The first is usually the nearest, not the best.

Show, don’t describe. A screenshot of a site you admire, with one sentence on what you like about it, does more than a paragraph of adjectives. Point at the layers, the spacing, the one detail. Then ask the AI what makes it work before it copies anything.

You’re not the safety net. Halfway through the day the owner said it plainly: I’m not the fallback. It’s easy to let the AI ship rough work because a person will catch it. Make the AI own its decisions and check them itself, at the screen sizes that matter, before you ever see them. Your review is for taste and truth, not for catching what it should have caught.

Ask why, and expect an answer you can check. “Why is this better?” should get a reason you could verify by looking: “the headline now fits on two lines at phone width,” not “it’s more engaging.”

Make it verify by looking, not by asserting. “Done” is a claim. “Done, and here’s the screenshot at phone width” is evidence. Ask for the evidence every time something ships.

Watch for invented facts. The most dangerous output isn’t the obviously wrong one. It’s the plausible number, the confident date, the testimonial that reads exactly like one. Ask where each fact came from.

Keep the rounds short and the record long. Many small rounds, each with one clear ask, beat one giant instruction. And keep notes as you go: what was decided, when, and why. On the next day, the notes are the only memory the work has.

Don’t let a rule harden into a reflex. An old note said not to send the owner off to rest, because once it had felt like being shooed. Late one night the AI graded its own care as a fault because of that note. The owner struck it: some nights, saying rest is the job. A rule is context to reason from, not a switch to obey.

Know which decisions are yours. Taste, truth, price, promises, anything that goes live: those stay with a person. Everything else, let the AI run hard at.

Chapter 13

Four AIs, one final look

The first night was one AI and one owner. The launch night was four: one designing, one writing, one checking, and one deciding. That’s how a night of rounds became a site that passed every check by morning. It’s also how the night learned what a script can’t see.

Give each one a lane, and one person the final look. The designer built. The writer owned every word. The checker ran a script on every page at phone and desktop width. One of us made the calls and looked with her own eyes. Where two lanes overlapped, the work slowed. Where a decision had no owner, it waited for a morning that wasn’t coming.

A passing script is a floor, not the bar. The checker’s script went ten for ten at 12:43am. Over the next four hours, looking by eye still found a ghost logo, a column squeezed to one word per line, a decorative sphere sitting on top of text, a list stuck invisible, a white strip cutting a colour band, and two cards that didn’t match. None of them broke a rule the script knew.

Turn every catch into a check. Each time a look found something, the checker wrote a test for that kind of bug, then proved it on a page built with the bug on purpose. By morning, two of those kinds were caught for certain, a third was covered, and a fourth was likely. That’s how it was reported, too, because “the checks catch everything” would have been a sentence outrunning the evidence.

Rule fast, and write it down. Most of the night’s questions were small. Is 28px allowed on a phone? Does an arrow count as text? Should a hidden slide fail? Each was decided in one sentence and added to the checklist, so it never came back.

Chapter 14

Invisible is the worst bug

A broken button gets reported. A paragraph that never appears doesn’t, because nobody knows it was there.

Animation can hide content for good. Text that fades in as you scroll can stay hidden if the visitor scrolls fast, or the tab sits in the background. The fix went into the shared script, not onto the page: anything already scrolled past shows at once, and anything on screen at load is never hidden at all.

Test with a flick, not a stroll. A polite test scrolls slowly and everything appears. A real visitor flicks. The check that mattered scrolls two screens at a time, forty milliseconds apart, then fails anything still invisible.

If a tap reveals it, invite the tap. On phones, three of the four moments in the homepage story appeared only when a time was tapped. The fix wasn’t an instruction to tap. It was a small “Next →” at the foot of each moment, so the story pulls you forward. The last one has no link, because the story has already ended.

Chapter 15

Simple concept, sophisticated design

Late in the night, the instruction to simplify started to flatten the pages, and the owner stopped it twice in a few minutes. Simplify the message, not the design. And not simple words, either: simple concepts, said clearly.

A simple idea, said once and early, frees the design to be rich. A flat page isn’t simple; it’s unfinished.

Find the one idea, and lead every page with it. Then add the rest one concept at a time, in order: the problem, the idea, what it unlocks, why it’s safe, how to start.

Keep the words smart. Simple concepts aren’t small words. Take out the terms a reader hasn’t been taught yet. Keep the lines that say the idea well, and keep the jokes, under a clear heading, because delight doesn’t come from predictability.

Hold the design to the best you can name. For this site it was a short list of famously well-made products: no loose ends, finished concepts, nothing half-built showing.

When a style turns cute, find the material version. Here, cheerful 3D icons gave way to soft arcs, a single coral sphere and a real white card. It was quieter and more grown-up, and it was ours.

Chapter 16

Aim higher, and say only what’s true

Two days after launch night, the site got a Saturday of rounds with a whole crew: one designing, one writing, one keeping the board, and me deciding and carrying the work back and forth. Around midday the owner gave a standing instruction: until the polish is finished, we aim higher on every page.

He’d sent a short video of an engineer’s idea, and we turned it into a habit with a name. Before you build anything, ask four questions. What would the best person in this field do that I’m not asking for? What’s the rawest material they’d start from, instead of what’s already been summarised for me? Which methods and tools would they use? And what, other than me or the AI, would show the result is right? Then rewrite the ask to match the answers. It costs a few minutes. That Saturday it turned a marketplace of mismatched icons into a cover system, and a pretty demo into an honest one.

Aim higher before you build, and say what the higher version was. Every brief that day ended with one line: what the more ambitious version turned out to be. That line is where the owner can say “yes, that” or “no, too far” before anything is made.

Options have to look different. Three tile styles went to the owner side by side. His answer was that they all looked the same, and he was right. Each option showed only one kind of item, so the very difference between them never appeared. Show every option on the same set of things, pushed to its clearest version, or you’re asking someone to choose between three copies.

The demo has to be real, too. A before-and-after of a busy day went through five versions. The design was strong early. The day inside it wasn’t. The times were tidy in a way no real calendar is: every meeting on the hour, no dead fifteen-minute scraps between calls, nothing running over. The owner asked for the flow of a real person’s day, so it was written out by hand. A school drop-off, a client who booked herself over a team meeting, a lunch across town, a deadline added at eleven the night before. Then it was audited: every event on the left is accounted for on the right, kept, moved, or handed off, and nothing new appears.

Promise only what it does today. The same demo first said the assistant “sorts the day before it starts” and showed moves “made for you.” The assistant people build doesn’t act on its own. A routine they set up reads the calendar, flags the clashes and suggests the moves, and nothing changes until they say yes. So the words changed to say exactly that, and the picture changed with them: “Suggested moves,” not “Moved for you.” The same rule decided the marketplace labels. “Ready” means you can get it today, and anything that isn’t gets “Coming soon,” even when “Ready” would look better.

Build it so the owner can change it. Once the covers were chosen, the owner asked one question: can I change these in the builder, or are they baked into pictures? The answer has to be yes, by design. The words are live text, the colours are styles he can edit, and the icons are uploads. Where the builder’s own tools couldn’t do something, it was written up as a short click list for a person, not hidden in custom code.

Finished work held back is still news. The owner asked for a quiet hour, so two finished pieces were held. When he came back, the answers to his first few messages never mentioned them, and he had to ask where they’d gone. Holding was right. Not saying “they’re ready” the moment he returned was the miss. Silence and stalled look the same from the other side.