Ship a site by vibe coding

What is vibe coding, exactly?

The term has a specific origin. Andrej Karpathy posted it in early February 2025, describing a way of working where you talk to a coding model, accept its changes without reading the diffs, paste error messages back in with no comment, and let the code grow past what you understand. In the same post he said it is "not too bad for throwaway weekend projects".

That is the fact. Here is my reading of it, marked as mine: the person who named the thing scoped it to weekend projects in the same breath, and almost everything built on top of the term since has quietly dropped that line. The term spread faster than the caveat did.

It is also worth saying what it is not. Using an AI to help you write code is not vibe coding. Reviewing every change and understanding what shipped is just development with a faster keyboard. Vibe coding, in the original sense, is the specific choice to stop reading.

The easy answer, and what it leaves out

Ask the internet how to do this and you get: describe your idea, the AI builds it, you click deploy, you are live. Beautiful. Fine.

What do you do on the Tuesday when the preview looks perfect and the deploy fails with a red error you have never seen? That is not an edge case, it is the middle of the normal path. The honest version of the promise is smaller and more useful: you can get a real page live without a dev setup, and you can keep it alive if you learn four specific things.

Three ways to vibe code a website

These are three different deals, not three brands. Pick by how much control you want to hold, not by which one is trending.

All three change every few months. Features move, limits move, pricing moves. Check the tool's own docs before committing, and treat any comparison (including this table) as a snapshot.

The workflow that actually works

1. 1Write the description before you open any tool. One paragraph, plain language: what the page is, who it is for, and the one thing you want a visitor to do.
2. 2Get one page working. Not a site. One page that renders, with your real words on it, on a phone sized screen.
3. 3Make one change. A single change, stated in one sentence.
4. 4Look at the result. Actually open the page. Do not take the model's word for it.
5. 5Commit. Then make the next change.

One change at a time is the entire difference between a site that ships and a session that collapses at one in the morning with forty files changed and no idea which change broke the build.

The reason is simple. Change one thing and look, and the cause of any break is always the last thing you did. Committing after each working step gives you a floor to fall back to, which makes the next risky request cheap instead of frightening. It is the same discipline that makes your first AI workflow survive contact with real work: small steps, visible output, a way back.

The prompt that gets you a good first page

Copy this, fill the brackets, and paste it into whichever of the three tools you picked. It is deliberately boring.

Build one page for [WHAT THE THING IS].
It is for [WHO IT IS FOR], who arrive from [WHERE THEY COME FROM].
The one action I want from them is [THE ONE ACTION].

Content, in this order:
- a headline that says what this is in plain words
- two or three lines of proof: [WHAT MAKES IT CREDIBLE]
- one call to action: [THE ONE ACTION]
- a footer with [CONTACT AND ANY LEGAL LINKS]

Constraints:
- Stack: [e.g. plain HTML and CSS, or Next.js with Tailwind]
- One page only. No extra routes, no database, no login.
- Mobile first. It has to read well on a phone.
- Use the copy I gave you. Do not invent testimonials, logos, client names, or numbers.
- No placeholder lorem ipsum. If you need copy I did not give you, ask me.

Show me the finished page, then stop. Do not add features I did not ask for.

Why each part is in there:

• What it is. Left vague, the model invents a product and you spend the first hour correcting its assumptions instead of building the page.
• Who it is for, and where they come from. Someone arriving from a WhatsApp link needs a different first screen than someone arriving from a search result. The model will not guess, and it will not ask.
• The one action. A page with three equal buttons has no action. Naming one forces the layout to make a decision.
• Content in this order. You are handing over an outline, not a wish. In my experience this is the biggest single quality difference in the first output.
• Constraints. The stack line stops it choosing something you cannot host. The one page line stops scope creep. The no invented testimonials line matters most: these tools fill empty space with plausible social proof, and you are the one publishing it.
• Then stop. The most common way a good first page goes wrong is that the tool keeps going and buries it.

Where vibe coding a website falls over

• The confident rewrite. You ask for a small change and it rewrites a component that was working, then reports that behaviour is unchanged. Sometimes that is true. This is the reason you commit before every request.
• Version drift. Models write for the framework version they have seen most often, which is often not the one installed. The symptom is code that looks correct and fails on an API that moved. Tell it your versions and point it at the installed docs.
• Dependencies you never chose. One casual request pulls in three packages. Each is now something you maintain, update, and are exposed to. Nobody decided this, it just accumulated.
• No tests, so nothing names the break. In a normal codebase a failing test tells you what went wrong. Here the only check is you looking at the page. That works for one page and stops working around page five.
• The deploy is nothing like the preview. A preview usually runs a dev server. Production runs a build, and a build does things a dev server does not: it type checks, it inlines values, it is strict about filename case, and it fails on the warning you ignored.

Secrets: the failure that actually costs you

Frontend frameworks deliberately expose some environment variables to the browser and mark them with a prefix. Next.js documents that a variable prefixed with NEXT_PUBLIC_ is inlined into the JavaScript bundle at build time and sent to the client. Vite's docs say the same about the VITE_ prefix, and add plainly that those variables should not contain sensitive information such as API keys. That prefix is a declaration you are making, not a protection you are receiving. An assistant asked to make a key reachable from a component will reasonably add it, and the key is then public to anyone who opens the network tab.

The second route is git. A key pasted into a file and committed stays in the history after you delete the line. GitHub's push protection is designed to block a push when it detects a secret, which is genuinely useful, but it is a net rather than a plan.

So the rule is short. Secrets live in your host's environment variable settings, never in the repo. Anything needing a secret key is called from a server route or serverless function, not the browser (Vite's own docs recommend exactly this). Anything already pasted somewhere questionable gets rotated, not hidden.

The small list of things you have to learn

Not "go learn to code". Four things, and they are finite.

1. 1Read an error message. The first line says what broke. The path and line number say where. The stack underneath is mostly not for you: you are scanning for the first line that names a file you recognise.
2. 2Know what a build is. Your source files are not what ships. A build turns them into what the browser downloads. If something works in preview and fails on deploy, the build log is the thing to read.
3. 3Know what an environment variable is. A value set outside your code, per environment, so the same code can point at different things and secrets stay out of the repo. The part to hold in your head is which of yours are public.
4. 4Use version control. Three moves is enough to start: see what changed, save a working state, go back to the last good one. That is the undo button for everything above.

That is the list. Four things, not a degree. If you want the wider version of this question, where to start with AI covers the same logic applied to tools rather than to code.

How do you get it live?

Mainstream hosts work roughly the same way, and the shape is worth knowing even when a builder does it for you. You connect a git repository, the host watches a branch, and when you push it runs a build command and publishes the contents of a build output directory. Cloudflare's Pages docs put it plainly: the build command comes from your framework, and the content of the output directory is what gets uploaded as your site. Branches other than production get preview deployments, which is how you look at a change before it is the real page.

A custom domain is a separate job and it is DNS, not code. You buy the name at a registrar, add it to the project on your host, and then point records at the host. Vercel's docs are a clear example of the general pattern: an apex domain like example.com is configured with an A record, a subdomain like docs.example.com with a CNAME, and both can instead be handled by moving the domain's nameservers to the host.

One warning from those same docs is worth repeating, because it is the one that stings. If you move nameservers, copy your existing DNS records over first, including the MX records for email. Otherwise your email quietly stops arriving, and you will spend a day not connecting that to the website you launched that morning.

Is it good enough for a real business site?

My honest line, and it is a line I draw rather than a rule I can prove: it depends on what sits behind the page. A static marketing page, a landing page, a portfolio, a one page offer with a contact form. Yes, with the checks in this article. That is most of what small businesses actually need, and the cost of getting it slightly wrong is an ugly form for a week.

Anything with logins, payments, or other people's personal data is a different category. The failure there is not an ugly form, it is a breach, and "the model said it was secure" is not a position you want to be in. I would still build the front of it this way, and have the parts that touch data reviewed by someone who reads code. If the site is meant to do work rather than sit there, that is a different build, closer to an agent that does real work.

What you actually end up with

Two things, and the second is the durable one. A real page at a real address, which is worth more than the perfect site you have been planning for eight months. And a small, specific skill: describe it, change one thing, look at it, commit. That loop is not about websites. It is how you work with any of these tools without handing over the steering wheel.

If the first version turns out to be wrong, the description, the prompt, and the loop all survive. You rewrite the page, not the skill. So the question to take to your own work is narrow: what is the one page you have been putting off because the setup felt like the hard part, and what is the single action you would want from whoever lands on it?