How We Built the Spotlight Build Engine on AWS

Vertical flow diagram of the Spotlight build engine: buy, welcome and intake, AI builds the site, provision on AWS, point the domain, detect and attach, live.
How a Spotlight site builds itself: buy, welcome and intake, AI builds the site, provision on AWS, point the domain, detect and attach, live.
From one purchase to a live personal brand site on AWS — the whole path runs unattended; a human keeps only the money and the go-live approval.

A site that builds itself

Spotlight is the personal brand website product from Local Service Spotlight. Someone buys, fills out one short form, and minutes later they have a live, researched personal brand site on their own domain, with nobody touching anything in between. This is the account of how a Claude agent built the engine that makes that happen: a zero-touch pipeline on AWS that researches a customer, writes and renders their site, provisions it with its own certificate and CDN, and emails them the single step they have to take.

How this fits the playbook

The method behind it is how we build a personal brand website, grounded in the entity thinking from Google entities and trust and personal branding on Google, and it follows Dennis’s meta-article process. The first time an agent built one of these sites by hand is the Cam Hazzard build, and the WordPress variant is the Trenton Sandler build. This build is the next step: instead of an agent building one site, an agent built the machine that builds the sites. Its network-scale sibling, how that one engine serves every trade, is how we wired the Spotlight Network to one engine.

What the engine does

The whole thing runs as about ten AWS Lambda functions coordinated by a state machine, with no server to keep running and no CMS. When a customer buys and submits the intake form, the engine researches them from what they gave us plus public signals, writes their site as structured content, and renders it to static HTML. It provisions each customer their own storage bucket, their own CDN distribution, and their own SSL certificate, then emails them the two steps to point their domain. A poller watches for the domain to resolve and announces the site the moment it is live. Every customer site is static HTML on its own edge-cached distribution, which is why it loads fast, costs about fifty cents a month to host, and has nothing to log into and nothing to break.

The model writes; the code owns the markup

The single most important design decision is that the language model writes the words, and deterministic code owns every tag, class, and asset. The agent’s research and writing produce a structured content object, and a renderer, not the model, turns that object into HTML. That split is what lets more than thirty brand and quality rules survive every generation: no emojis on cards, extensionless URLs, a specific Connect-page layout, and the structured data that feeds a Google Knowledge Panel are all enforced in code. They hold on the first customer and the ten-thousandth, and they hold again every time we improve the template.

One template, every site

Because the markup lives in code, improving the template is a fleet operation, not a hand edit. When we sharpen a component or fix a detail, a single re-render ships it to every existing customer site at once. A site built months ago gets the same upgrade as one built today, with nobody logging into anything. That is the difference between hosting a fleet of sites and maintaining one.

Engineering it to run unattended

A zero-touch pipeline only earns the name if it stays correct without a human watching, so most of the care went into the edges and the failure paths. Four decisions make it dependable.

Every step is idempotent, and every customer is independent. A retried step never double-builds or double-charges, and one customer’s issue never blocks anyone else’s build.

A human review gate holds the announcement. The public “your site is live” email waits until a person has approved the site, so nothing reaches a customer’s audience unseen.

Moving a domain never breaks the customer’s email. The engine preserves the customer’s existing mail records through the nameserver switch, so pointing their domain at us leaves their email untouched.

Sites self-host their fonts. Each site serves its own fonts instead of calling a font CDN, so pages load faster and never hand a visitor’s IP to a third party.

Effort and cost comparison

Task Agent time Human time Agent cost Human cost (blended $100/hr)
Architecture and serverless template 45 min 16 hr $1.20 $1,600
The Lambda functions (build, intake, provisioning, poller, review, more) 3 hr 60 hr $4.00 $6,000
Generator and renderer (model writes, code owns the markup) 1.5 hr 24 hr $2.00 $2,400
Test suite (147 tests, including a full end-to-end run) 2 hr 30 hr $2.20 $3,000
Transactional emails and the review gate 40 min 10 hr $0.90 $1,000
Provisioning and email-record preservation 40 min 10 hr $0.90 $1,000
Docs and handoff 45 min 6 hr $0.65 $600
Total ~9 hr ~156 hr ~$11.85 ~$15,600

Costs use Claude Sonnet public rates ($3/M input, $15/M output). The human hours are a conservative estimate of building the same engine by hand, covering architecture, development, QA, and documentation, at a blended $100/hour. Even on conservative numbers, running the agent cost a tiny fraction of staffing the build, and the point is not the one-time saving: this is the repeatable version, so the engine now builds every new customer’s site for about fifty cents in hosting rather than a fresh development project each time.

What the agent handled versus what stayed with a human

Agent handled autonomously: the architecture, the Lambda functions, the generator and renderer, the full test suite, the transactional emails, the provisioning sequence, and the documentation.

Kept with a human, by design: deploying to AWS, moving any money, and approving each site at the review gate before it goes public. All money movement and every public go-live stayed with a human.

Why this creates value for the customer

The customer gets a fast, secure, professional personal brand site on their own domain, kept current by us, with nothing to manage. Because it is static and edge-cached, there are no plugins to collide, no admin password to phish, and no server to go down. They send us their wins, and the site stays accurate.

Why this creates value for BlitzMetrics

This is what turns a service into a product. One small team can build and host a site for about fifty cents a month, ship a template improvement to the whole fleet at once, and add an entire new trade with a single config entry. It is the fulfillment engine behind the Spotlight Network: many front doors, one pipeline.

The Spotlight Network: one engine serving twelve trade front doors
The engine is the fulfillment side of the whole network: every front door, from HVAC to athletes, sells into this one pipeline.

The build pattern

This is entity authority, productized: research a person, structure them into an entity home, and ship it as static, fast, owned infrastructure. Read the personal branding method, see the single-site version in the Cam Hazzard build, the network-scale version in how we wired the network to one engine, and the live product at Local Service Spotlight. If you run a local service business and want your own, that is where to start.

Dylan Haugen
Dylan Haugen
Dylan Haugen is a professional dunker, content creator, and editor at the Content Factory, where he transforms podcasts and interviews into strategic brand assets. He collaborates with Dennis Yu to support young entrepreneurs and business owners in building their personal brands through education, transparency, and effective content marketing. As the host of the Dunk Talk podcast and a dedicated advocate for establishing dunking as a recognized sport, Dylan combines athletic expertise, storytelling, and digital strategy to help elevate the next generation of creators.