AI Website Factory

business.json is the source of truth — every artifact below is derived from it

1. Identify A business enters — shortlisted from the market scan, or an inbound applicant.
2. Research The business’s site, state license records, and Google Places collapse into one evidence file. <20 s
3. Audit Grader signals plus a full crawl of the existing site, reported findings-first. ~1 min
4. Build decision human gate I decide: build, review, or skip. Weak fits never reach design.
5. Design A design DNA is derived and written to DESIGN.md; a similarity gate keeps every site visually distinct. ~80 s
6. Build + QA The Astro site-kit assembles the site; accessibility, pixel-diff, composition, and a truth ledger gate it — every claim traces to evidence. ~11 min
7. Preview Fail-closed noindex deploy — a failing build refuses to ship, and canonicals already point at the real domain.
8. Approval human gate I review the approval package. Nothing external — domains, forms, launch — happens before this.
9. Launch Flipping to production is the domain-launch act: single-launch scope, no automatic relaunches.

stack Google Stitch API · Google Places API · DataForSEO API · Astro · Tailwind CSS · JavaScript / Node.js · Netlify · Git / GitHub · AI coding agents

Overview

The Website Factory is a production system for building local-business websites. Feed it a business, and it researches the business, generates the content and design, assembles the site, runs QA, and deploys it to a live preview URL — a measured cold run takes roughly 13 minutes from identified business to QA-passed site. Production launch is a separate, human-approved step.

It is not a chat window with “make me a website” typed into it. It’s a factory in the literal sense: a defined pipeline where each stage has inputs, constraints, and a check before anything moves forward.

The problem

A properly built local-business website isn’t one task — it’s a few dozen of them. Research the business and its competitors. Write service copy that matches how customers actually search. Design something that doesn’t look generated. Build the service pages and service-area pages. Handle the metadata, structured data, sitemap, and social assets. Validate every link. Control what gets indexed. Deploy.

Each step is individually manageable. Together, they’re the reason a good local website costs thousands of dollars and weeks of calendar time — and the reason so many small businesses end up with something mediocre.

What I did

I designed the pipeline and own every part of it that isn’t generation:

• The system itself — stage order, inputs and outputs, and where a human has to approve before anything proceeds
• Persistent instructions — the standing rules the AI works under, not per-session prompting: house style, structure requirements, SEO constraints, quality bars
• Integrations — Google Stitch for design direction, Google Places and DataForSEO for business and search data, social and web research for the rest
• Constraints and safeguards — fail-closed behavior: when a step can’t verify its own output, the pipeline stops instead of shipping something broken
• QA and shipping — I review the output at the approval gates, run the automated checks, and deploy

To be precise about authorship: the AI writes a lot of the code and copy. I design the system it works inside, direct the development, review everything it produces, integrate the APIs, and ship the result. The leverage comes from the constraints, not the generation.

The system

The pipeline runs in order, with human approval gates between the stages that matter:

1. Research — business data from the Google Places API, search and competitor data from DataForSEO, plus social and web research, assembled into a research brief the later stages draw from
2. Design and content — AI-assisted, using Google Stitch for design direction and the research brief for grounding, so the site reflects the actual business rather than a template
3. Assembly — an Astro site built via Node.js, versioned in Git, with a local-SEO architecture: service pages, service-area pages, metadata, XML sitemap, structured data / schema markup, and generated OG social assets
4. QA — automated link validation, metadata and schema checks, and indexing controls (what should be indexed, what shouldn’t), with fail-closed safeguards throughout — an unverified step halts the run
5. Approval and deploy — I review, approve, and ship through Git to Netlify

The SEO layer is designed in, not bolted on: the page architecture targets how people actually search for local services, and the same structure supports AEO (answer-engine optimization) and GEO (generative-engine optimization) — being citable and understandable when an AI, not a human, is the one reading the page.

The clock is measured, not estimated. One cold run, October 2026, start to finish: research in under 20 seconds (10 facts from the business’s own site, state license records, and Google Places), the audit a minute later (25 findings, 20 pages crawled), design direction 80 seconds after that, then eleven minutes of build, automated QA, and deploy to a live preview URL. About 13 minutes end to end — and a warm re-run of the same business finished in 34 seconds.

Outcome

• ≈13 minutes, machine-measured, from identified business to a QA-passed site deployed to a live preview URL (cold run, October 2026) — 34 seconds on a warm re-run

Live site:

• Primo Plumbing — a Chula Vista, CA plumber, and the factory’s golden site: researched, designed, built, and launched through the full pipeline, passing the automated readiness gates — accessibility checks, pixel-diff visual QA against locked baselines, live site checks — before a controlled production launch.

The number that matters most is the first one. What took a small agency a week now takes minutes of pipeline time, with more consistency than the manual version.

What I learned

• The constraints are the product. Anyone can prompt an LLM for a website. The version that works has persistent instructions, approval gates, automated QA, and fail-closed defaults. Generation is cheap; knowing what “good” is — and encoding it — is the work.
• Fail-closed is worth the friction. Early on, the pipeline would push through uncertainty and I’d find the damage at review. Making it stop instead moved the catches upstream and made the review gates calmer.
• The last 10% is still mine. The system produces a complete site; judgment about whether it’s right — for the business, the market, the customer — hasn’t been automated, and I don’t think it soon will be.