Launch a new company website

When to use

The company needs a website it does not yet have, or is replacing one outright. Not for registering the domain itself — use tech.register-domain first and come back. Not for moving an existing site host to Brain Club with the content kept — use tech.move-domain-to-bc. Not for a one-page campaign under an existing site — that is a page in the current site, not a launch.

Before you start

• The domain is decided and held by the company (if not: run tech.register-domain first).
• The page list is written down, even if it is three pages: Home, About, Contact.
• Legal texts exist or their source is named: privacy policy, cookie notice, company details
• Whoever owns the content has time this week — content is the long pole, not the build.

What a run requires2

The trail9 steps

1. S1

   Write the one-page briefagent

   Purpose, audience, page list, language(s), what a visitor should do (call, buy, book, write).

   Done when the brief fits on one screen and names the single main action.

2. S2

   Draft structure and contentagent

   For each page: headline, text, images, contact block, footer with company details. Use the brand kit if one exists; otherwise note that growth.brand-kit should run later.

   Done when every page in the list has draft text and no "lorem" placeholders.

3. S3

   Approve content and designownerneeds approval · owner

   Approval · S3 · owner — the run stops until a named person records the decision

   Present the drafts page by page with the brief on top.

   Done when the owner has approved each page or named the change; changes go back to S2 once.

4. S4

   Build in the builder moduleagent

   Assemble pages on a staging address under the company's account (never a personal one). Wire the main action: form, button or booking link pointing at a company mailbox (tech.create-mailbox if needed).

   Done when every page renders on the staging address and the form test-submits to the company mailbox.

5. S5

   Pre-launch checksagent

   Mobile view, page titles and descriptions, favicon, 404 page, HTTPS on staging, analytics test hit, cookie consent banner where required, legal texts linked in the footer.

   Done when the checklist passes with none of the items marked "later".

6. S6

   Approve go-liveownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Show the staging site and the cutover plan (when, what changes, how to roll back).

   Done when the owner has named the go-live moment.

7. S7

   Cut the domain overagent

   If the domain is already on Brain Club nameservers: change the A/AAAA/CNAME records with bc dns to the new site. If not: onboard the zone first — bc domains onboard <domain> --tenant <slug> (dry run, read the plan, --apply), then delegate, so the new nameservers already serve the new records before the parent TTL turns over.

   Done when the Brain Club nameservers answer with the new site's records before the parent delegation is changed.

8. S8

   Verify from outsideagent

   Resolve from at least two public resolvers; open the site over HTTPS on the real domain; submit one test message through the form and confirm it arrives in the company mailbox; check the certificate is valid.

   Done when the site opens from an outside network, HTTPS is valid, and the test message arrived.

   ⛔ A green check on the office network proves nothing — the office DNS may still hold the old answer.

9. S9

   Measure and recordagent

   Confirm analytics records the visit and the test event; verify the property in Search Console (tech.connect-search-console for the full procedure), submit the sitemap; link the site to the goal/task it serves with bc tasks add or bc goals add; send the owner a three-line summary: what is live, on which domain, what is now measured.

   Done when analytics shows the test visit and event, the Search Console property is verified with the sitemap submitted, the site is linked to its goal/task, and the owner has the three-line summary.

Checks — how we know it worked

• The domain opens over HTTPS from an outside network (phone on mobile data, not office Wi-Fi).
• The form test-submission arrives in the company mailbox — read it, do not assume it.
• Analytics shows the test visit and the test event with today's date.
• Search Console shows the property verified and the sitemap submitted.
• Footer shows company name, registration number, address and a working contact address.

If it goes wrong

What each step leaves behind

1. S1the brief fits on one screen and names the single main action.
2. S2every page in the list has draft text and no "lorem" placeholders.
3. S3the owner has approved each page or named the change; changes go back to S2 once.
4. S4every page renders on the staging address and the form test-submits to the company mailbox.
5. S5the checklist passes with none of the items marked "later".
6. S6the owner has named the go-live moment.
7. S7the Brain Club nameservers answer with the new site's records before the parent delegation is changed.
8. S8the site opens from an outside network, HTTPS is valid, and the test message arrived.
9. S9analytics shows the test visit and event, the Search Console property is verified with the sitemap submitted, the site is linked to its goal/task, and the owner has the three-line summary.

Evidence to keep

The approved brief (S1) · the owner's approval in S3 and S6 (who, when) · the bc domains onboard run output and DNS records set · S8 verification answers with timestamp · the test form submission · the Search Console property id · the link to the goal/task.

How this playbook improves

After every 5 runs ask: how many days from ask to live, and did the wait sit in S2 (content) or S7 (DNS)? Did any launched site have a broken form found later than S8? Did analytics record from day 1? A new version changes the step that caused the wait or the miss, and says so in its change note.