The problem#
The slow part of a website isn't typing HTML. It's the loop around it: brief → structure → copy → design → build → review → fix → deploy — with a human handoff at every step, and every handoff a place for a week to disappear.
Skip the loop and you get the other failure: a site that looks finished and says nothing. Generic structure, copy nobody would say out loud, a layout that was never a product decision.
So the goal wasn't “generate websites”. It was a production workflow where the drafting and the building can be delegated, and the judgement can't.
How does it work?#
business brief → agents draft structure and copy → first working build → my direction pass → revisions → responsive QA → deploy
The agents do the first draft of everything. I do the decisions, and I hold the last two steps.
- brief
- Who it's for, what it sells, what the one job of the page is.
- first_build
- Agents turn the brief into structure, draft copy and a working front end.
- direction
- My pass on product decisions, hierarchy and visual judgement — what stays, what gets cut, what gets rewritten.
- revision_pass
- Changes are directed, not requested: singular, specific, in priority order.
- qa
- Copy read aloud, responsiveness checked, links and states verified before anything goes live.
- deploy
- The site goes live, by hand, when I say it's ready.
That's what makes it a workflow rather than a trick: the parts that depend on taste are isolated, reviewed one at a time, and never handed to the machine.
What did I build?#
- A brief format agents can act on. One page that carries audience, offer and the job of the page — so drafting starts from a decision instead of a vibe.
- A repeatable build scaffold. The first working version arrives with structure, copy and layout already in place, so review starts on something real.
- A review protocol. A fixed order — product, then brand, then words — so revisions are decisions instead of a long list of nitpicks.
- A pre-launch check. Copy read aloud, responsive behaviour, links and states, then deploy.
- Agent orchestration. Multiple agents on one build need a single source of truth and clear boundaries, or they overwrite each other's intent.
The constant is the loop and the review protocol — not the tooling.
Before and after#
| Stage | The usual loop | This workflow |
|---|---|---|
| Brief to structure | Wait for a sitemap and wireframes | Brief becomes structure and page order in one pass |
| Copy | Placeholder text blocks the build | Draft copy arrives with the structure, then gets rewritten by me |
| Build | Every layout starts from blank | Agents build the first working version against an agreed structure |
| Review | Round trips between design, copy and dev | One directed revision pass: product, brand, words |
| Live | Deploy is its own project | Responsive check, then deploy — and the last step is mine |
What changes is where the hours go: less time producing the first draft of everything, more time deciding what's actually good.
Technical depth#
- agent orchestration
- front-end
- copy refinement
- deployment
- responsive QA
The workflow isn't tied to one framework. What's fixed is the sequence and the checkpoints — brief, first build, directed revision, QA, deploy — and those are portable.
The clearest thing I can say about the division of labour: the agents are fast at producing the first version of anything, and equally fast at producing a plausible version of the wrong thing. The review protocol is what stops the second one reaching a live site.
Production readiness#
A generated site fails politely: it loads, it looks fine, and it says the wrong thing in the wrong order. The safeguards aim straight at that.
- Nothing ships unreviewed. Every page goes through the same pass: product, brand, words, then behaviour.
- Copy gets read aloud. If I wouldn't say it out loud, it doesn't go on the site.
- One source of truth per build. Structure, copy and design decisions live in one place so the build can't drift.
- Deploy is a human step. Going live is a decision, not an automatic consequence of a build finishing.
Unglamorous rules, and the reason the speed doesn't cost quality: the same checklist runs whether the draft took four days or twenty minutes.
The result#
A repeatable route from brief to live site across the kinds of sites that come up most: product launch, service business, editorial and luxury, conversion page, app landing.
The metric that matters here — brief to first working version, and revisions per site — isn't published yet. It's being measured, not estimated.
Until then, the honest claim is the process itself: agents draft, a human directs, and every site passes the same review before it goes live.
30-second walkthrough#
Why this matters to an employer#
Speed with control
The first draft of everything stops being the bottleneck, and the review protocol keeps the standard.
Front-end and product judgement
Knowing which structure is right is the work; producing it is the part that got fast.
Orchestration
Coordinating agents with clear boundaries and one source of truth is the same skill as coordinating any pipeline.
Deployment
I take it all the way live and check the result, rather than handing over a file.
AI as leverage, not abdication
Keeping quality control while moving fast is the balance most teams are still looking for.