Building client websites with Claude

Five pieces have to exist before Claude is useful. Each has one job. Understand them and every error message later makes sense.

What "connecting Claude to a website" means

There is no button that plugs Claude into a URL. Claude connects to the files behind the site. Three setups, in order of how often we use them:

Confirm: http://localhost:8888 (Mac) or http://localhost (Windows) shows a server page, not an error.

Laragon: right-click the tray icon → Quick app → WordPress, name it granitostatyba, skip to step 3. Everyone else — don't do this by hand. Let Claude do it:

1. Open a terminal in the web root and start Claude:

   Terminal — macOSzsh

   $ cd /Applications/MAMP/htdocs
   $ claude

2. One prompt sets up everything — database, WordPress files, and debugging:

   Claudeprompt

   > Set up a new local WordPress site in ./granitostatyba on
   > this MAMP server:
   >
   > 1. Create a MySQL database `dmnt_granitostatyba` with
   >    collation utf8mb4_unicode_ci, using MAMP's mysql at
   >    localhost:8889, user root / root.
   > 2. Download the latest WordPress and unzip it into
   >    ./granitostatyba.
   > 3. Create wp-config.php pointing at that database, and
   >    enable WP_DEBUG with logging to wp-content/debug.log
   >    but with display off.
   >
   > Done means: http://localhost:8888/granitostatyba loads the
   > WordPress installer with no database error.

   Claude runs the terminal commands, shows you each one, and asks before anything destructive.

3. Finish in the browser — the only part that needs you. Open http://localhost:8888/granitostatyba, pick Lietuvių as the site language, and create the admin user with a local-only password. Never put a client's real credentials on your laptop.

1. Install VS Code from code.visualstudio.com.

2. Install these extensions (Cmd/Ctrl+Shift+X):

   • PHP Intelephense — autocomplete and error highlighting
   • WordPress Snippets — hook and function shortcuts
   • EditorConfig — consistent formatting across the team

3. Enable the terminal command: Cmd+Shift+P → Shell Command: Install 'code' command in PATH. Windows does this automatically.

4. Open the plugins folder — not the whole WordPress install. This is the step people get wrong:

   Terminalzsh

   $ code /Applications/MAMP/htdocs/granitostatyba/wp-content/plugins

1. Install Node.js 18+ from nodejs.org. Verify with node --version.

2. Install Claude Code:

   Terminalzsh / PowerShell

   $ npm install -g @anthropic-ai/claude-code
   $ claude --version

3. Open the VS Code terminal (Ctrl+`) inside the plugins folder and run claude. First run installs the VS Code extension and adds a Claude panel to the sidebar.

4. Authenticate with /login. Use the DMNT account, not a personal one — client work stays on agency billing.

5. Verify. Ask something only a connected Claude could answer:

   Claudeprompt

   > List every plugin folder here and tell me which are active,
   > based on their main plugin file.

   Real folder names → connected. Invented names, or a request to paste files → wrong folder, go back to Phase 03.

Commands worth memorising

Claude reads CLAUDE.md at the start of every session. Anything in it becomes a standing instruction, so you stop repeating yourself. Run /init, then edit the draft to look like this:

# UAB „Granito statyba" — granitostatyba.lt

## Environment
- Local: MAMP · http://localhost:8888/granitostatyba
- WordPress 6.x · PHP 8.2 · Elementor (free) + Hello Elementor child theme
- Live: https://granitostatyba.lt — never edited directly

## Architecture
- Every landing-page section is a custom Elementor widget in
  the plugin `dmnt-granito-widgets`. No sections built by hand
  in the Elementor editor.
- Widget classes: widgets/class-{name}-widget.php, one class per file
- Shared CSS: assets/css/widgets.css — BEM, prefix .dmnt-

## Conventions
- Prefix everything `dmnt_` — functions, hooks, options, CPTs
- Text domain: `dmnt-granito` · all UI strings translatable
- Site content is Lithuanian — keep ąčęėįšųūž intact, never transliterate
- Every widget needs the standard style section: padding, background,
  heading + body colour and typography, accent colour, button with
  hover, item gap, alignment — all responsive
- Escape all output, clean all input, protect every form
- Follow WordPress Coding Standards

## Rules
- Never edit WordPress core, Elementor, or the parent theme
- Never hardcode text that the client might want to change —
  it belongs in a control
- Ask before adding a Composer or npm dependency

In this workflow you rarely write code or type terminal commands by hand — you describe the result and Claude does the work. That makes the prompt the real tool. A weak prompt costs an hour of back-and-forth; a strong one gets it right the first time.

The four parts of a strong prompt

1. What — the exact thing to build or change, named precisely. Not "a section", but "an Elementor widget dmnt_stats in widgets/class-stats-widget.php".

2. Where — the file, widget or page it touches, so Claude doesn't guess. Name the path.

3. Constraints — the rules that apply: prefix, text domain, escaping, "follow the structure of the hero widget", "no new dependencies". Anything in CLAUDE.md is applied automatically; add only what's specific to this task.

4. Done means — how you'll judge the result: "the client can change every colour from the Style tab", "activating throws no notices in debug.log".

Bad prompt vs good prompt

Working rules

• One task per prompt. Six features in one prompt = six half-built features and no idea which broke the page.
• Plan mode first (Shift+Tab) for anything touching more than one file — read the plan, correct it, then approve.
• Paste errors verbatim — the full message from debug.log or the browser console, never a paraphrase like "it shows some error".
• Point at an example — "follow the structure of class-hero-widget.php" beats three paragraphs of description.
• Say what you'll test — when Claude knows "done" means the form email arriving, it writes toward that instead of toward "code that looks finished".
• Iterate, don't restart — if the result is 80% right, name the 20%: "keep everything, but the gap between cards should be a responsive slider control".
• /clear between unrelated tasks — old conversation context bleeds into new work.

Before any code: list the page's sections top to bottom, and decide which becomes a widget. One section, one widget, one file. Do this on paper or in a text file — it takes fifteen minutes and it determines everything after it.

Which sections become widgets

1. Install Elementor (Plugins → Add New → Elementor).

2. Choose the theme — two good options:

   Theme	Pick it when	Watch out for
   Hello Elementor (our default)	The whole site is built in Elementor — it's a blank canvas made by the Elementor team, fastest and least likely to fight your widgets	It's too blank: it ships almost no styling, so buttons, links, form fields and headings fall back to ugly browser defaults until you define every one of them in the Global Kit (next steps)
   Twenty Twenty-Five	The client will also edit content with the block editor, or you want sensible typography and colours out of the box	Its own theme styles sit underneath Elementor's — when a widget looks wrong, you're debugging two style systems instead of one

   This SOP continues with Hello Elementor.

3. Create a child theme so theme edits survive updates. Ask Claude:

   Claudeprompt

   > Create a Hello Elementor child theme in
   > ../themes/granito-child — style.css with the correct
   > Template header, functions.php enqueuing parent then child
   > styles, and a screenshot placeholder. Text domain granito.

4. Set the Global Kit in Elementor → Site Settings. This is the brand, defined once; every widget inherits it.

   Global token	Value	Used for
   Primary	#1F2A2E betono pilka	Headings, header, footer
   Secondary	#5A6670	Body text
   Accent	#D4610A signalinė oranžinė	Buttons, links, numbers
   Text	#2B3134	Paragraphs
   Primary font	Barlow Condensed 700	Headings
   Secondary font	Inter 400	Body

5. Override Hello Elementor's defaults. Hello ships with its own fallback colours and sizes that will leak through anywhere the kit is silent. Close every gap while you're in Site Settings:

   • Elementor → Settings → General — tick Disable Default Colors and Disable Default Fonts, so the Global Kit always wins over theme defaults
   • Site Settings → Typography — set body text and H1–H6 sizes explicitly; Hello's heading sizes are browser defaults
   • Site Settings → Buttons — text colour, background, hover colour, border radius and padding; unstyled Hello buttons are grey boxes
   • Site Settings → Form Fields — field text, background, border and focus colour, or the quote form inherits bare browser inputs
   • Site Settings → Typography → Link colour — normal and hover, or links stay browser blue

6. Set the container width to 1200px and enable Flexbox Containers in Elementor → Settings → Features. Everything below assumes containers, not the legacy section/column system.

Ask for "a modern, clean hero section" and you get the same page every AI has produced for the last two years: purple gradient, centred headline, three identical rounded cards, stock photo of strangers in hard hats. Clients recognise it now. Their customers recognise it too.

For a construction company selling we build things that last, a page that looks mass-produced quietly contradicts the pitch. Slop is not a rendering problem you clean up afterwards — it's what a prompt returns when it wasn't told what to do instead.

The tells, side by side

Preventing it in the prompt

All five rules below go into the widget prompts from Part III. They cost one extra paragraph and save a redesign.

1. Name a direction, never "modern and clean". Those words mean nothing, so Claude fills the gap with the average of everything it has seen. "Heavy, industrial, photo-led, closer to a materials catalogue than a tech startup" gives it somewhere to go.

2. Feed it the client's world. Their materials, their machinery, their signage, the vocabulary from their quotes. That's where non-generic choices come from.

3. Ban the defaults out loud. "No gradient backgrounds, no stock photography, no emoji icons, no centred hero, no identical cards." Explicit bans work; hoping doesn't.

4. Bring real content first. Real Lithuanian copy and real project photos before styling. Lorem and placeholders hide every layout problem until launch day.

5. Ask for hierarchy, not uniformity. Say which element should be seen first, second, third. Left alone, everything comes out the same size — the visual signature of slop.

Bad prompt vs good prompt

The review pass, before the client sees it

Six questions. A "no" anywhere means go back to the prompt, not to the CSS.

• Cover the logo — is this page still recognisably this company, or could it belong to any firm anywhere?
• Does every photograph come from the client?
• Is there a clear first, second and third in visual weight, or is everything shouting equally?
• Can you say why each colour is on the page, tracing it to something real?
• Does the copy contain a fact a competitor could not honestly copy — a year, a number, an address?
• Is anything on the page there only because pages like this usually have one?

> Review this landing page against the AI-slop checklist in
> Phase 09 of our SOP. Be harsh. For each item that fails,
> name the widget, say why it reads as generic, and propose
> a specific fix drawn from this client's own materials and
> photos. Don't change anything yet.

> Create an Elementor widget plugin at
> `dmnt-granito-widgets` (name: "DMNT Granito Elements").
>
> Requirements:
> - Block direct file access, and namespace the code
> - Show a friendly admin notice instead of breaking the site
>   if Elementor is inactive or older than version 3.5
> - Register an Elementor category "Granito statyba"
> - Pick up any widget file I add to widgets/ automatically
> - Enqueue assets/css/widgets.css on the frontend AND inside
>   the Elementor editor
> - Text domain dmnt-granito, languages/ folder
>
> Structure only — no widgets yet.

What you should get

dmnt-granito-widgets.php   ← header, guards, bootstrap
includes/
  class-plugin.php         ← hooks, category, asset loading
widgets/
  class-hero-widget.php    ← one file per section
  class-services-widget.php
  ...
assets/
  css/widgets.css
  js/widgets.js
languages/
uninstall.php
readme.txt

What must be true when it's done

• A Granito statyba category appears in the Elementor widget panel
• Every widget file you add to widgets/ registers itself automatically
• The plugin's styles load on the site and inside the Elementor editor preview
• Deactivating Elementor shows a friendly admin notice instead of a broken site

You never need to read the wiring code Claude writes. If any of those four isn't true, describe which one to Claude — it fixes its own plumbing.

Activate the plugin. Open any page in Elementor — a Granito statyba category should appear in the widget panel, empty for now.

You don't type any of this by hand — Claude writes it from a prompt like the one below. But you are the developer of record, so you must be able to read it. Every widget is one class with four jobs: identify itself, declare its controls, render HTML, and map controls to CSS. Walk through the Hero once and the other six are variations.

> Create the first widget: `dmnt_hero` in
> widgets/class-hero-widget.php.
>
> Content tab: eyebrow text, heading (textarea) with a
> heading-tag SELECT, CTA text + URL control, background
> image. Lithuanian defaults from the brief in CLAUDE.md.
>
> Style tab: heading colour + typography group, responsive
> bottom-spacing slider, responsive section padding
> (DIMENSIONS), alignment CHOOSE. Colours default empty so
> the Global Kit applies.
>
> Escape every output. CSS in assets/css/widgets.css under
> .dmnt-hero BEM classes.
>
> Done means: the widget appears under "Granito statyba" in
> the Elementor panel and every text and colour is editable
> from the sidebar.

What comes back does four jobs. You don't read the code — you check each job in the Elementor editor:

1. Identity — how the widget introduces itself. Its name, title, icon and category.

   Check: it appears in the panel under Granito statyba as "Granito — Hero" with a banner icon.

2. Content controls — what the client types. One sidebar field for every editable thing: eyebrow, heading, button text and link, background photo.

   Check: the Turinys tab shows those fields, already filled with the Lithuanian defaults from the brief.

3. Style controls — what the client restyles. Colour pickers, typography, spacing sliders and alignment — each wired to one part of the section, with separate values per device.

   Check: changing the heading colour changes only this widget's heading, and the tablet / mobile icons next to sliders give separate values.

4. Render — the HTML visitors receive. Takes whatever the client set in the sidebar and prints it safely on the page.

   Check: the section updates live in the preview as you type.

Reload the Elementor editor. The Hero widget now appears under Granito statyba, drags onto the page, and every field in the sidebar edits it live.

Every section must be fully editable — text, colour, size, spacing, everything. These are the controls that make that true. Ask for them by name and Claude writes them correctly first time.

Content controls

Style controls

Three modifiers worth knowing

The standard style section — every widget gets all eight

• Section padding and margin — responsive DIMENSIONS
• Background — Group_Control_Background
• Heading colour + typography
• Body text colour + typography
• Accent/number colour where the section has one
• Button colour, background, border, radius, padding — with a hover tab
• Gap between items — responsive SLIDER
• Alignment — responsive CHOOSE

Most sections are a list of similar items. That's a repeater: the client adds, removes and reorders rows without touching code.

> Create widget `dmnt_services` — a services grid.
>
> Content tab: section heading, plus a REPEATER of services —
> each row has an icon, pavadinimas and aprašymas. Defaults:
> Namų statyba, Renovacija, Vidaus apdaila, Stogo dengimas,
> each with a one-line Lithuanian description.
>
> Style tab: the standard style section, plus card
> background / border / radius / hover, and columns per device.
>
> Escape every output.
>
> Done means: in the sidebar I can add a fifth service, drag
> rows to reorder them, and each row is labelled by its
> pavadinimas.

Test it exactly the way the client will use it: add a row, delete a row, drag one to reorder. If any of that feels wrong in the sidebar, say so in one sentence and let Claude adjust.

Build the remaining widgets

One widget per Claude session. Working page after each. The pattern is identical, so this goes fast.

The projects section shouldn't be a repeater — the client adds projects as content, not as page design. So: a custom post type plus a widget that queries it.

1. Register the post type in the same plugin:

   Claudeprompt

   > In includes/, register a custom post type `dmnt_objektas`
   > (labels in Lithuanian: Objektas / Objektai), public, with
   > title, editor, thumbnail and excerpt. Add a taxonomy
   > `dmnt_objekto_tipas` (Namas, Renovacija, Apdaila, Stogas).
   > Add meta fields: vieta (text), metai (number),
   > plotas_m2 (number) — each one cleaned before saving.
   >
   > Done means: an "Objektai" menu appears in wp-admin and I can
   > add a project with a photo, location, year and floor area.

2. Build the widget — controls for how it queries, not what it says:

   Claudeprompt

   > Create widget `dmnt_projects` that queries the
   > dmnt_objektas post type.
   >
   > Content tab: NUMBER of projects to show, SELECT2 filter by
   > dmnt_objekto_tipas, SELECT for ordering (date / title /
   > plotas_m2), SWITCHERs for the vieta, metai and m² badges.
   >
   > Style tab: the standard style section from CLAUDE.md.
   >
   > Query efficiently — always a fixed limit, never "all posts",
   > and card thumbnails use a resized image, not the full photo.
   >
   > Done means: the widget shows real Objektai posts and the
   > filter, order and badge toggles all visibly work.

3. Add three real projects in wp-admin with photos. Placeholder content hides layout problems that real content exposes — a project name in Lithuanian is longer than "Project One".

All the engineering is behind you. Assembly takes twenty minutes.

1. Create a page named Pradžia and set it as the front page in Settings → Reading. Choose the Elementor Canvas or Full Width template.

2. Edit with Elementor. Open the Granito statyba category — all seven widgets are there.

3. Drag them in wireframe order: hero, stats, services, process, projects, reviews, quote form. Each lands with sensible Lithuanian defaults already in place, because you set 'default' on every control.

4. Wrap each widget in a Flexbox Container and set the container's width and vertical padding there. Section-level spacing belongs to the container; internal spacing belongs to the widget's own controls.

5. Give the quote form's container the CSS ID samata so the hero button's #samata link scrolls to it.

6. Check every breakpoint with Elementor's responsive preview — desktop, tablet, mobile. Fix problems using the responsive controls you built, not by adding custom CSS.

7. Hand the page to the client's shoes: change a heading, swap a colour, reorder two services, add a fifth. If any of that needs a developer, a control is missing — go back and add it.

The widgets are page-agnostic. The remaining pages are mostly recombinations.

Header and footer

Elementor's free tier has no theme builder, so header and footer live in the child theme's header.php and footer.php, or come from a header/footer plugin. Whichever route, the menu is a real WordPress menu the client can reorder — never a hardcoded list of links.

• Charset — database utf8mb4, page <meta charset="UTF-8">, files saved UTF-8. Test with „Šiaurės Ąžuolų g. 12, Vilnius" — if it renders as question marks, stop and fix the collation before adding content.
• HTML lang — <html lang="lt-LT">; WordPress sets this from the site language.
• Phone format — display +370 6XX XXXXX, link as tel:+3706XXXXXXX.
• Cookie consent — required under EU rules. Consent must be given before analytics loads, and refusing must be as easy as accepting.
• Privacy policy — a real page naming the data controller, what the form collects, retention period, and the visitor's GDPR rights.
• Form consent — an unticked checkbox linking to the policy. Pre-ticked is not consent.
• Data minimisation — collect only what's needed to send an estimate. No IP logging you can't justify.
• Fonts — self-host, don't hotlink Google Fonts. Serving them from Google's servers has been ruled a GDPR problem in the EU.
• Lithuanian sorting and dates — Y-m-d, and don't sort Lithuanian names with PHP's default collation.
• Accessibility — form labels tied to inputs, visible focus, alt text on project photos in Lithuanian.

• Every widget drags in cleanly and renders in the editor preview, not just on the frontend
• Every control actually changes something — click through all of them once
• Responsive values work on tablet and mobile independently
• Deleting all repeater rows doesn't fatal the page
• Leaving an image or link empty degrades gracefully
• Lithuanian characters render correctly in the editor, on the frontend, and in form emails
• Deactivating the plugin doesn't white-screen the site — pages lose sections, that's expected
• Deactivating Elementor shows the admin notice, not a fatal error
• Test as Administrator, Editor and Subscriber
• Browser console clean; debug.log empty
• Switch to a default theme — widgets still render

Live log while you test

$ tail -f /Applications/MAMP/htdocs/granitostatyba/wp-content/debug.log

Leave that running. When something breaks the cause appears in real time — copy it to Claude verbatim, file path and line number included.

Run /security-review in Claude — it checks the technical details. Then ask it to confirm each line below in plain yes/no terms, and read the answers:

• Nothing prints unescaped — no text from a control reaches the page raw
• The quote form can't be faked — submissions are verified as coming from the real form
• Every form input is cleaned before it's saved or emailed
• The name field can't smuggle email headers into the outgoing message
• Bots are slowed down — a honeypot or rate limit on the form
• Files block direct access when opened outside WordPress
• No passwords or keys in the code — secrets live in wp-config.php
• No debug leftovers — no test output shipping to the live site

> Go through the security checklist in Phase 19 of our SOP
> against every widget in this plugin. Answer each line
> yes/no with the file that proves it. Fix any "no" and show
> me what changed.

• Project and hero photos resized and converted to WebP — construction photography is enormous by default
• loading="lazy" on everything below the fold; the hero image explicitly not lazy
• Widget CSS in one file, enqueued once, no inline <style> blocks per widget
• Caching plugin configured (WP Rocket, LiteSpeed, or the host's own)
• One <h1> per page — the hero heading; everything else h2/h3
• Title and meta description per page, in Lithuanian, written for people not keywords
• LocalBusiness schema with address, phone, opening hours and service area
• Google Business Profile linked; NAP details identical to the footer
• XML sitemap submitted to Search Console for the .lt domain
• PageSpeed Insights on mobile — target 90+ before handover

1. Back up the live site first if one already exists — files and database. Do it even if the host claims automatic backups.

2. Export the local site. Install All-in-One WP Migration on your local WordPress → All-in-One WP Migration → Export → File. It packages the whole site — pages, widgets, plugin, photos, database — into one .wpress file.

3. Prepare the live server. Fresh WordPress install on the host, then install All-in-One WP Migration there too. If the export file is bigger than the upload limit, raise upload_max_filesize in the host's PHP settings, or use the plugin's file-size extension.

4. Import — All-in-One WP Migration → Import → File, choose the .wpress file, confirm. The plugin rewrites localhost:8888/granitostatyba to granitostatyba.lt automatically, including inside Elementor data.

5. Log back in — the import replaced everything, so use your local admin username and password. Then go to Settings → Permalinks and click Save once to refresh the URL rules.

6. Confirm SSL — the site loads on https:// with a valid padlock. Most hosts issue the certificate in one click.

7. Re-run the Phase 18 checklist on the live domain. Most importantly: submit the real quote form once and confirm the email arrives at the client's inbox.

Some bugs exist only on the host. Two ways to give Claude access — both read-only until you're certain.

A · SSH into the host

$ ssh dmnt@granitostatyba.lt
$ cd ~/public_html/wp-content/plugins/dmnt-granito-widgets
$ claude

Or use VS Code's Remote–SSH extension to open the remote folder locally, keeping the Claude panel where you're used to it.

B · WP-CLI for content and database work

$ wp plugin list --status=active
$ wp post list --post_type=dmnt_objektas --format=table
$ wp search-replace 'http://old.lt' 'https://granitostatyba.lt' --dry-run

New section widget

> Add a new Elementor widget `dmnt_process` to
> dmnt-granito-widgets, following the exact structure of
> widgets/class-hero-widget.php.
>
> Content: section heading, and a repeater of steps with
> title + description. Lithuanian defaults: Konsultacija,
> Sąmata, Statyba, Objekto perdavimas.
>
> Style: the standard style section from CLAUDE.md, plus
> step-number colour and size, connector line colour, and a
> horizontal/vertical layout SELECT.
>
> Escape every output. Add the CSS to assets/css/widgets.css
> using .dmnt-process BEM classes.

Add missing controls to an existing widget

> The client can't change the hero button's colours. Add a
> Style section for the button with normal/hover tabs:
> text colour, background, border group control, border
> radius, responsive padding, and typography. Leave defaults
> empty so the Global Kit applies.

Debugging a fatal

> The page fatals when the services repeater is empty. Here
> are the last 20 lines of debug.log: [paste]
> Find the root cause, explain it in one sentence, fix it,
> and check the other widgets for the same mistake.

Pre-release review

> Review every widget in this plugin against WordPress Coding
> Standards and the security checklist in CLAUDE.md. Flag any
> unescaped output, any hardcoded colour or size that should
> be a control, and any missing {{WRAPPER}}. List issues by
> severity with file and line. Change nothing yet.

Client handover docs

> Write a client guide in Lithuanian explaining how to edit
> each section of the landing page in Elementor: which widget
> is which, what each control does, and how to add a new
> Objektas. Plain language, no technical jargon.

The site is finished when every line below is true. Not before.

• Every wireframe section exists as its own widget
• Every piece of visible text is editable through a control — nothing hardcoded
• Every section has colour, typography and spacing controls, responsive per device
• Client can reorder, restyle and add items without a developer — verified by doing it
• Phase 09 review passed — the page reads as this company, not as a template
• Phase 18 test checklist passes with an empty debug.log
• Phase 19 security checklist passes with no blocking issues
• Phase 17 Lithuanian and GDPR requirements all met
• Mobile PageSpeed 90+; one h1 per page; schema in place
• Quote form tested end to end on the real domain, email received
• A .wpress export saved in the client's project folder
• Deployed to live and the Phase 18 checklist re-run on the real domain
• Lithuanian client guide delivered; a second DMNT developer has reviewed the diff