Skip to main content
HoTMoL.io Logo HoTMoL.io Logo

From Client Brief to Live Site in an Afternoon

How HoTMoL's chat-driven intake workflow turns raw client copy (from a form submission, a Word doc, or freeform notes) into a fully structured Astro site in a single Claude Code session.

From Client Brief to Live Site in an Afternoon

The slowest part of building a service-business website isn’t the code. It’s the translation layer between what the client sends you and the structured content your components actually need. A wall of text in an email, a Google Doc full of bullet points, a Fluent Forms submission with services jammed into a single textarea. The intake workflow was built to eliminate that bottleneck entirely.

How It Works

There is no CLI command and nothing to install. You open a Claude Code chat session in the project and drop in whatever the client sent you, in any format: a pasted email, a Word doc, a bulleted list, a form export. Claude reads it directly and infers the structure. Business name, tagline, description, services with names and descriptions, team members, locations, testimonials, and FAQs are all parsed, normalized, and written to a single reviewable file before anything touches the codebase.

The Checkpoint Step

Before any content files are written, Claude writes scripts/brief.json as a checkpoint and asks you to review it. This is the most important part of the workflow. Claude is good at parsing unstructured input, but a client who writes “we do landscaping and also some irrigation stuff and snow removal in winter” needs a human to decide whether that’s two services or three, and what to call them. If anything is ambiguous, Claude asks before writing content, rather than guessing.

Read through brief.json, correct anything that looks off, and tell Claude to proceed. There is no separate import command to run. Once you confirm the brief, Claude writes the content files in the same session.

What Gets Written

Claude writes Markdown and YAML files for every content collection that has data in the brief:

  • src/content/services/*.md: one file per service, with title, description, and metadata
  • src/content/team/*.yaml: one file per team member
  • src/content/locations/*.md: one file per service area
  • src/content/testimonials/*.yaml: one file per review, real quotes only

The site config at src/content/config/site.yaml gets the business name, contact info, social links, and global CTA defaults. Everything the header, footer, and schema components need is populated automatically.

From There to Live

With content in place, the workflow becomes assembly, still inside the same chat session:

  1. Claude opens each page in src/pages/ and wires up components to match the content
  2. Client images get sourced or dropped into public/images/[type]/
  3. If the copy is thin, Claude rewrites the weak sections directly, no separate pass required
  4. npm run build and deploy

For a typical 6-8 page service-business site (home, about, services index, slug pages, locations, contact) the assembly step takes a couple hours of back-and-forth in the chat. The intake step takes a few minutes once the raw copy is in hand. That’s the whole day’s work.

Why This Matters

The intake workflow doesn’t replace developer judgment. It eliminates the mechanical translation work so you can spend your time on the decisions that actually require judgment: which hero variant fits this client’s brand, how to sequence the sections, whether the testimonials are strong enough to lead with. That’s where the value is. The workflow just clears the path to get there.