---
name: deliver-personal-brand-site-from-request
description: "Build a site from the owner’s real request."
category: Personal Branding
stage: —
definitive_article: https://blitzmetrics.com/from-one-email-to-a-live-personal-brand-site/
status: needs-work
---

# Deliver a personal-brand site from a request

Build a site from the owner’s real request. This guide checks the facts, builds the page and gives the owner one clear next step. Start with the full request and the domain they control.

**The path:** Full request → Checked preview → Exact domain plan → Verified live site

**Start when:** A person requests a site and identifies the domain they actually control.

## Inputs

- The full original request, accepted business scope, intended reader and goal.
- Actual domain owner, existing site/source, hosting plan and DNS/mail records.
- Verified bio, photos, proof, source rights, supported build tools and deployment/send authority.

## Steps

1. Read the entire original conversation. Resolve the correct person, actual domain and current request, including changes of mind. Record what the site should help its reader do before collecting more material; do not choose a domain from an old email alone.
2. Collect the existing approved bio, photos, interviews and proof. Verify load-bearing facts against their sources and keep private material private. Complete safe preparation before requesting genuinely missing assets, with the missing item tied to a specific blocked section.
3. Use [Build the personal brand site](https://local-service-spotlight.github.io/task-library/?task=build-personal-brand-website#task-build-personal-brand-website) for the content build. Produce a concrete preview with real media, the person’s own voice, source-backed proof and clear contact path. Use the current [Article Guidelines](https://localservicespotlight.com/article-guidelines/) opening and visual requirements; retain layout and builder data on an existing site.
4. Identify both the registrar and authoritative DNS provider from actual records and the authorized account. Nameservers show where DNS is served, which need not be the registrar. Read the existing web, mail and verification records before preparing any change.
5. Prepare only the exact web records required by the selected host, with current before values and recovery steps. Prefer a minimal web-record change when appropriate. Check whether email uses the root domain or affected records; changing A records is not universally risk-free for mail, and changing nameservers needs a complete zone plan.
6. Link instructions for the actual provider and the observed controls. If a maintained guide is missing, prepare a reusable guide from the provider’s current official documentation. Do not copy a fleet IP, nameserver set or automatic certificate promise from another site.
7. Prepare the reply with the checked preview and one concrete owner action. Keep it a draft unless sending is authorized. Provision, map the domain and publish only through the accepted deployment rail; keep DNS pending, built and live as separate states.
8. After launch, check the normal public URL, HTTPS, intended content, media, contact path and relevant retained mail configuration. Save the exact source and evidence, then return the verified result to the original conversation under its send authority.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The preview’s facts, voice, media and first-screen value are reviewed against sources.
- [ ] The domain plan is exact to the current host and preserves recorded dependent services.
- [ ] Only the checked public domain is called live; draft replies and owner dependencies remain explicit.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional owner first mentions an old domain, then confirms a different domain she controls. The team builds a preview from her real photos and checks the active mail records at the current DNS host. It drafts one exact web-record action. The job remains blocked on that owner action until the final public site is verified.

## Handoff and Content Factory context

The domain owner receives the exact pending action; [Review search and real inquiries](https://local-service-spotlight.github.io/task-library/?task=measure-search-impressions-traffic-inbound-opportunities#task-measure-search-impressions-traffic-inbound-opportunities) receives the authorized launched site and actual source connections. The original request remains the parent record.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/from-one-email-to-a-live-personal-brand-site/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=deliver-personal-brand-site-from-request#task-deliver-personal-brand-site-from-request)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.