The loop
How it works
Q-Code turns a written brief into a published website in four steps: you describe it, it states how it read you, it builds a preview, you publish.
The part that matters is the order. Every change is visible to you before it is visible to anyone else, and the step that makes something public is always one you take deliberately.
At a glance
The four steps
01
Describe it in a sentence
No brief template, no specification document. "A one page site for a plumber in Luton, with a contact form and prices" is enough to start. Short requests are the normal case and the platform is built to expand them rather than send them back.
02
It states how it read you, then builds
Before touching a file the agent says in one line what it understood you to mean. If that line is wrong you have lost a sentence, not an afternoon. Then it writes the pages, the components and the structured data together.
03
You see it before anyone else can
Every change lands on a private preview build first. The live site keeps serving the last published version until you say otherwise, so nothing reaches a visitor because a build finished.
04
Publish, on your own domain
One action puts it on a real domain with a certificate, a sitemap, and a copy pushed to your own GitHub repository. The published site is static files on a global network, so it stays up whether or not the builder is running.
Detail 01
A short request is a complete request
Most briefs arrive as a line, not a document. "Add a testimonial carousel to the home page" is six words, and turning it into a plan is the platform's job rather than yours.
So the agent expands it internally before acting: which artefact, on which page, reading what data, styled how, and what obvious accompanying parts it needs. A carousel needs a component, a placement, a data source and behaviour at every width. You should not have to list those.
Detail 02
It says how it read you, in one line
Before touching a file it states its reading. One line, not a plan and not a set of clarifying questions, because a question costs you a round trip and usually gets a vaguer answer than the platform's own judgement.
It pauses only when it genuinely should: when a request could mean two materially different things, when the work is large, or when something would be deleted or replaced. Everything else goes straight to a preview, because the preview is the confirmation.
Detail 03
Content and structure are different jobs
Adding a testimonial and adding a testimonials section look similar and are not. One is data, the other is a change to a page.
So the words, the entries and the settings live as rows in a database, edited in a panel: about a second, nothing spent, and the build machine stays asleep. Pages, layout and components are code, and changing them is a build. The platform routes your request to whichever of the two it actually is, and tells you which it chose.
Detail 04
Nothing goes live because a build finished
Every change lands on a private preview first, built with the production address so what you are looking at is exactly what publishing would put live. Same canonical links, same cards, same sitemap.
The live site keeps serving the last published version until you choose otherwise. Publishing is a separate action, and it also pushes a copy of the whole project to your own GitHub repository, so the site exists somewhere that is not the build machine.
Then what
Once a site is live, the parts you change most often stop needing a build at all. Read what comes as standard, seewhat each kind of change costs, or look atthe kinds of site it suits.