When: you're having an AI design and build a website, from the first look through to handing it over.
Built from: starting a new codebase, putting a site up on Cloudflare, align before you give it more.
The worry: an AI can turn out a good-looking page in minutes, so it's tempting to take the first one. But the first one tends to look like every other AI-made page, it can ship broken in ways you don't see on your own screen, and nobody remembers why the look ended up the way it did.
What's really going on: the look is a decision about who the site is for, and the AI can't make that for you. Once it's made, most of what goes wrong is quiet: a page that is blank for some visitors, images far too big, two copies of the site overwriting each other. You only find those by checking.
The look
- Settle who it's for before you pick a look. Say where it sits (between budget and luxury, say), how it should feel, and how it must never feel. A dark, luxurious look was dropped once because it would have scared off the mid-range buyers the site was for.
- Ask for several looks that are really different. Give each one a different layout to follow: magazine, catalogue, full-screen photos, bright retail. Name the colours too. Left to choose, agents drift together: three of four "different" looks once picked green on their own.
- Avoid the tells of an AI-made page: a number on every section (01, 02…), a small capitals label above every section, and a cream or beige background. Also gradient text, frosted glass for decoration, a coloured stripe down the side of cards, and rows of identical icon cards. Numbers belong only on a real sequence, like "how it works". Let warmth come from the accent colour, the photos and the type.
- Keep small grey text dark enough to read. A grey picked for elegance came out at about 2.5 to 1 contrast. It needs at least 4.5 to 1. Never lighten it for looks.
- Borrow from known brands' design systems by fit, not by fame. Pick the two or three whose problem is like yours and take one idea from each: a filterable photo wall from Pinterest, colours taken from real materials from Starbucks, one accent kept for a single moment the way Starbucks keeps gold for its rewards.
- Write the look down in one DESIGN.md: the colours, type, spacing and components first, then layout, motion, voice, and what to do and not do. Every later change reads it, so the look doesn't drift.
Building it
- A fade-in must never be what makes content appear. If content starts hidden and waits for a scroll to show it, it stays blank in a hidden tab, in a screenshot tool and for search engines. That shipped blank three times on one site. Hide content only once the page's script has run, show what's already on screen at load, and add a fallback that shows everything after about a second and a half.
- Respect the reduced-motion setting: stop anything that scrolls by itself and show content without the fade.
- No sideways scrolling on a phone. Check at 375 pixels wide. Anything decorative or scaled up sits inside a box that hides overflow.
- Shrink images before they go on the page. Generated images come out around 2,700 pixels wide and 2.5 MB each. Resizing to about 1,800 pixels took one site's images from 22 MB to 3.5 MB with no visible loss. Squeezing without resizing saved only about 7%.
- When you swap in a real photo, give it a new file name. Images are usually cached for a year, so a returning visitor keeps the old one under the old name.
- React 19 has no single-file build any more, so the old unpkg link fails. For React without a build step, load it from esm.sh with an import map, and write the markup with htm.
- One form can do several jobs. A booking button, a quote button and an upload-your-plans button can all open the same form, with its type already picked by the button that opened it.
- If more than one agent takes screenshots at once, give each its own browser. Sharing one, they take each other's pages. Each one checks the address before it takes a shot.
Showing it and choosing
- Show the options as a preview hub: each version at its own address, with a date, a short list of what changed, and a thumbnail. Use the same words in every look, so the choice is made by eye.
- Narrow down deliberately. Going broad is useful only until it's time to pick one or two and go deep.
Shipping it
- One deploy path per site. When two machines both deployed the same site, a deploy from an out-of-date copy quietly put an older version back live. Pull the latest before any work, and deploy only by pushing, so GitHub Actions does it.
- Cloudflare's own traps (headers that add up, caching, checking the right address) are in putting a site up on Cloudflare.
Handing it to someone who isn't technical
- They'll change it by talking to their own AI, so give that AI a CLAUDE.md in the repo. It says what to read first, that "publish it" means commit and push, never to deploy by hand, which words the business never uses, and that a fact marked as unconfirmed is never stated as fact.
Tools tried
- Meta's Astryx component library: themed through CSS variables, with strong form parts. It reads clean and systematic, so it needs a lot of theming to feel warm.
As a skill: ask the AI to turn this page into a skill for any new site, with DESIGN.md as the first thing it writes.