Skip to content
BekDigital Lab

The prompt system I use to build client websites

Two documents instead of one prompt — a permanent quality standard, and a per-client brief. Why the split is the part that actually works.

Published

20 Aug 2026

Type
Prompt pack
Level
intermediate
Made for
  • Claude Code
Read time
4 min

Ask an AI to "build a premium website for a restaurant" and you will get the same site every time: hero, three cards, an about section, three feature cards, testimonials, FAQ, CTA, footer. It is competent and completely forgettable, and you can spot it from across the room.

The fix is not a cleverer sentence. It is separating two things that people usually mash into one prompt.

The split

Document one is a standard. It never changes between projects. It covers what "finished" means — accessibility, performance, colour discipline, animation rules, what counts as a real feature versus a fake one, and an explicit list of the patterns to avoid. It is long on purpose.

Document two is a brief. It changes every time. Business, audience, location, goal, brand feeling, references, real content, things to avoid.

Then you hand over both.

The standard stops the output being sloppy. The brief stops it being generic. One without the other gives you either a polished template or a distinctive mess.

Why the standard has to be long

The instinct is to keep prompts short. That is right for questions and wrong for production work, because most of what makes a site feel cheap is a decision that was never made — nobody said what should happen to a card with no image, so you get a grey box.

Every rule in my standard exists because something came out wrong once. That is the only good reason for a rule to be in there.

The parts that change the output most

These four earn their place more than anything else in the document:

  1. An explicit anti-pattern list. Naming the generic structure — hero, three cards, about, three features, testimonials, FAQ — and forbidding it unless it genuinely fits. Nothing else moves the result as much as this one paragraph.
  2. Banning invented credibility. No fake reviews, ratings, awards, statistics, years of experience, or client logos. Ever. Placeholder content must be obviously placeholder. This is the rule that makes the output safe to show a real client.
  3. "When integration is missing, create a clean integration point." Stops you getting a contact form that looks like it works and silently does nothing.
  4. A self-critique step. Requiring a pass that lists the weaknesses before declaring the work done. The first draft is never the one worth shipping.

The condensed version

The full standard is long. This is the core I would paste if I only had room for one screen:

You are acting as senior creative director, UI/UX designer, frontend engineer,
accessibility specialist and performance engineer.

Build a production-ready website for a real business. It must be good enough to
present to a paying client and deploy publicly.

BEFORE BUILDING, ask me about: the business, its location and audience, the goal
of the site, the services, what content and branding already exist, brand colours
and fonts, the feeling it should have, anything to avoid, and 1-3 reference sites.

DESIGN
- Choose a palette deliberately: 3-4 colours plus neutrals, and say why.
- Choose typography from the industry, not habit.
- Do not use a centred hero by default. Pick the composition that fits.
- Adapt the section list to the business. Do not add sections for length.

DO NOT PRODUCE
- Hero -> three cards -> about -> three features -> testimonials -> FAQ -> CTA,
  unless that genuinely fits this business.
- Generic AI purple/blue gradients, or gradients used because they look modern.
- Invented reviews, ratings, awards, statistics, experience or partnerships.
  Use obvious placeholders when information is missing.
- Interfaces that pretend to work. If there is no backend, build a real
  integration point instead.

NON-NEGOTIABLE
- Semantic HTML, keyboard access, visible focus, WCAG AA contrast.
- Respect prefers-reduced-motion. Never hide content behind animation.
- Optimised, responsive, lazy-loaded images. Minimal dependencies.
- Mobile designed intentionally, not shrunk from desktop.
- No console errors, no unfinished sections, no dev artifacts.

FINISH BY
Critiquing your own output: visual design, UX, animation, responsive behaviour,
accessibility, performance. Then fix what materially improves it.

How to adapt it

Add your own anti-patterns. Mine are aimed at web work. If you keep receiving the same wrong thing, that sentence belongs in your standard, not in a follow-up message.

Keep the ask-me-first step. It is tempting to cut it and paste everything up front. The questions are what stop it inventing a business that does not exist.

Do not soften the credibility rule. It is the difference between a site you can send to a client and one you have to audit line by line first.

Where it breaks

It will not save a project with no real content. If there are no photos, no copy, no services list and no contact details, you get a beautifully built empty shell — and the standard is honest enough to leave visible gaps rather than fill them with invented material. That is correct behaviour, and it still means you need the content.

It is also overkill for a landing page you will throw away in a week.

Tagged
  • prompts
  • web-development
  • claude-code
  • design
  • workflow
Related
If this helped

Tell me what you built with it.

Genuinely useful feedback is what decides which resource gets written next.