What actually needs to be in a build prompt?
Four things, and I say that after watching something like two hundred of these turn into finished sites: what it is, who it's for, the must-haves, and — optionally — a mood. Everything else is noise the builder will fill in with defaults anyway, so the real skill isn't writing more, it's noticing which of these four you actually have an opinion about and saying only that.
Start with what it is, and keep it to a category, not a spec. "A booking site for a yoga studio" beats "a site where people see times and click a button to reserve a spot and get a confirmation" even though the second one contains more information. The category activates defaults the builder already has — schedules look like schedules, booking flows look like booking flows — while the description makes it reconstruct the category from scratch.
Do I need to say who it's for?
You don't need to, but it's the line people skip that they shouldn't. "For the studio's existing students" and "for people discovering the studio for the first time" produce different sites almost everywhere it matters — copy tone, whether there's a big marketing hero or a straight-to-schedule layout, whether pricing sits up front (new visitors need it) or gets tucked away (regulars already know it). One clause here can resolve a hundred small ambiguities that a page of feature requests never would. If the audience really is generic, leave it out — don't manufacture one just to fill the slot.
How many must-haves should I list?
Two or three. The test I use: would you reject the first build for missing this? "Class schedule, online payments, teacher bios" passes that test for a yoga studio — without a schedule it's not a smaller version of the site, it's a different site. "A newsletter signup in the footer" almost never passes; that's a nice-to-have, and nice-to-haves belong in the follow-up chat once you've seen a plan, not jammed into the opening prompt where they compete with things that matter.
This is honestly the ingredient people botch worst, in both directions. Zero must-haves and the builder guesses, sometimes wrong. Eight must-haves and the builder treats all eight as equally load-bearing, and what comes back reads like a feature list wearing a website costume — no hierarchy, no room to breathe. If I had to push back on skipping one ingredient, it'd be this one. Even a single clause of "the two things that make this yours" saves a round-trip almost every time, because it's the one piece of information the builder has no way to infer from the category alone.
Should I specify a mood?
Only if you have one. Plenty of good prompts skip this entirely, and that's fine — the design director commits to an art direction whether you specify one or not. A two-word mood ("warm and hand-drawn," "clinical and fast," "like a 90s arcade") just points that commitment somewhere instead of leaving it to whatever the category's defaults are. If you have a strong reaction — you know you want cream backgrounds and warm serif type, or you know you hate rounded corners — spend the clause. "Clean and modern" doesn't count, by the way. That's not a mood, it's the absence of one, and it steers nothing while still costing you a slot.
Why not just describe everything I'm thinking?
Because the builder complies. That's the actual failure mode, and it's not what people expect — it isn't that too much information confuses the builder, it's that every sentence you write reads as an instruction, including the half-formed ones you'd happily discard on a second look. I've watched someone write "maybe a testimonials section, not sure" and get back a testimonials section with three placeholder quotes, because "maybe, not sure" is a hedge to a human reader and a feature request to a system that takes you at your word.
This wouldn't matter if under-specifying were expensive, the way it is with a human dev team, where ambiguity costs you two weeks before anyone notices the wrong thing got built. It isn't expensive here. The builder plans before it builds — you see a concrete proposal before anything's committed to code — so under-specifying costs you a five-minute correction in the chat, while over-specifying front-loads all your weakest half-formed ideas at the exact moment you have the least information to know which ones are worth keeping. Ten words of real requirements beat two hundred words of stream-of-consciousness, not because more information is bad in the abstract, but because in this interface specifically, every extra word is a commitment.
There's a quieter cost too: it flattens hierarchy. List twelve features with equal emphasis and the builder has no signal about which three you actually care about, so it either gives all twelve equal visual weight (cluttered) or guesses at priority (sometimes wrong, and now you're debugging a guess instead of stating a preference). Three must-haves stated plainly protect that hierarchy. Twelve in a paragraph erase it.
What does a good prompt actually look like?
| Prompt | Why it works |
|---|---|
| "A training log for climbers — sessions, grades, progress charts." | What plus three must-haves, ten words of requirements total. No audience note, because "climbers logging their own training" is obvious from the category — it correctly skips the one ingredient not doing any work here. |
| "A landing page for my podcast about urban farming, warm and editorial, with an episode list and a subscribe form." | What, audience implied by "my podcast," mood, two features. It doesn't say which player embeds the episodes or how many show per page — those are round-two questions, not opening-prompt questions. |
| "A two-player air-hockey game, real physics, one keyboard." | Games make this pattern obvious: genre plus the one constraint that defines how it actually plays. "Real physics" and "one keyboard" aren't features so much as the two decisions that determine whether it feels like the game in your head. Table color, puck trails, scoring UI — the builder proposes, you react. |
What links all three isn't brevity for its own sake, it's that every word is doing a job. Cut "warm and editorial" from the podcast prompt and you get a generic podcast page; cut "urban farming" and the mood word has nothing left to aim at. That's the real test for whether a prompt is well-formed — not word count. I'd take a 40-word prompt where every clause earns its place over a 15-word prompt that's terse for the sake of it and quietly drops a must-have.
What if I already have brand colors or real photos?
Attach them. Don't describe them. I've watched people write a careful paragraph pinning down a brand palette in hex-adjacent language — "a deep forest green, kind of muted" — when the actual brand guide was sitting in a PDF on their desktop the whole time. A described color is a guess the builder has to reconstruct; an attached one is just correct. Real menus, real photos, brand assets — the knowledge and reference features feed them straight into the build, and facts beat descriptions of facts every time.
