From Prompt to Live Website: How It Actually Works End to End

The phrase "type a prompt, get a website" sounds like a magic trick, and like most magic tricks it works because of a lot of unglamorous machinery happening offstage. If you are a non-technical builder — a founder, a shop owner, an operator with an idea — it helps to understand that machinery, because knowing what the system is doing lets you steer it well. This guide walks through the whole path, from the sentence you type to the live URL you can hand to a customer, and it names the surface you will be looking at during each stage so nothing arrives as a surprise.

Read it once before your first build and the whole flow will feel familiar. Read it again after your first build and the parts that felt arbitrary will make sense.

What "prompt to website" is, and what it is not

It is worth clearing two misconceptions out of the way first, because both of them cause people to misjudge the tool in opposite directions.

The first misconception is that you get a picture of a website. You do not. What gets generated is real software — actual pages, actual logic behind them, actual tables that store data. The distinction matters the moment a visitor clicks a button: a mockup does nothing, while a real app saves the appointment, sends the email, and charges the card.

The second misconception is that the machine reads your mind. It does not. It reads your description. Everything downstream — the pages, the data model, the buttons — is inferred from what you said and from what the agent asks you afterwards. That makes the quality of your description the single biggest lever you have, which is why this guide spends the first two sections on it rather than on the technology.

Step one: the brief, not the prompt

When you describe what you want — "a booking page for my barbershop with three services and a contact form" — the first job is not writing code. It is interpretation. The system reads your prompt the way a good contractor reads a rough sketch: it infers the pages you will need, the data you will store, and the actions a visitor should be able to take. A booking page implies a list of services, a calendar or time slots, and somewhere to save appointments. None of that was in your sentence explicitly, but all of it is implied.

This is why the more concrete your prompt, the better the first result. You are not programming; you are briefing. And a brief has a shape.

What a useful brief contains

• Who uses it. A visitor who never signs in, a customer with an account, and an admin who manages the content are three different apps. Say which ones exist.
• What they do. The verbs are the features. Book, cancel, pay, upload, filter, export — each verb implies a screen and usually a table.
• What gets stored. If you want to look at it later, it has to be saved. Appointments, orders, submissions, uploads: name them.
• What the screens are. Even a rough list — home, services, booking, confirmation — gives the plan a skeleton to hang on.
• Whether money changes hands. Payment is the single largest fork in the design of an app. Say yes or no early.

Worked example: the same idea, briefed two ways

Compare these. The first is a prompt. The second is a brief.

Vague:
  "a booking page for my barbershop with some services"

Specific:
  A booking page for a two-chair barbershop.
  Three services: haircut (30 min, 25), beard trim (15 min, 12),
  hot towel shave (45 min, 40).
  Visitors pick a service, pick a slot, and leave name + email + phone.
  The booking is saved and the customer gets a confirmation email.
  I need a page only I can see that lists tomorrow bookings.

The second version contains a data model (services with a duration and a price, bookings with contact details), an email requirement, and an admin screen behind sign-in. None of that had to be phrased technically. It just had to be said.

You do not have to get this right the first time, and you should not agonise over the wording. A vague first prompt still produces a working starting point, and everything after this step is designed around refining it. But a good brief buys you fewer correction rounds, and correction rounds are the part that costs you time and credits.

Step two: the scoping conversation and the blueprint

A new project does not leap straight to building. It opens in chat first. The agent asks about the parts of your idea it genuinely cannot guess — who signs in, what gets stored, whether money changes hands — and fills in a blueprint as you answer. Treat these questions as the cheapest part of the whole process. Answering a question now costs a sentence; discovering the same gap after the build costs a rebuild.

The blueprint itself is a control in the project header. It stays labelled Blueprint while the scope is still thin, and changes to Review blueprint once the agent thinks it has enough to build from. That label is a genuinely useful signal: it is the system telling you whether it believes it understands the job yet.

What the blueprint shows you

Opening it shows what is about to be built and which services it will use, with each service marked as managed for you or connected under your own account. This is the moment to catch a misunderstanding, because it is the last cheap one. If the blueprint says it is building a public listing page and you meant a private admin page, say so now.

Choosing how much effort the build should spend

You also choose a build quality, which is simply how much effort the build is allowed to spend on itself. There are three settings and they trade speed against thoroughness in a predictable way.

• Prototype — the fastest and cheapest, with fewer checks. Right for a throwaway experiment or a first look at whether an idea has legs.
• Standard — the balanced default. Right for almost everything.
• Best — researches current practice and reviews more before shipping. Right when the thing you are building has to hold up: anything touching money, sign-in, or data you would be embarrassed to lose.

Nothing chosen here is permanent. You can change anything after the first build. The blueprint is a starting point, not a contract.

The cheapest correction is the one you make before the build starts. The second cheapest is the one you make in the preview. Everything after that costs progressively more.

Step three: the first build, and the sandbox underneath it

Confirming starts the first run. Your project gets a sandbox — an isolated container that holds the code and runs the dev server — and the Preview tab renders whatever is running inside it. The sandbox is not your laptop and it is not a repository. That isolation is exactly what makes an in-progress change harmless: nothing that happens in there can damage anything that matters.

While this happens you get a boot panel with a terminal streaming the actual steps: claiming a container, booting the runtime, installing dependencies, starting the dev server. It is worth watching once, because it demystifies everything that follows.

Why the first boot is the slow one

The first start of a project provisions a container from scratch and installs dependencies, which can take up to a minute. Later starts are warm and much faster. If a boot fails, the start control turns into a retry, and the terminal output above it names the step that failed rather than just reporting failure. A second attempt clears most transient container problems.

One more thing worth knowing early: the preview sleeps on its own after about five minutes with nothing hitting it, and it is metered per second while it is running. That is an idle window, not a countdown from when you started — every request resets it, so a preview you are using stays up. Walk away and the first visit after lunch may need it started again. That is normal, not a fault.

Step four: the preview is the real app

You see the app come together in a live preview almost immediately. The preview is not a static screenshot — it is the running app. You can click through it, fill in forms, and watch real behavior. Treat it as your iteration loop, not a final check. Change one thing, look, change the next.

Because the preview is the live app, what you approve there is what ships. There is no translation step where a design quietly becomes something different in production.

Two preview behaviours that look like bugs and are not

While a build is running, the preview deliberately keeps showing your last stable version and labels it as such, then refreshes itself when the build finishes. It looks stale; it is protecting you from watching a half-built page assemble itself. And if a feature is dead while the page itself loads fine, look for the missing-secrets banner — it counts the required environment keys that have no value and links straight to the tab where you can fill them.

Step five: editing by pointing, not by prose

Describing changes in words is fine for big strokes, but tedious for small ones. "Make the heading bigger and move the button under the photo" is slower to type than to do. The division of labour that works is simple: chat for behaviour, the visual surface for design.

Element selection instead of describing location

Design work happens on the Studio tab, which has a live mode: you arm element selection, click the thing you mean in the running app, and describe the change against that focus. This is the difference between "the second button in the third card on the pricing section" and clicking the button. Selection ties your instruction to a specific element, so edits land where you mean them instead of rewriting the page.

The Preview tab itself deliberately keeps only two controls — refresh, and open the running app in a new browser tab — precisely because selection moved to Studio. If you go looking for click-to-edit on Preview and cannot find it, that is why.

Reference images

You can also work the other way around: attach a reference image to a message when you want the agent to match a look. A competitor page, a design export, a photograph of a sketch on paper — anything that gives the agent a concrete visual target instead of an adjective. Expect a close match rather than a pixel-exact reproduction, then fine-tune the specific elements that matter by selecting them.

The fastest way to describe a visual change is usually to point at it. The fastest way to describe behavior is usually to say it. Good prompt-to-website tools let you do both.

Step six: the parts you never had to write

Here is where most "build it yourself" journeys quietly die. A real app needs a place to store data, a way for users to sign in, a way to send email, and — sometimes — a way to take payment. Each of those is normally a separate account, a separate dashboard, a separate set of keys to copy into the right place without typos. The slow, error-prone wiring is the actual work.

• A Postgres data layer, written in from a vetted brick the moment your app needs to store data — your appointments, products and customers have somewhere to live, in ordinary Supabase tables you can read.
• Sign-in from the auth brick — a session provider, a login and sign-up form, a route guard and a profiles table under row-level security — so you are not writing password handling or session security yourself.
• Transactional email through Resend. This is the one layer with no brick behind it: the sending code is generated for your app, against a Resend key you supply, from a domain you have verified.
• Stripe checkout and subscriptions from the payments brick, on the plans that include payments — the checkout endpoint, the client redirect and a signature-verified webhook, written against your own Stripe account.

The honest framing: these are best-in-class services — Supabase for the database and auth, Resend for email, Stripe for payments — and what is removed is the code you would otherwise write to talk to them, not the accounts underneath. The integration lands in your own repository from vetted bricks; connecting the account it runs against is a separate, explicit step, and for Stripe and Resend that account is yours by default, so the money settles with you and mail leaves from your domain. It is worth knowing which parts sit on which plan: the data layer, sign-in and the sending code are written in on every plan including the free one, while payments arrive with the paid tiers.

A brick only goes in when your request actually needs it, so a plain marketing page stays a plain marketing page rather than dragging a database along behind it.

Step seven: checking what actually got built

This step is the one most people skip, and it is the one that separates a confident launch from a hopeful one. Under Repository, the Features tab lists every feature the agent has built for the project and whether the most recent build confirmed it still works. A passing build re-verifies the whole list; a failing one flags what it touched.

Read that list before you go live. It is an inventory, and inventories catch two things a preview will not: something you asked for that quietly did not get built, and something that used to work and stopped.

The neighbouring Changes tab shows the history of accepted states — the checkpoints of your project as it evolved. You will meet it again the first time you need to go backwards.

Step eight: Go Live

When the preview looks right, you Go Live. The action lives on Repository → Deploy. It ships the current build to production hosting on Cloudflare and gives the project a real, public address over HTTPS — one you can put on a business card or send to a customer. There is no separate "now learn how to deploy" chapter. The thing you were previewing becomes the thing the world can visit.

What you get back is a deployment status card with the live URL, when it last shipped, the sandbox preview URL, and the Cloudflare project, which is provisioned on the first Go Live.

Publishing is continuous, not a one-time event

Once a project is live, the same button becomes a redeploy. This is a small detail with a large consequence for how you work: shipping stops being an event you schedule and becomes something you do whenever a change is ready. Every attempt is written to the deploy history on the same tab, including the failures, so you can always see what shipped and when.

A custom domain is available on the paid plans. Free-plan apps go live on the address they are given and carry a small "Built with code-anything.com" badge, which is removed on every paid plan.

The whole lifecycle in one picture

brief         → describe the app: who, what, what is stored, money y/n
scope         → agent asks what it cannot guess; blueprint fills in
confirm       → review the blueprint, pick a build quality, start
sandbox       → isolated container claimed, deps installed, dev server up
preview       → the real running app, not a mockup
iterate       → chat for behaviour · Studio selection for design
wire backend  → Postgres + auth + email (+ payments on paid plans)
verify        → typecheck, tests, build, repair, re-check
features      → read the inventory of what exists and what passed
go live       → deploy to a public HTTPS URL on Cloudflare
redeploy      → the same action, every time after the first

What the loop feels like after the first week

The first build is the memorable one, but it is not representative. Most of the value shows up in the twentieth change, not the first, because by then the pattern has settled into something like a rhythm: describe a change, watch it land in the preview, glance at the feature list, redeploy. The unit of work shrinks. You stop batching up a month of ideas into a terrifying release and start shipping the one thing you thought of this morning.

That shift is the actual product benefit, and it is worth aiming for deliberately. Small changes are easier to describe, easier to verify, easier to review, and easier to undo. Large changes are the opposite in every one of those dimensions.

Common mistakes, in rough order of how much time they cost

1. Skipping the scoping questions. They exist because the answers cannot be guessed. Answering them costs a sentence each; not answering them costs a rebuild.
2. Asking for five unrelated changes in one message. Each one becomes harder to verify and harder to attribute when something breaks. Ask for one thing, look, then ask for the next.
3. Describing where something is on the page instead of selecting it. Use Studio selection for anything visual — it is faster to click than to describe, and far more precise.
4. Judging the preview during a build. It shows your last stable version on purpose while a build runs, then refreshes itself when the build finishes.
5. Going live without reading the feature list. The preview shows you the page you are looking at; the feature list shows you everything you are not looking at.
6. Treating the first result as the verdict. The first build is a starting point by design. Steering it is the job, not a sign that something went wrong.

What this does and does not change

What changes: the distance between an idea and a working product collapses from weeks of account-creation and integration into an afternoon of describing and refining. What does not change: you still need to know what you want and judge whether the result is good. The tool removes the plumbing, not the thinking. Your taste, your understanding of your customers, and your willingness to iterate are still what make the difference between a generic page and a product people use.

If you are starting out, begin small and concrete, ship something live early, and improve it against real feedback. The whole point of a fast prompt-to-live loop is that "ship and learn" stops being a slogan and becomes your default speed.