The loop
How building a site by conversation works
Building a site by conversation works as one short loop: describe it, watch it build, check the preview, then publish it.
You describe what you want in plain English, the build narrates itself as it goes, and the result lands on a live preview URL that only you can see. When it looks right, one click publishes it to your own domain. Corrections are one line each, and there is no limit on how many you send.
A site for my bike shop. Opening hours, a repair booking form, and it has to look calm rather than shouty.
Building a four-page site: home, repairs, opening hours and contact. Adding the bookings module for the repair slots, and taking a deposit is one switch if you want it later.
warm neutral base · one amber accent
Build 14
- Read the brief
- Wrote 4 pages
- Installed @ccd/bookings
- Generated opening hours markup
- Auditing built HTML
6 steps
Describe, build, preview, correct, publish, audit.
The loop is short on purpose. Every step ends in something you can look at, so a misunderstanding surfaces while it is still one sentence to fix.
01
Describe what you want
Write it the way you would say it out loud. Six words is a complete request: "add a testimonials carousel to the homepage" is a job, not a fragment. Expanding it into a plan is the platform’s work, not yours.
02
Watch the build narrate itself
Each step is announced in one plain line before it happens — "reading the homepage", "adding a contact section" — so you can tell whether it understood you while it is still cheap to say otherwise.
03
Look at the live preview
Every build lands on its own preview URL before it goes anywhere else. The preview is the confirmation: you see the change before any visitor can, which is why almost nothing needs a clarifying question first.
04
Say what to change
Course-correction is one line. "Too much purple", "move the form above the map", "make the headings smaller" — all of those are complete instructions, and none of them costs a fresh start.
05
Publish to your own domain
One click puts the build on your custom domain with a certificate already issued, usually in about twenty seconds. The previous version stays available, so publishing is reversible.
06
Let the audit close the loop
The published site is scored across five pillars and the findings come back in plain English. Approving a fix starts the loop again from step two, with the work already described.
Preview and publish
The preview is the confirmation.
A build does not go to your domain. It goes to its own URL, with its own report: what was produced, what the page checks said about it, and what the visibility audit scored. Publishing is a separate, deliberate act.
That separation is what makes short requests safe. There is no need to interrogate you about a colour or a heading when you are about to see both, and a preview you dislike costs one sentence rather than a rollback.
Publishing is reversible. The version that was live stays available, so replacing it is a decision you can undo.
- 12 pages built
- 2.4s
- Checked built HTML
- 0 failures
- Visibility audit
- 90/100
- Uploaded to edge
- 1.1s
Content is not a build
The things you change weekly never need one.
Asking for a build to change a price would be a bad trade, so the content that changes often lives in a panel and renders at request time.
- Copy and headings
- A panel field. Saved instantly, live on the next page view.
- Photographs
- Upload once; every size and format is generated for you.
- Prices and stock
- Rows in the catalogue. No build, no deploy.
- Opening hours
- One panel, and the structured data updates with it.
- Testimonials
- Approve an entry and it appears where it was placed.
- Posting schedule
- A queue you edit, not a build you request.
Builds are for structure: a new page, a new section, a different layout, a module installed. Placing a testimonials carousel is a build; the quotes inside it are not.
The engine
Model-swappable, on purpose.
The build engine is not welded to one model. That matters less for what it can do today than for what happens next year.
One engine, many projects
Every project is built by the same engine reading the same conventions, so a fix made once is a fix everywhere.
Upgrades are free of rewrites
A better model is a configuration change. No project has to be migrated to benefit from it, because none of them depends on the model’s quirks.
Conventions over prompts
Each project carries its own written conventions, and those win over the engine’s defaults. The site teaches the builder, rather than the reverse.
Q&A
Questions about building this way
How long does a build take?
A small change is usually under a minute; a new page or a restyle is a few minutes. Publishing after that takes around twenty seconds, because the site is static files going onto an edge network rather than a server being restarted.
Is there a limit on how many times I can ask for changes?
No. There are no message limits and no credit meter counting your prompts, because a platform that charges per instruction quietly teaches you to write worse instructions.
Can I see and edit the code?
Yes. Every project is a real Git repository — Astro, Tailwind and React — that you can clone, read, edit and push. Nothing is hidden behind a proprietary editor format.
Which AI model builds the site?
The engine is model-swappable, and the current default is the strongest available Claude model. The interesting part is not which model it is today; it is that upgrading the model upgrades every project without any of them being rewritten.
What if a build breaks something?
You see it on the preview rather than on your domain, and the previously published version stays live until you choose to replace it. Rolling back is a click.
Do I have to describe things in a particular way?
No. Short requests are the normal case and are read generously: what artefact, on which page, from what data, styled how. If a request is genuinely ambiguous between two different things you get asked; if the preview would answer it anyway, you get the preview instead.
It starts with one sentence.
Describe the thing you want to exist, then look at what comes back. Correcting a preview is faster than writing a brief.