Vibe Coding Tutorial: Idea to Live App

By the end of this tutorial you will have a small web app live on a public URL, built by describing it to an AI coding agent. The shortest path is six moves: write a one-paragraph idea, ask the agent for the smallest working version, open it in a browser, change it with short prompts, save each good state in git, and deploy the folder to Cloudflare Pages. Allow two hours. Facts checked 31 October 2026.

What you will have at the end

• A single-page "split the bill" calculator running in your browser
• A git history with a save point after each working change
• A free public URL on Cloudflare Pages
• A short checklist that catches the common vibe-coding mistakes
• A sense of where this method stops being safe

Vibe coding means building by describing, then judging by running. It is quick, and it hides risk. This guide keeps the speed and adds the few habits that matter. For the debate, see is vibe coding bad and vibe coding vs agentic coding.

Prerequisites

• A computer with a terminal, and a code editor or just a browser
• Claude Code installed and signed in. Our first-run guide takes twenty minutes. Any agent that edits files and runs commands works too.
• git, and Node.js with npm, which we use for the deploy tool
• A free Cloudflare account

Not sure which tool to use? See best vibe coding tools and Claude Code for vibe coding.

Step 1: Write the idea in one paragraph

A vague idea gives a vague app. Write four things.

1. Who it is for. "Friends splitting a restaurant bill."
2. What it does. "Enter the total, a tip percent and the number of people. Show what each person pays."
3. What it does not do. "No accounts, no saving, no server."
4. What done looks like. "Works on a phone, loads fast, one file if possible."

The last two matter most. Telling an agent what to leave out keeps the app small, which keeps it safe and easy to change. The Claude Code docs say the same thing from the other side: a specific prompt gives the agent information it cannot get from reading anything else.

Step 2: Make a folder and start the agent

mkdir splitbill && cd splitbill
git init
claude

If you want to see every action before it happens, start in Manual mode instead:

claude --permission-mode manual

New terminal sessions may start in a mode that approves routine actions on their own, so choose on purpose. For a first vibe-coding session on your own laptop, Manual is the better teacher.

Step 3: Ask for the smallest working version

Build a single-page web app in index.html with inline CSS and JavaScript, no libraries and no build step.

It is a bill splitter for friends at a restaurant. Inputs: bill total, tip percent (default 15), number of people (default 2). Output: tip amount, total with tip, and what each person pays, rounded to two decimals. It must work on a phone screen, with large tap targets and readable text. No accounts, no saving, no network calls.

Make the smallest version that works. Do not add features I did not ask for.

Then open the file in your browser:

open index.html        # macOS
xdg-open index.html    # Linux
start index.html       # Windows

Try it with numbers you can check by hand. A 100.00 bill, 20 percent tip and 4 people should give 30.00 each. If it does not, say exactly what you typed and what you saw. Paste a screenshot if you can. The docs note that you can paste an image of a design or an error straight into the prompt.

Step 4: Save the first good state

Do this now, before you change anything. A save point is what makes vibe coding safe to experiment with.

git add index.html
git commit -m "first working bill splitter"

From now on, commit after every change that works. If a later prompt breaks the app, you can get back to the last good state:

git checkout -- index.html

That discards uncommitted changes to the file, so only run it when you mean to. Claude Code also has /rewind, but its checkpoints only track files the agent edited with its own tools, so git is the real safety net.

Step 5: Change it with small prompts

One change per prompt. Run it. Commit it. Examples, in a sensible order:

Add a "round up each share" checkbox that rounds every person's share up to the next whole currency unit and shows the extra amount.

Make the design calmer: a light background, one accent colour, and a dark mode that follows the phone setting.

Handle bad input: negative numbers, empty fields and zero people should show a short message, never NaN or Infinity.

The third prompt is the one beginners skip. Agents build the happy path first, and the broken cases appear when a real person types something odd. Test them yourself: clear a field, type a letter, enter zero people.

When it goes wrong

The docs give a simple rule for steering a session. Watch the first minute, press Esc when the agent drifts, and after two failed corrections run /clear and write one better prompt instead of a third correction. A third correction mostly adds to a conversation that already holds two failed attempts.

If you are not sure what the agent just did, ask:

Explain what you changed in plain words, and show me the diff.

Step 6: Ask for a check, not a promise

An agent that says "it works" has told you its opinion. Ask for something you can see.

Write a small test page or a few assertions I can run that check these cases: 100 total, 20 percent tip, 4 people gives 30.00 each; zero people shows an error; an empty total shows an error. Tell me exactly how to run them and show the output.

The docs call this closing the loop: when the agent has a check that returns pass or fail, it can run the check, read the failure and fix it by itself. Without one, you become the test suite.

Step 7: Deploy to a public URL

Cloudflare Pages can host a static folder for free. The Direct Upload route uses the Wrangler command-line tool. You need npm, then:

npx wrangler login
npx wrangler pages project create

The create command asks for a project name and a production branch. The docs say subsequent deployments reuse both values, saved in a node_modules/.cache/wrangler folder. Put your site in its own folder, so you upload only what you mean to:

mkdir public
cp index.html public/
npx wrangler pages deploy public

Wrangler prints the URL when it finishes. Open it on your phone. That is a live app.

The Pages free plan limits that matter here, from Cloudflare's docs: 500 builds a month, up to 20,000 files per site, and 25 MiB per file. A direct upload of a single HTML file is far below all of them. The limits page describes the 500 builds a month in terms of pushing to a Git repository, and it does not say whether a direct upload counts. Custom domains are capped at 100 per project on the Free plan.

Never deploy the project root. It would include the .git folder, any .env file and anything else lying around. Deploy a dedicated folder like public/.

For other hosts and the full picture, read deploy a vibe-coded app and look at Render and Vercel pricing if you outgrow static hosting.

Step 8: The safety pass

Run this before you tell anyone the URL.

If the app grows accounts, payments or stored data, stop and read secure a vibe-coded app first. This is where vibe coding stops being a good idea without a reviewer. An agent will happily write a login system that looks right and has a hole in it.

Read the code you cannot write

You do not need to write JavaScript to review a page of it. A slow, structured read catches most of what goes wrong in a small app. Open index.html in an editor and look for five things.

1. Where does the number come from? Find the line that does the arithmetic. Check that it uses the inputs you expect, divides by the number of people and not by a fixed number, and rounds at the end rather than at every step. Ask the agent to point at the line if you cannot find it.
2. What happens on bad input? Look for a branch that stops when the people count is zero or the total is empty. If there is none, the third prompt in Step 5 has not landed.
3. What does it load from outside? Search for http. Every match is a request to a server you did not write. For a calculator the honest answer is none, or a font at most.
4. What does it remember? Search for localStorage, cookie and fetch. A bill splitter has no reason to use any of them. If one appears, ask why.
5. Is anything copied from somewhere else? If you see a licence comment or a large block you did not ask for, ask the agent where it came from.

Then ask the agent to explain the file back to you in plain words, one function at a time, and check the explanation against what you saw. Where the explanation and the code disagree, trust the code. This habit costs ten minutes and is the one that separates a hobby app from one you would let a stranger use.

Prompts that work, and prompts that backfire

Short, concrete, one change at a time. If you catch yourself writing a paragraph with three requests in it, split it into three prompts and commit between them.

Ship it again, and undo a bad deploy

Deploying is not a one-time act. Each change follows the same loop: edit, run it locally, commit, copy to public/, deploy. Two small habits make it safe.

First, keep the deploy step to one command. A shell alias or an npm script that copies the file and runs npx wrangler pages deploy public removes the chance of deploying from the wrong folder. Ask the agent to add the script and to explain it, then read it.

Second, know how to go back. Cloudflare keeps earlier deployments of a Pages project, so a bad release is not permanent. The dashboard lists them, and its documentation covers rolling back to a previous one. If you also keep git commits as save points, you can redeploy any earlier state by checking it out, copying it into public/ and deploying again.

To use your own domain, add it in the Pages project settings and follow the DNS steps the dashboard shows. Test the Pages URL first and the custom domain second, so a DNS delay is not mistaken for a broken app.

When to switch from a static page to a real app

A static page cannot store anything, call a paid API safely or log anyone in. The moment you want one of those, you need a server, and the risk changes. Use this as a rough guide.

The pattern in the table is that risk follows data. Anything the page stores, or any secret it holds, raises the cost of a mistake. A key placed in front-end code is public the moment you deploy, and a model will sometimes put one there if you ask it to "just make it work". When you reach that line, read secure a vibe-coded app, then find a person who reviews code.

Three small projects to try next

Repeat the loop on projects that are small enough to finish in an evening. Each one teaches a different habit.

• A unit converter. Teaches testing against known answers. Twelve inches is thirty point four eight centimetres, and you can check every result by hand.
• A habit tracker that saves in the browser. Teaches the difference between local storage and a server, and what clearing your browser does to your data.
• A one-page site for a real person or club. Teaches content, mobile layout and a custom domain, which matter more than code for most sites.

Keep every project under one hundred lines at first. When a file grows past what you can skim, ask the agent to split it, and notice that each split is a design decision you should understand.

What can go wrong

What it costs

The app itself can cost nothing: static hosting on Cloudflare Pages has a free plan, and the domain is optional. The agent is the main cost.

Claude Code needs a paid plan, a Console account or a cloud provider. From the pricing page, checked 31 October 2026: Pro at $17 a month billed annually ($20 monthly), Max at $100, Ultra at $200. The Free chat plan does not list Claude Code. A small app like this one uses a modest slice of a plan, though we have not measured it. Run /usage after the session to see where it went, and /clear between unrelated tasks to keep long sessions from costing more than they should. See Claude pricing and AI coding agent pricing compared.

Privacy

Everything you type to the agent, and every file it reads, goes to the model provider. For this tutorial that is a public calculator, so little is at stake. Do not paste customer data, client code under an NDA or real credentials into any vibe-coding session. On consumer Claude plans, whether your data may be used for training depends on a setting you control. On commercial and API terms, Anthropic says it does not train on code or prompts sent to Claude Code unless the customer opts in. Check the setting once, on purpose.

Checklist

• The idea says who, what, what not, and what done looks like
• First prompt asks for the smallest version, with no libraries
• Checked a result by hand against a known answer
• A git commit after every working change
• One change per prompt
• Bad-input cases tested by you
• A check or test that the agent ran, with output shown
• Deployed a dedicated folder, not the project root
• Searched the code for secrets and third-party scripts
• Opened the live URL on a phone
• A reviewer booked before adding accounts, payments or stored data

What this guide uses