The prompt-to-production lifecycle, explained

Picture a concrete project: a neighbourhood bakery wants a website. The owner types a paragraph into an AI assistant describing the shop, the opening hours, the croissants. Ninety seconds later there are three pages of layout and copy on screen. Between that moment and a customer in another city typing the bakery's domain into a phone, four distinct things have to happen. Most explanations of AI website building cover only the first one.

This post maps all four. The stages are the same whether the AI is ChatGPT, Claude, Lovable, Bolt, Cursor, or an agent framework nobody has launched yet, because the stages belong to the problem, not to any tool.

Stage 1: the build

The build is the famous part. You describe, the model generates, you react, it revises. Under the surface, every one of these tools converges on the same output: a folder of web files. HTML pages, stylesheets, scripts, images, sometimes produced by a build command, sometimes written directly.

Two things about this stage are worth knowing even if you never look inside the folder. First, the files are the product. Not the chat, not the preview, not the project inside the tool. If you can get the files, everything downstream is possible; if you cannot, you are constrained to whatever the tool offers. Second, the build stage has no natural end. AI will happily revise forever, and "the site is done" is a decision you make, not an event the tool announces. Projects that never leave stage 1 are the most common failure in this whole workflow.

Stage 2: the hand-off

The hand-off is the stage nobody's marketing mentions, and it is where the bakery site either becomes real or stays a screenshot. The generated files have to travel from the AI's environment to a host. Historically this meant a human downloading folders, creating accounts, and wiring up deployment tools, which is precisely the work the bakery owner was avoiding by using AI.

The modern answer is to make the AI do the hand-off itself. There are two mechanisms, matched to two kinds of AI tool:

• The magic file, for conversational assistants. A single instruction document, pasted into the chat, that teaches the assistant how to publish to the platform: what to send, where, in what format. The assistant packages the site it just wrote and pushes it over the platform's API from inside the conversation. One paste, and the tool that built the site also ships it.
• MCP, for agent clients. Tools like Claude Desktop or Cursor can connect to a Model Context Protocol server once, after which publishing is a built-in capability rather than pasted instructions. The agent can list sites, deploy, read what is live, and push an update, all as ordinary actions inside a session.

The distinction matters for how iteration feels later. With the magic file, publishing is something the conversation does at the end. Over MCP, it is something the agent can do at any moment. Both arrive at the same place, and the mechanics of both are described in how AI-hosted websites work.

Stage 3: the live domain

The hand-off produces a site on a platform address, live within seconds and fine for checking that everything works. A real launch needs one more move: the bakery's own domain.

Concretely this means three small events. The domain gets registered, or an existing one gets pointed at the host with a DNS record. The host starts answering for that name. And a TLS certificate is issued automatically so the site loads over HTTPS without anyone touching a certificate file. On a platform built for this workflow, the whole sequence is minutes of waiting rather than an afternoon of configuration, and the AI can be asked to set up its part.

Stage 3 is also the boundary line from our definition of an AI-hosted website: before it, you have generated files on a temporary address; after it, you have a website in the full sense, on an address you own, that no tool's session expiry can take away.

Stage 4: running it properly

Launch is not the end of the lifecycle. It is the start of the longest stage, and the one where hosting choices show their value. Running a site properly means a few specific capabilities are in place:

• Forms that go somewhere. The bakery's contact form has to deliver actual email, not simulate success. Static sites need a relay for this, and it should be part of the hosting rather than a third subscription.
• Analytics you can read. Page views and visitor counts, collected without bolting a tracking suite onto a two-page site, so the owner knows whether the ad in the local paper worked.
• Snapshots and rollback. Every deploy gets recorded, and any deploy can be restored. This is what makes AI-driven editing safe: when an enthusiastic revision breaks the menu page, recovery is one action, not an incident.
• Staging for changes that matter. Once the site has real traffic, updates can go to a staging copy first and be promoted when they look right, instead of being tested on customers.

And crucially, the loop closes. The same AI that built the site remains the way to change it: describe the edit, let the assistant apply it, deploy through the same hand-off as stage 2. The lifecycle is a cycle from here on, with stages 1, 2 and 4 repeating for as long as the site lives.

Where projects actually stall

Seen as a whole, the lifecycle explains the two places AI website projects die. The first is the exit from stage 1: endless revising with no decision to ship. The second is a stalled stage 2: the files exist, but the gap between the AI's environment and a real server never gets crossed because crossing it used to require skills the builder did not have. Automating the hand-off is what removed that wall, and it is the reason the category exists now rather than five years ago. If you are still weighing a platform that fuses building and hosting against one that separates them, the overview at AI hosting vs website builders compares the options; if your site already lives on a builder, switching from a website builder to AI hosting is the migration guide.

On AI-Hosted, powered by VibeDeploy from infrastructure in Belgium, all four stages after the build are the product: magic file and MCP hand-off, domains with automatic HTTPS, and forms, analytics, snapshots and staging as standard. Plans are flat at 15, 39 or 129 euro per month including VAT, detailed on the pricing page, and the 14-day free trial needs no card. Bring a prompt; leave with a site that is actually running.