Events AI Circle AI Workflows
3rd Space Bucharest · AI Workflows Card 002 Shipped Aug 2026

Brief, build, and the part nobody warns you aboutCreate a Website

Write the brief with Claude. Hand the brief to Claude Design. Then move the domain without killing your email.

CreatorEric Melchor
RunsOnce per site
Stages3
Total time~7 hours
One site, start to live 7 hours
1 hr — writing the brief ~4 hrs — the build 2 hrs — domain cutover, and fixing what it broke

The honest comparison isn’t a faster process — it’s an absent one. The site this replaced had been about to be redone for months. Nobody was ever going to spend three weekends on it.

Overview

What this card automates

Rebuilding a website is two different jobs that people usually mash into one. The first is deciding what the site has to say and do — who it’s for, what objection it has to defeat, what happens in what order. The second is making it exist. Almost everyone starts with the second job, picks a template, and then discovers halfway through that they never settled the first one.

The move here is to split them deliberately. Spend an hour with Claude writing a real brief — audience, positioning, banned phrases, section-by-section copy that’s actually usable, and a list of the assets only you can supply. Then hand that brief to Claude Design and let it build. The brief does the thinking; the builder does the building. A vague brief produces a generic site no matter which tool you point at it.

Then there’s the third job nobody mentions: pointing the domain at the new host. That’s where this one drew blood, and it’s the reason this card is worth reading even if you never build a site with AI.

This workflow built 3rdspacebucharest.com — the site you’re reading this on.

Before

What it replaced

A page on Canva Sites that had been “about to be redone” for months.

01No email capture. The single most valuable thing the site could do — take an address from someone who’d never been to an event — it couldn’t do.
02No way to embed the ticketing calendar. Every new event meant editing the page by hand, so it was usually out of date.
03The positioning wasn’t on it. The most differentiating fact about 3rd Space — that you get introductions to eight or ten guests before you arrive — was buried in a bullet.
04It read like everyone else’s. “Meaningful connections.” “Like-minded individuals.” The exact phrases the audience has learned to skim past.
05Nothing was measurable. No forms to track, so no way to learn whether anything on the page worked.
After

The three stages, in order

The order is the whole method. Building before briefing is how you end up with a site that looks fine and says nothing.

11 hr

Write the brief with Claudeconversation — no building yet

An hour of being interrogated about your own business, turned into a document a builder can execute without asking you anything.

  • Names the emotional target in one line — and what it is not. Here: make a busy, skeptical professional think “that sounds like a relief.” Not “exciting.”
  • Writes down the one objection to defeat, in the words the visitor would actually think it. Every section then exists as evidence against that sentence.
  • Sets voice rules as two lists — and bans specific phrases by name, so the generic ones can’t creep back in.
  • Orders the page as a narrative arc, marks the signature section, and drafts real copy for each one — not placeholder.
  • Ends with the asset list: the photos, quotes and decisions only you can supply.
Only you have this The hard numbers and the real quotes. 25 seats, 210 people through the door, nine-plus nationalities, the venue address, what an attendee actually wrote you. Claude structures the argument; you supply the facts it’s made of.
2~4 hrs

Hand the brief to Claude Designbrief in, site out

The build stage takes the finished brief as its input. You’re not re-explaining the business — it’s all in the document.

  • Builds the long-scroll homepage in the section order the brief specifies, using the brief’s draft copy as real copy.
  • Builds the second page — here, the AI Circle cohort page — under its own rules, since urgency is legitimate there and not on the homepage.
  • Puts the numbers that change monthly into one editable component, so updating them later isn’t a redesign.
  • Deploys to Netlify.
Watch for Your specific copy being “improved” into community-speak, and placeholder images surviving to launch. Both are fixed by saying so in the brief — and by having the real photos ready before this stage starts, not during it.
32 hrs

Move the domainthe dangerous one

Point the domain at the new host — and carry the email records across with it.

  • Export or screenshot the entire existing DNS zone before touching the nameservers.
  • Recreate every non-website record in the new zone first: MX, SPF, DKIM, DMARC, and any verification records.
  • Then switch the nameservers.
  • Test inbound mail from an outside address, on a different provider, and check again the next day.
This is where it broke It didn’t go in this order the first time. See below — it’s the most useful thing on this card.
Stack

What it runs on

Claude · Cowork Claude Design Netlify Bluehost (domain) Google Workspace (email) Luma (tickets) Substack (list) dig / DNS lookup
Where it breaks

The email outage nobody warns you about

The one that got us

Your website will work perfectly. Your email will have nowhere to go.

Moving a domain to a new host means the new host’s nameservers become authoritative. Everything your domain does — serve a website, receive mail, prove that mail is really from you — lives in that zone as separate records. Only what’s in the new zone exists. The website records get set up as part of launching the site. The mail records are not part of “the website,” so they quietly don’t come along.

And nothing tells you. There’s no error, no alert, no red banner. The bounce message goes to whoever emailed you. Your inbox just gets quiet — and a quiet inbox looks exactly like a normal slow week.

It went on for days. It only surfaced because someone mentioned in passing that their email to me had bounced.

  • Screenshot the whole DNS zone before you switch. Every record, every type. Afterwards, getting a clean look at the old one is hard.
  • Know which records aren’t about the website. MX (where mail is delivered, with priority numbers), TXT starting v=spf1 (who may send as you), DKIM keys, the _dmarc policy, and any domain-verification records.
  • Create them in the new zone first, then switch nameservers. Not the other way round.
  • Exactly one SPF record. Two v=spf1 records on one domain is a permanent failure, not a merge — combine them into a single record.
  • Test from outside. Send from a different provider’s address. Emailing yourself from yourself proves nothing about inbound routing.
  • Then set a reminder for 24 hours later that says “did anyone email me?” That one habit is the whole lesson.

Give propagation time before you “fix” it again

Once correct records are in, delivery still isn’t instant — old answers stay cached for as long as the TTL says. Changing things again after twenty minutes because mail hasn’t arrived turns a short outage into a long one.

Lower TTLs to 300s a day before the switch if you can.

A vague brief beats no brief, and loses to a specific one

“Make it look modern” produces a site indistinguishable from every other one. A named objection in the visitor’s own words produces a site that argues.

The most valuable line in the brief: "Am I going to have to work the room?"

Say that the draft copy is real copy

Write it into the brief explicitly, or your specific, hard-won lines get smoothed into “meaningful connections” and “vibrant community” during the build.

Ban the clichés by name in the brief's Don't list.

Placeholders survive to launch

If the real photos aren’t ready when the build starts, stand-ins go in — and stand-ins have a way of still being there on launch day. Gather assets as stage zero.

Highest-leverage asset here: a real, anonymised excerpt of the pre-event intro email.

Build the parts that change as swappable blocks

Dates, prices and headline stats change every month or every cohort. If they’re woven through the layout, every update becomes a redesign.

Stats in one component; cohort dates and pricing in their own blocks.

Don’t let the site handle money

Tickets stayed on the existing platform and the site just hands off. One less thing to build, one less thing to secure, one less thing that can break on a Friday night.

The site's only job is capturing an email address.

Copy this

The brief template and the cutover checklist

This workflow’s reusable part isn’t a skill file — it’s these two documents. The first one decides your site. The second one saves your email.

website-design-brief-template.md 
# Website Design Brief — template

Work through this with Claude in conversation *before* any building starts. Answer in your own words; let Claude push back and ask for specifics. The output is one document you hand to Claude Design.

The brief is where the site is decided. The builder just executes it.

---

## 1. The brief in one line

What should a visitor feel? Name one emotion, and say what it is *not*.

> Example: Make a busy, skeptical professional think "that sounds like a relief." Not "exciting." Not "high-energy." A relief. That emotional target governs every layout, photo and line of copy.

## 2. Who this is for

- Who exactly — age, work, city, income, taste
- What they already tried that didn't work, and why it drained them
- How much time and patience they have on this page
- **The one objection to defeat.** Write it as a sentence they'd say in their head.

> The objection is the most useful line in the whole brief. Every section is evidence against it.

## 3. Positioning

One sentence that is the site's whole argument. Then three proof pillars — facts, not adjectives — that recur structurally throughout the design.

Also write **what this is not**. A list of the adjacent things you'll be mistaken for.

## 4. Voice and copy rules

Two lists, both specific:

- **Do:** sentence length, person ("you" vs "we"), the kind of detail that belongs (real place names, real numbers)
- **Don't:** the exact phrases you never want to see. Name them. Every competitor's clichés, banned by name.

> Rule of thumb: if a line could appear on any competitor's site, cut it.

## 5. Structure

The page order, numbered, as a narrative arc. Say the arc out loud — e.g. *recognition → relief → proof → invitation*. Note which section is the signature one and must get the most space.

Navigation: what's in it, what happens on mobile.

## 6. Section by section

For each section: the layout note, the photo direction, and **real draft copy — not placeholder**.

Say explicitly at the top: *"Draft copy below is real, usable copy. Refine tone, keep the substance."* Otherwise the builder rewrites your specific lines into generic ones.

For each section, cover:

- What it has to accomplish
- Layout / visual treatment
- The actual words
- Any design note that isn't obvious ("the email field must be live here, not a button that scrolls to a form")

## 7. Additional pages

Same treatment, but note where the rules differ from the homepage and why.

## 8. Visual direction

Layout-level only if a design system already exists. Cover:

- What the primary design material is (photography? type? data?)
- Mood in physical terms — a time of day, a place
- Whitespace, accent colour usage, motion
- **What's banned.** Stock photography, icon soup, gradient-heavy styling — whatever your audience reads as low-effort.

## 9. Technical requirements

A table: need → recommendation. Platform, forms, email list, embeds, payments, analytics, performance budget, SEO and Open Graph.

Say what the site must *not* do — e.g. "the site never handles money; it hands off."

## 10. What you still need to supply

A checklist of assets only you can produce: photos, headshots, testimonial attributions, logos, cover art, and any decision still open. Mark the highest-leverage item.

> Do this before the build, not during. A builder with no photos fills the space with placeholders, and placeholders survive to launch.

## 11. How to know it worked

Two or three observable outcomes. Not "looks good" — things you could actually watch someone do.

## Appendix — reference facts

Every hard number, date, price, address, URL and quote in one place, so nothing gets invented mid-build.

To use them:

  1. Paste the brief template into a conversation with Claude and say: “Interview me through this for my site. Push back when my answers are vague.”
  2. Don’t accept your own first answer on the objection or the voice rules — those two do most of the work.
  3. When the brief is finished, hand the whole document to Claude Design and let it build.
  4. Before you point the domain anywhere, run the cutover checklist. All of it.
Built by Eric Melchor Founder, 3rd Space Bucharest. Built 3rdspacebucharest.com this way in August 2026.

More cards in 3rd Space AI Workflows — each one a real workflow from a real member, with the template attached.