The loop
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
6 steps
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
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. You can attach things to a message too, so a logo or a set of photographs arrives with the instruction that needs them.
02
Each step is announced in one plain line before it happens: "reading the homepage", "adding a contact section". You can tell whether it understood you while it is still cheap to say otherwise, and a brief too big for one run is planned into phases you watch land one at a time.
03
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
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
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
The published site is scored across six 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
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.
The cockpit
Home is every project you own as a card: a real screenshot of the site as it looks now, captured at the edge, the domain it answers on, and what it has cost so far this month.
Every project as a card. The picture on it is a real screenshot of the site as it looks now, captured at the edge rather than picked from stock, so a board of eight projects is readable at a glance.
Opening a project gives it a screen of its own, so a project is somewhere you go rather than a filter on a list.
One strip that states the project’s state in plain words and offers exactly one action. Not twelve buttons: the next one.
A command palette on one keystroke, for getting to a project, a panel or a page without remembering where it lives.
Spend is shown per build and month to date, per project and for the platform as a whole, so the bill is a number you glance at rather than a statement you go and open, and a budget warning arrives before a budget is crossed. Publishing is confirmed in the same place you asked for it: you press publish in the cockpit and the answer comes back inline, rather than in a log somewhere else.
The chat
Two things the chat takes off you: giving the builder a file to work from, and getting through a job that is too big for one sitting.
Attach a logo or a set of photographs to a message, drag them onto the chat, or paste them straight in. They arrive as part of the request rather than as something to upload somewhere else first.
A brand file that sits on a solid background is offered a transparent version, shown as a before and after, and it takes a nod from you before it is used. The original is kept either way. Which makes a rebrand about as long as it sounds: attach a logo, type rebrand, done.
A brief too big for one run is recognised as one before the work starts. It is planned into phases and run a phase at a time, with the preview brought up to date in between, so a long build is a sequence of things you can look at rather than one long silence.
If it stops, hits its turn cap or restarts, it resumes from the last completed phase. Work that was already finished is not done again.
Coming from somewhere else
Import is a guided page rather than a support conversation: source, pre-flight, import, gates, result, each one visible and each one passed before the next opens.
01
Say which Lovable project is coming across and where it lives.
02
What could go wrong is checked before anything is moved, and it is reported in plain words.
03
The project comes over onto infrastructure held in your name.
04
The steps that are hard to undo wait for explicit verification. The domain is behind them.
05
What came across, what it looks like now, and what is left for you to decide.
The gates are the point of the page. Three of them have to clear before your custom domain moves: a real member signs in on the imported site, a real payment event arrives from the provider, and the secrets are rotated so the old project cannot act on the new one. Nothing dangerous is automated away.
An imported React site is not a second-class project either. It gets the same owner admin console a site built here from scratch gets, with an overview, analytics, brand voice and access, drawn in the imported site’s own palette.
Moving a Lovable project to Q-Code covers the five steps and the three gates in full.
How Q-Code and Lovable differ covers what changes once a project is here, which is mostly a question of who holds the hosting, the repository and the domain.
Content is not a build
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.
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
Most changes go to a fast, capable model by default. A large rebuild or a creative brief is routed to the strongest model available, because that is where the quality bar actually needs it.
A small edit does not need the same model as a new page built from nothing. The engine picks the model the change actually calls for, rather than paying for the strongest one every time.
Generated copy passes through a gate that enforces the house voice and British English before it reaches the page, whichever model wrote it.
A long change checkpoints its progress and continues rather than stopping at a limit. If it is about to spend past a cost ceiling, it warns you and asks first.
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
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.
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.
Yes. Every project is a real Git repository, built with Astro, Tailwind and React, that you can clone, read, edit and push. Nothing is hidden behind a proprietary editor format.
Each change is routed to the model that earns it: a fast, capable model by default for most changes, and the strongest available model where the quality bar needs it, such as a large or creative build. Every piece of generated copy passes through a style gate that enforces the house voice and British English before it lands on the page.
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.
It is spotted as a large brief before the work starts, planned into phases, and run one phase at a time with the preview brought up to date in between. If it stops, hits its turn cap or the session restarts, it resumes from the last completed phase rather than doing finished work twice.
Yes, through a guided import wizard that runs in five steps: source, pre-flight, import, gates and result. Three verification gates have to clear before your domain moves: a real member signs in on the imported site, a real payment event arrives from the provider, and the secrets are rotated.
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.
Describe the thing you want to exist, then look at what comes back. Correcting a preview is faster than writing a brief.