Local Business Websites With Claude: The Real Math

Two numbers about local business websites with Claude sit next to each other and refuse to make sense together.

The first: a professional small business website in 2026 costs between $2,000 and $8,000, with agency builds running $5,000 to $30,000, according to the 2026 pricing surveys published by Levitate and OuterBox. Ongoing hosting, security, and backups add another $1,100 to $5,000 a year.

The second: I can get Claude to produce a site for a roofing company in Austin that looks better than that roofing company's current $6,000 site in roughly the time it takes to make coffee.

Both numbers are true. The gap between them is where an entire service business now lives — and where a lot of people are about to get burned, because building local business websites with Claude is genuinely eight minutes of work wrapped in about three hours of work that nobody puts in the demo video. I've been building and maintaining client sites for over eight years through my agency, and the parts that generate the support tickets, the churn, and the awkward month-two conversations have not changed just because generation got fast.

I want to walk through the whole pipeline: the reference-driven design method, the build corrections I make every single time, the SEO layer, the Netlify form wiring, the AI reply loop, and how to compress it into a reusable Skill. But I'm going to keep stopping to show you the arithmetic that the pitch skips. There's one calculation in particular — about a hero video — that will decide whether your client's site is still online in week six.

Start with the eight minutes, because the eight minutes is real. It just isn't the deliverable.

How long does it take to build local business websites with Claude?

When someone says Claude built a business website in eight minutes, they are measuring one thing: the time from prompt submission to a rendered page in a browser. That measurement is honest and it is also nearly useless for pricing, because it excludes everything a client is actually paying for.

Here's the split I'd expect on a real roofing, HVAC, dental, or landscaping site.

Genuinely minutes: layout generation, component structure, responsive behavior, color system, typography scale, animation, the FAQ block, the service card grid, meta tags, robots.txt, sitemap.xml, and the JSON-LD schema block. Claude Opus 5 — released July 24, 2026 with a 1M-token context window — will hold an entire multi-page site in context and revise it coherently. This part is not hype. It works.

Genuinely hours: every fact on the page. The business's real service area. Whether they actually do commercial or only residential. Their license number. Their insurance carrier. The correct spelling of the owner's name. Their real phone number formatted so it dials on mobile. Their hours, including the seasonal ones. Whether the five-star reviews you're about to quote are theirs and whether you have permission to quote them.

Genuinely a day, spread across a week: DNS propagation, the client finding their registrar password, the client's brother-in-law who "does computers" wanting a call, and the two rounds of "can we make the logo bigger."

Charge for the second and third buckets. The first bucket is your margin, not your product.

That distinction matters more than it sounds, because it determines what you say on the sales call. If you sell speed, you have priced yourself into a race with the next person who watched the same video. If you sell the accurate, indexed, lead-capturing outcome, the eight minutes is just how you keep the margin.

So how do you get the eight minutes to produce something that doesn't look like every other AI site? You stop describing and start showing.

Designing from a real reference instead of a text prompt

The single biggest quality jump in this workflow has nothing to do with the model. It's the input.

Describing a website in prose gets you the model's average of every website. Feeding it a screenshot of a specific high-converting competitor gets you that competitor's structural decisions, applied to your client's business. Those are wildly different outputs from the same model.

My selection method: search the client's exact service and city, then ignore the organic results. Look at who's paying for the ad slot and who has the review volume — a roofing company sitting on a thousand five-star Google reviews and running sponsored placements has already paid to learn what converts in that market. Their layout is a survey result. Screenshot the whole page, top to bottom.

Then the prompt is roughly: here is the structure I want, here is the business, here are the brand colors, adapt it.

Now the part every tutorial skips.

There is a line here, and you need to know exactly where it is. Layout conventions, section ordering, and the decision to put a form above the fold are not protectable. Their photography is. Their copy is. Their testimonials are. Their logo obviously is. If you feed a screenshot to Claude and it reproduces a headline verbatim, that's a problem you own, not a problem the model owns — and it's the kind of thing that surfaces eighteen months later when the competitor's marketing agency runs a plagiarism check.

I read the generated copy specifically hunting for phrases that feel imported. Anything that sounds like it was written for a different company usually was.

For media, Pexels is the default: free for commercial use, no attribution required. Two restrictions in that license that people miss — don't sell unaltered copies as a product, and don't imply endorsement by the people or brands shown in the imagery. That second one is live for local trades. A stock photo of a smiling man in a hard hat placed next to the words "Meet our lead installer, Dave" is exactly the implied endorsement the license prohibits. Use crew photos the client provides, or keep the stock imagery unattributed to a named person.

Once the reference is in and the media is sourced, the model gives you a first pass. It will be about 80% right and confidently wrong in the same five places every time.

The five corrections I make on every single build

I stopped treating these as bugs and started treating them as a checklist, because they recur across models and across prompts. Years of client work drilled one habit into me that pays off here: nothing ships until I've looked at it at desktop, tablet, and mobile widths — that's a standing rule in my workflow, not a nice-to-have, because three of these five failures only show up off-desktop.

1. The header collides with the menu. Fixed-position headers and the nav bar end up stacked or overlapping on the first render more often than not, and it always looks worse on tablet than on the widths you were previewing. Specify it explicitly: sticky header, defined height, nav vertically centered inside it, body content offset by that same height. Test at 768px, not just 1440px.

2. The hero video has no overlay. A background video with white text over it is unreadable roughly half the time, because the video's average luminance changes every frame. A dark gradient overlay at 40–60% opacity fixes readability and, as a side effect, makes the whole thing look more expensive. This is the cheapest premium-perception trick in the stack.

3. The copy is written for a reader who doesn't exist. Generated headlines drift toward abstraction — "Elevating Standards in Residential Roofing." Nobody searching for a roof at 11 PM after a hailstorm wants that. Rewrite to outcome and time: what you do, how fast, and what it costs to find out. Strip the em-dashes while you're in there. They're the most reliable visual tell of unedited model output, and local business owners have started to notice.

4. The icons are generic and the images are wrong. Service cards ship with abstract line icons and stock photos that don't match the service. For a roofer, actual photographs of actual roofs outperform any icon set. Swap them. It takes four minutes and it is the difference between "a website" and "their website."

5. Nothing is centered that should be. Text alignment inside cards, badge positioning, the footer columns. Minor, visible, and the first thing a client points at.

Work through those five and the output crosses a threshold. I've seen a corrected build sit next to the reference site — a company doing real volume with a real marketing budget — and read as the more credible of the two. That's not because Claude is a better designer than their agency. It's because their site is four years old and mine is compounding four years of convention into one afternoon.

Which brings me to the thing that will quietly kill that site.

The hero video is a billing decision, not a design decision

Here's the calculation nobody in this space is running.

Netlify's April 14, 2026 pricing update changed the metering on credit-based plans. Bandwidth went from 10 credits per GB to 20 credits per GB. Compute went from 5 to 10 credits per GB-hour. Web requests dropped from 3 to 2 credits per 10,000. New accounts get 300 credits per month on the free plan, and a production deploy costs 15 credits.

Do the division. Three hundred credits is either about twenty deploys with zero bandwidth left, or roughly 15 GB of bandwidth with zero deploys, or some split between them. And when the credits run out on a free plan, the site is paused — it stops serving traffic until the next billing cycle. Netlify warns at 50%, 75%, and 100%.

Now put a 7 MB hero video on that site.

15 GB divided by 7 MB is about 2,140 page loads. Subtract the deploys you'll burn during the revision rounds — say five, at 15 credits each, which is 75 credits, roughly 3.75 GB of bandwidth gone — and you're closer to 1,600 loads. Then subtract the rest of the page weight, because the video isn't the only asset.

A local roofing company in a metro market during storm season can do that in three weeks.

And then the site goes dark. Not slow. Dark. During the exact period the client is spending money on ads pointing at it.

There is no version of that conversation where you keep the retainer.

So: compress ruthlessly, and know why. Getting the hero video under 7 MB is the number the workflow usually cites, and it's a reasonable ceiling for Largest Contentful Paint. But LCP is not the binding constraint here — billing is. On any client site I expect real traffic on, I do three things:

• Compress the hero to 2–3 MB, not 7. H.264 at a lower bitrate, 1920×1080 max, no audio track, 6–10 second loop.
• Ship a static poster image as the poster attribute so the first paint never waits on video, and so mobile — where autoplay is unreliable anyway — mostly never downloads the video at all.
• Move the client onto a paid plan, or onto Cloudflare Pages, before launch if the traffic forecast is anywhere near five figures a month.

If the client won't pay for hosting, the honest answer is a static image hero. It costs you nothing and it costs them nothing, and a fast image beats a paused video by an infinite margin.

Bake this into the quote. "Hosting and bandwidth: $25/month" is a line item that pays for itself the first time a storm doubles their traffic.

Alright — that was the hard part. The rest of the pipeline is more forgiving.

SEO for local business websites with Claude: what actually ranks

This is the part clients don't know to ask for and agencies bill as a premium extra. Claude generates all of it in the same pass as the site, which is genuinely a structural advantage over hand-building.

The standard set: unique <title> and meta description per page, Open Graph tags so the link preview isn't blank when the owner posts it to Facebook, robots.txt, and sitemap.xml. Ten seconds of prompt, and it's the difference between an indexed site and a URL.

The piece that actually moves local rankings is the structured data. Google requires both name and address on LocalBusiness structured data for a rich result, and it explicitly recommends using the most specific subtype available rather than the generic one. Schema.org's hierarchy runs Thing → Organization → LocalBusiness → dozens of subtypes: Roofer, HomeAndConstructionBusiness, Dentist, Plumber, Electrician, ProfessionalService, Store.

So for a roofing company, the type isn't LocalBusiness. It's Roofer. Tell Claude that explicitly, because left to its own defaults it will reach for the generic parent type more often than not.

The full block I ask for:

{
  "@context": "https://schema.org",
  "@type": "Roofer",
  "name": "Exact name as it appears on Google Business Profile",
  "image": "https://example.com/og-image.jpg",
  "telephone": "+1-512-555-0142",
  "email": "office@example.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1200 Example Rd",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 30.2672, "longitude": -97.7431 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "07:00", "closes": "18:00"
  }],
  "areaServed": ["Austin","Round Rock","Cedar Park","Georgetown"],
  "sameAs": [
    "https://www.google.com/maps/place/...",
    "https://www.facebook.com/..."
  ]
}

The name, address, and telephone must match the client's Google Business Profile character for character. "St" versus "Street" is a mismatch. This is the single most common local SEO error I see on otherwise competent sites, and it's the one that costs map pack visibility.

One more reason this matters in 2026 specifically: AI answer engines read structured data to decide which businesses to name in a recommendation. A local business with clean, validated schema is a legible entity to those systems. One without it is a paragraph of text they have to guess about. If you want the fuller treatment of that, I went deep on it in my breakdown of rebuilding a site around Claude and SEO.

And a warning from my own scar tissue: schema only helps if it's true. Structured data that claims things the business doesn't have — reviews, ratings, credentials — is how sites get deindexed, not ranked. I learned that on my own property, the hard way. Validate the block before handoff, and validate it against reality, not just against the parser.

Then wire the form, which is where the actual money is.

Wiring the contact form so the leads actually arrive

Netlify Forms is the reason this stack works for local businesses. No backend, no serverless function, no third-party form service subscription. You add one attribute and Netlify's build step handles the rest.

Then there's the limit everyone quotes, and it's now wrong in a way that matters.

Netlify Forms submissions are free and unlimited on credit-based plans as of April 14, 2026. The changelog wording is direct: "Now form submissions are free across all Credit plans. Previously, each form submission cost 1 credit."

But — and this is the distinction that will bite someone — the legacy 100-submissions-per-month cap still applies to legacy plans. Accounts created before September 4, 2025 may still be on the old model with separate bandwidth and build-minute allowances, and switching to credit-based pricing is permanent. So the correct answer to "how many form submissions do I get" is: check which plan the account is on first. If you're deploying into a client's existing Netlify account from 2024, do not assume unlimited.

Here's the form markup I ship, with the spam handling built in rather than bolted on:

<form
  name="contact"
  method="POST"
  data-netlify="true"
  netlify-honeypot="bot-field"
  action="/thank-you"
>
  <input type="hidden" name="form-name" value="contact" />

  <!-- Honeypot: hidden from humans, irresistible to bots -->
  <p class="hidden" aria-hidden="true">
    <label>Don't fill this out if you're human:
      <input name="bot-field" type="text" tabindex="-1" autocomplete="off" />
    </label>
  </p>

  <label for="name">Name</label>
  <input id="name" name="name" type="text" required />

  <label for="phone">Phone</label>
  <input id="phone" name="phone" type="tel" required />

  <label for="service">What do you need?</label>
  <select id="service" name="service">
    <option>Roof repair</option>
    <option>Full replacement</option>
    <option>Storm damage inspection</option>
  </select>

  <button type="submit">Get My Free Inspection</button>
</form>

Four things in there that aren't optional:

The form-name hidden input is required for any JavaScript-rendered form — if Netlify's post-processing can't find the form in the static HTML, submissions vanish silently. This is the number one cause of "the form doesn't work" on React and Next.js builds.

The honeypot uses Netlify's own attribute syntax. Per Netlify's spam filter docs, submissions that fill the honeypot are rejected outright and never appear even in the spam list. All submissions are additionally filtered through Akismet by default. If a client is getting hammered, you can layer reCAPTCHA 2 on top with data-netlify-recaptcha="true", though I'd rather not put a friction gate in front of a storm-damage lead.

The action="/thank-you" gives you a conversion page you can fire an analytics event or ad pixel from. Without it you get Netlify's default confirmation and no measurable conversion.

type="tel" pulls up the numeric keypad on mobile, where most of these submissions originate.

Then configure the notification in the Netlify dashboard: Forms → Form notifications → Add notification → Email notification, pointed at the business's real inbox. Do this before handoff and test it with a real submission from your phone on cellular data, not from your laptop on the office WiFi.

And check the spam folder on the client's side. A notification arriving from Netlify's sending domain into a Microsoft 365 tenant with aggressive filtering is a lead the business never sees and never knew existed. I've watched a perfectly good site be declared "not working" for three weeks over exactly this. If the business runs their own domain email, set up a forwarding rule and whitelist the sender before you invoice.

The form fires. The email lands. Now the interesting part: what happens in the ninety minutes after.

The AI reply loop — and why it drafts instead of sends

Speed of first response is the whole game in local trades. A homeowner with a leaking roof messages four companies. The one that answers first usually wins, and it's not close.

So the loop: Claude reads the incoming form-notification emails, extracts the lead details, and drafts a personalized reply in the business's voice — acknowledging the specific service they asked about, offering a free inspection, and proposing two concrete appointment windows. On a schedule, running continuously, or handed to a virtual assistant who does nothing but review and hit send.

Now the part I feel strongly about.

Draft. Do not auto-send. And the reason isn't output quality — Claude writes a better follow-up than most contractors do at 9 PM. The reason is legal.

A message that names a price, a date, and a scope is, in a lot of jurisdictions, an offer. If the model hallucinates "$450 flat rate for storm damage inspection and same-week replacement," and the homeowner accepts in writing, your client has a contract dispute and you built the machine that generated it. For a trade with licensing, insurance, and permitting obligations, that risk is not theoretical.

There's also a policy dimension. Anthropic's usage policy prohibits presenting AI output as human-written where disclosure is expected, and requires human-in-the-loop oversight for higher-risk domains. A contractor's customer reasonably expects a human on the other end of a quote. A draft-and-review loop keeps a human in that position, which is both the safer design and the honest one.

Practical constraints I put on the drafting prompt:

• Never state a price. Ever. Route pricing to "our estimator will confirm on site."
• Never confirm an appointment. Propose windows, and let the human commit.
• Never make a warranty, timeline, or insurance claim.
• Match the business's actual voice, which means feeding it three or four real emails the owner has already sent.
• Flag anything mentioning water intrusion, structural damage, or injury for immediate human attention rather than drafting at all.

With those rails on, a VA can clear thirty drafts in twenty minutes. That's the service you're actually selling on retainer — not the website.

Packaging the workflow into a Skill so it survives contact with client number four

Doing this once is a project. Doing it eleven times from memory is how quality decays. The fix is a Skill.

A SKILL.md is a folder with one required file: a Markdown document with YAML frontmatter containing name and description, and a body of instructions. The reason it beats a saved prompt in a text file is progressive disclosure, and the token accounting is worth internalizing:

• Name and description load at startup — roughly 100 tokens per skill
• The full SKILL.md body loads only when the skill activates — keep it under about 5,000 tokens
• Files in references/ load only when the model reaches for them

So a fat prompt burns context on every conversation. A Skill burns 100 tokens until the moment you need it. With eight or ten skills installed, that difference compounds into real working room — which matters when you're also holding a whole site in context. I broke down the mechanics more fully in my Claude Code agent skills guide.

What I put in the local-business builder Skill:

SKILL.md body — the intake questions, the five standing corrections, the hosting decision tree, the schema subtype selection rule, the form markup requirements, and the "never state a price" constraint for the reply loop.

references/schema-types.md — the mapping from trade to Schema.org subtype. Roofer, Plumber, Electrician, HVACBusiness, Dentist, AutoRepair, LegalService. Loaded only when generating the JSON-LD.

references/form-patterns.md — the full Netlify markup with honeypot, the form-name hidden input rule for JS-rendered forms, and the notification setup checklist.

references/copy-rules.md — the voice constraints, the em-dash strip, the outcome-first headline patterns.

assets/ — default hero videos and poster images already compressed to spec, so the fallback path is instant.

The intake is where the compounding happens. The Skill asks a short fixed set of questions — business name, trade, city, service area, phone, hours, brand colors, whether they have a logo, whether they have media — and then builds with smart defaults for everything unanswered. Falls back to a static image hero if no video is supplied. Outputs a single folder, zipped, with the site, assets, robots.txt, sitemap.xml, and the schema block already embedded.

Deployment is drag-and-drop: unzip, drag the folder onto Netlify, get a live *.netlify.app URL immediately. That URL is your sales asset — you send it to the business owner before you've asked for a dollar. Custom domain takes two minutes of DNS records once they say yes.

Notably, the SKILL.md format is now a cross-vendor standard. The core structure works in Claude Code, OpenAI's Codex CLI, Cursor, Gemini CLI, and GitHub Copilot, with Claude-specific fields ignored gracefully by the others. You're not building on a proprietary format you'll have to rewrite.

Now the honest section, because everything above works and everything above has a ceiling.

Real talk: what you're actually selling, and where this falls apart

You are not selling a website. If you sell a website, you're selling a commodity that your client can now watch a video and produce themselves, and your price collapses to whatever the next person charges. The website is the wedge. The lead-response system, the hosting, the schema maintenance, the seasonal content updates, and the fact that someone answers the phone when the form breaks — that's the product. Running an agency taught me this before AI made it obvious: the build was never where the durable revenue was. I made the fuller argument for why the project fee died and the retainer won in my piece on the AI agency retainer model.

Read Anthropic's terms rather than assuming. The commercial terms are clear on ownership: "Anthropic agrees that Customer (a) retains all rights to its Inputs, and (b) owns its Outputs." So you own what you generate and you can deliver it to a client. Separately, you may not resell the Services themselves without approval — meaning you can sell a website Claude helped you build, but you cannot resell Claude access, route client requests through your consumer plan credentials, or offer "Claude login" as part of your package. Those are two different questions and people conflate them constantly.

On disclosure: I don't hide the tooling and I don't lead with it. If a client asks how I build this fast, they get a straight answer. What I never do is let a homeowner believe they're getting a hand-typed reply from the owner when it's an unreviewed draft. Anthropic's policy language on not presenting AI output as human-written where disclosure is expected is a reasonable floor, and the review step in the reply loop is how you stay above it.

The client will not be able to edit the site. This is the failure mode that shows up in month two. You hand over a beautiful static site, and then they want to change their hours for a holiday, and they can't, and they email you, and you do it for free because it takes ninety seconds, and then it happens eleven more times. Either price that into the retainer explicitly or add a real editing layer — I wrote up the whole CMS layer problem for Claude-built sites after hitting exactly this.

Some businesses genuinely should not buy this. A restaurant that needs live menu updates and online ordering, a clinic with HIPAA obligations around any intake form, anyone taking payment on-site, anyone with real inventory. Static site plus Netlify Forms is the wrong shape for those. Say so, and refer them out. The referral costs you one sale and buys you the reputation that produces the next six.

The site will look AI-built if you skip the corrections. Every generated site shares a family resemblance, and local business owners have now seen enough of them to recognize it. The five corrections aren't polish, they're the differentiator — I catalogued more of these in the professional website hacks post.

And the honest limitation on my own numbers: the Netlify credit math above is arithmetic on published rates, not a measurement from a site I've watched get paused. The rates are verifiable and the division is simple, but your client's actual bandwidth depends on their traffic mix, mobile autoplay behavior, and how much CDN caching absorbs. Treat the 2,100-page-loads figure as an order-of-magnitude warning, not a guarantee. The point stands either way: a video hero on a free plan has a hard ceiling, and you need to know where it is before your client finds out.

What to charge

The $500–$2,000 range for the build holds up against the market. The 2026 benchmarks put freelance small business sites at $500–$5,000 and agency work at $5,000–$30,000, so a $1,200 build that visibly outperforms their existing $6,000 site is an easy yes with room to negotiate.

Some people run a demo-first version of this: build the site unasked, send the live preview link, charge a few hundred to move it to the client's domain. Higher volume, lower price, much higher rejection rate. It works because the marginal cost of an unsold build is now close to zero — I've written about the mechanics of that approach in the AI website cloning post. It's a numbers game and it needs the Skill to be viable.

The retainer is where the business is. $200–$1,000 a month, and it has to be attached to something the client can feel, or they cancel in month three. Attach it to lead response — reviewed replies inside ninety minutes — and the cancellation conversation becomes "do you want to stop answering leads." Attach it to "hosting and updates" and you're a $25 line item they'll forget they're paying.

Once the base retainer exists, the expansions are straightforward and each one is a price increase: chasing unpaid invoices, ranking inbound leads by urgency, reactivating customers who haven't booked in eighteen months, triaging complaints before they become public reviews. Same model, same drafting discipline, different inbox.

The two numbers, revisited

Go back to where this started. A $2,000–$8,000 market price, and an eight-minute build.

The gap isn't a market inefficiency waiting to be arbitraged by whoever moves fastest. It's a re-pricing of which part was ever the expensive part. Layout was never the hard problem. Accuracy was. Being findable was. Answering the phone was.

Claude collapsed the cheap part to nearly zero and left the expensive parts exactly where they were.

So here's what I'd do this week if you're starting: pick one trade in one city you actually know something about. Build the site — corrections included, video under 3 MB, schema with the right subtype, form tested from your phone on cellular. Then send the live link to that business owner with no pitch attached, just: I built this, it's yours if you want it, here's what it costs to put it on your domain.

You'll learn more from that one email than from another six hours of tutorials. And you'll find out fast whether you built a website or a business.

If You'd Rather Buy the Pipeline Than Build It

Everything in this post — the reference-driven builds, the correction checklist, the schema layer, the form wiring, the draft-only reply loop — is work I deliver for clients through my agency practice, either as a one-time build or as the full retainer system with the Skill configured for your niche. If you're a business owner who wants the site, or a freelancer who wants the machine that makes them, look through my services and pick the engagement that fits.