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.
Step one: turning a sentence into a plan
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. "Three services: haircut, beard trim, and hot towel shave, each with a price and a duration" gives the planner far more to work with than "some services."
Step two: generating a working app, not a mockup
The difference between a design tool and code-anything is that what gets generated is real software, not a picture of software. The output is an actual application — front-end pages, the logic behind them, and the data layer they read from and write to. That 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.
You see this 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.
Step three: 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. So the preview supports click-to-edit: you select the thing on the page you want to change and adjust it directly. You can also work the other way around — hand the system a screenshot of a design you like, and it will reproduce that layout in your app.
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.
Why the preview is the real workspace
Treat the preview 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.
Step four: the parts you never had to set up
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 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 — and it is exactly the part that is handled for you.
- A managed Postgres database, provisioned and connected — your appointments, products, and customers have somewhere to live.
- Authentication, so users can sign up and log in, without you building password handling or session security.
- Transactional email through Resend, so confirmations and receipts actually arrive in inboxes.
- Stripe payments wired in, so you can charge customers — no separate Stripe integration project to manage.
The honest framing: these are best-in-class services — Supabase for the database and auth, Resend for email, Stripe for payments — connected on your behalf so you do not have to create the accounts or hand-wire the keys. You get the capability without the setup tax.
Step five: Go Live
When the preview looks right, you Go Live. The app is deployed to a real, public URL on production infrastructure — built on Cloudflare — that 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.
A simplified picture of the lifecycle looks like this:
prompt → describe the app in plain language
plan → infer pages, data, and actions
generate → produce a real, running application
preview → click-to-edit / screenshot-to-design loop
wire backend → Postgres + auth + email + payments (automatic)
go live → deploy to a real URL on CloudflareWhat 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.