The deployment gap: why vibe coding stops when the code is done

Vibe coding solved the part everybody talks about. The agent builds the site, you read it, you ask for one more change, and it is done. Then the conversation ends and nothing else happens. The files sit in a folder on your machine, and there is no next prompt that makes them public.

That is the deployment gap: everything between a finished site and a site that somebody else can open. It has four walls. The site has no address. The address is not your name. The form on the page does not go anywhere. And nothing on the page can take money.

None of the four is a coding problem. Which is exactly why the tool that wrote the code cannot get you past them.

What the deployment gap actually is

Two things happened in the last few years, and only one of them is finished. Artificial intelligence made building a site something you can do by describing it. Nothing changed about what happens after.

So there are now two separate events where people assume there is one. The agent finishing is an event. The site being live is a different event. Between them sits a set of steps that nobody in your conversation is responsible for, that have nothing to do with the quality of what was built, and that will not be mentioned unless you go looking.

The gap is not one obstacle, which is part of why it is so hard to describe. It is several unrelated ones in a row, ranging from a five-minute job to a decision about who is legally on the hook, and none of them resembles the work you were just doing. You were describing a headline. Now you are being asked to pick a runtime. The mismatch is sharper than it sounds, because most of the people building this way are not developers, and picking a runtime was never going to be one of their skills.

It is also not about code quality. The code is fine. The code was never the thing standing between you and a link.

The four walls

Four is the whole list, in the order people hit them. What follows is the map, not the route: each wall has a page of its own, and this is not it.

The site has no address

The first wall is the quietest, because it does not announce itself. The site works. You can open it. Double-click index.html and there it is, headline, images, the lot.

Then someone asks you to send the link, and there is no link. file:///Users/you/… is not an address; it is a path on one computer. A preview pane inside a chat is not an address either. It is a window into a session that only you are in. The site exists, but only where you are standing. What it actually takes to move it somewhere else is a short and specific answer, and if the thing you built lives inside a Claude artifact, that is the same wall one layer up.

The address is not your name

Get past the first wall and you have a URL. Look at it. Somebody else's brand is in front of your project name.

This reads as cosmetic and is not. An address you do not control is an address you cannot keep: you cannot hand it to a client as theirs, you cannot put it on a card, and you cannot take it with you when the platform underneath changes its mind about pricing or shuts down. Pointing your own name at the site is one DNS record — genuinely one — but it is a record in a registry, on somebody's account, tied to a payment method, and that is a different kind of object than a file.

The form does not go anywhere

Ask any agent for a contact form and you will have one in about four seconds. It will look right. It will validate the email field. It will show a thank-you message.

It will not deliver anything to you, because there is nobody behind it. A page served as a static file is exactly that — a file handed to a browser. When a visitor presses Send, the browser needs a service on the other end to receive, store, and forward that submission, and a folder of finished files does not contain one on its own. This is a property of the format, not a bug in what your agent wrote, and it holds on every static host there is, unless the host itself is that service standing behind the page.

Nothing on the page can take money

The same mechanic, with the stakes an order of magnitude higher. A Buy button is a link and some styling; taking money is an account, an identity check, a processor, a record of what was sold, and someone answerable when a charge is disputed.

You can paste a hosted payment link onto a page and it will work in the narrow sense that money moves. What you will not have is any of the part that comes after — knowing what was bought, delivering it, refunding it, or proving any of it happened. That is not a page you are shipping. It is a page with a hole in it.

It is one wall, not four

Here is the claim I will defend: those are not four problems. They are one boundary, seen from four sides.

An agent can do anything that can be done with files. It reads them, writes them, renames them, restructures them, and it is better at that than most people are. Every one of the four walls sits at the exact point where files stop and something else begins, and that something else is always the same thing.

A domain is a name in a registry, held by an account, on somebody's identity, paid for with somebody's card. A form receiving submissions means a stranger's personal data is now sitting somewhere, and someone is responsible for it. Taking money means there is a recipient, and a jurisdiction, and a dispute process. Even the plain address is a rented place on somebody's machine.

None of that is code. All of it is accountability — the point at which the work stops being a description of a page and starts being a commitment made in someone's name. Your agent does not have a name to make commitments in. It should not have one. The boundary is not a limitation of the current models, and a better model next year will not move it.

The walls also do not add up; they multiply. Clearing three of four gets you a site nobody can find, or a beautiful page with a form that silently swallows every enquiry. Any one of them still standing stops the whole thing, which is why "almost live" is a state so many projects sit in permanently.

That is a different argument from the one about why publishing got expensive in the first place, which is about a price set for applications and never re-examined for documents, and it is worth reading separately.

"Deployment gap" already means something else

Before using a term, it is worth checking who else is using it. So in August 2026 we ran deployment gap through Google and went through all 28 results on the first pages, one at a time.

Not one was about a person with a finished website.

Seventeen were about enterprise AI: pilots that never reach production, the distance between an AI budget and an AI system. Five were about machine learning specifically — the model that works in the notebook and falls over in production. Three were about robotics, including a16z on the gap between robotics research and robots that actually do jobs. One was an arXiv paper on AI regulation. One was about provisioning environments for developer teams. Google offered no "people also ask" questions at all, which usually means there is no settled public version of the question yet.

The term has been in that sense for a while: deeplearning.ai's The Batch ran a piece headlined Deployment Gap in December 2019, about companies that had bought machine learning and could not ship it. That is a real problem and those are its rightful owners. We are not arguing with them.

The point is narrower, and it is the reason this page exists. The version of the problem that stops one person with one finished site did not have a name at all. The closest anyone comes is Sydney Butler at How-To Geek, who describes people who "might have a working AI-coded app, but no idea how to deploy it to a server," and lists what they are expected to learn: "how to configure a web server, set up its security, register and connect a domain." That is one and a half of the four walls, and it is the most complete account we found.

Which walls have doors today

Now the uncomfortable half, since a page that names a problem and then claims to have solved all of it is not worth reading.

Three out of four. That is the honest state of this product in August 2026, and it is why the last wall gets the least room here rather than the most.

Where we do have a door, the shape of it matters more than the fact of it. The agent that already holds your files is the one that publishes them, so publishing is a sentence in the conversation you were already having rather than a context switch into a hosting dashboard. The last ten published versions are kept, so a change that turns out wrong is reversible instead of rebuildable. Images and fonts travel with the site; video and PDFs do not, and still need a public URL of their own. And it is static sites only. If your project owns a database, server-side code, private keys, or scheduled work, this is the wrong layer entirely and it deserves the decision made properly before anything gets published.

Where each wall is answered

If you are standing at a specific wall rather than reading about all four, go straight there. The mechanics of the first one — what counts as "the page," why the file is called index.html, what travels with it — are written up in how to host an HTML file. The second is one record and a wait, including why verification keeps failing. If your site currently lives inside a chat, the artifact case has its own page. And the connection that lets an agent do any of this at all is an open standard your tool probably already speaks.

Wall three has its own page now too: what a working contact form actually needs, the real contract behind it, not the four-second version an agent hands you by default. For wall four, the honest answer is the one above: not from us, not yet, and be careful of anyone who tells you it is a five-minute job.

Frequently asked questions