← All posts

How to build a website with Claude Code: a client site in an afternoon

How to build a website with Claude Code for a client: brief, content model, pages, theme and staging, step by step, with a human reviewing before launch.

4 November 2026 6 min read by Contentive · Team

"A client site in an afternoon" is the kind of claim that usually falls apart on contact. So let's be precise about what it covers before going through the steps.

It covers a brochure site: five to eight pages, a contact form, a services list, a team section, maybe a short news area. It assumes the copy is written, or at least drafted, and that the brand exists: a logo, two or three colours, a typeface. With those in hand, an agent can do most of the assembly while you do the judging.

It takes longer when the copy isn't ready, when the client hasn't decided what they sell, when there are integrations, or when the design is meant to be distinctive rather than clean. None of those are agent problems. They're project problems, and an agent won't solve them for you.

Before you start

Set up a new workspace for the client. Keep it separate from anything live, so the agent has room to make a mess you can throw away.

Connect Claude Code to Contentive's MCP server. There are two ways. The remote connector is a URL you add to Claude Code, which signs you in with OAuth. The local server runs on your machine over stdio with a scoped token. Either gives the agent the same tools. If you want the background, what is MCP explains the protocol, and why there's no AI chat box explains why we expose tools rather than a prompt box.

Then make a folder in your repo for the project and write the brief there, as a markdown file the agent can read. More on what goes in it below.

Step by step

Ask the agent to read the workspace first. It should call describe_schema before doing anything else. On a new workspace the answer is "nothing here yet", and that's useful too.
Apply or create the content model. For a standard brochure site, a starter model gets you most of the way: a page type and stacks for common sections. The agent can apply one with apply_template and then add what the brief needs, such as a services type with a price field or a team type. For anything unusual, have it propose the model in plain language first and approve it before it creates anything.
Compose the pages. The agent creates each page from the brief's copy and composes it from blocks: a hero, a services grid, testimonials, a call to action. Pages are content, so the client can reorder those blocks later.
Create the contact form. Use create_form, with a notify email and a redirect, and put it on the contact page as a form block. Don't let the agent build a form out of plain fields. It would look right and send nothing.
Write the theme as local files. A new workspace has no theme yet, so deploy the starter theme first, from the Studio or with the agent's deploy_theme tool. Then run contentive login and contentive theme pull to get it into your repo. The agent edits the Liquid layout, a template per content type, a template per section and the theme CSS, as ordinary files.
Check it locally. contentive theme dev renders the theme on your machine against the workspace's live content, including drafts, using the production renderer, and reloads as files change. You and the agent look at the same pages.
Push to staging. contentive theme check, then contentive theme push. Push only ever goes to staging.

The review

This is the part that can't be delegated. Open the staging site and read every page, start to finish, as the client's customer would. Check every link. Submit the contact form and confirm the email arrives. Look at it on a phone.

Staging is private by default, so send the client a preview link if they need to see it. When you're both happy, promote staging to production in the Studio. The agent can promote with promote_deployment too, but the first launch of a client site is a decision a person should make.

What the agent gets wrong, and how the brief prevents it

It invents fields when the brief is vague. Ask for "a team page" and you may get a team type with nine fields, three of which the client will never fill in. Fix it in the brief: list the fields you want on each type, and tell the agent to ask before adding any others.

It writes generic copy. Given gaps, an agent fills them with confident, empty sentences. Fix it by providing the copy, and by telling the agent never to write copy that isn't in the brief, but to leave a clearly marked placeholder instead.

It over-designs sections. Left alone, it adds gradients, animations and extra decorative sections. Fix it with constraints: the colours, the type scale, the spacing, the sections allowed on each page and a sentence like "plain and clean, no decorative animation".

Afterwards

Nothing the agent built is special. Every content type, page and form is an ordinary object the client can edit in the Studio, with version history. The theme is files in your git, so the next developer can pick it up without the agent. That's the point of building this way: the agent saves time on the assembly, and leaves behind a normal site.

What it costs

Your judgement is still the bottleneck. The agent can assemble faster than you can review, and an unreviewed site is not a finished one. Budget review time as real time.

The quality also depends on the agent you bring and the brief you write. A strong model with a weak brief produces a plausible, generic site. A good brief is most of the work.

The brief template

Here's the shape of the brief we'd start from. Copy it into the repo and fill it in.

Client and audience. One paragraph: who they are, who visits, what visitors should do.
Pages. Each page by name, with its sections in order.
Content types and fields. Each type, each field, required or not. "Ask before adding fields."
Copy. Pasted in, or a link to the file. "Never write copy; leave a placeholder."
Brand. Logo file, colours, typefaces, spacing, and one line on tone.
Form. Fields, who gets notified, where to redirect.
Constraints. No animation, no extra sections, no external scripts.
Done means. Pushed to staging, form tested, nothing promoted.