Vibe Coding Tutorial: How to Ship a Working App in One Weekend

What vibe coding actually means

The term "vibe coding" was coined to describe working with AI coding agents in a high-velocity, low-ceremony way — describing what you want in plain language and letting the model figure out the implementation. The idea went viral because it feels like cheating: you describe a feature, the agent writes it, you review and ship.

The problem is that "just describe what you want" is incomplete advice. Unconstrained, the model will: invent dependencies you didn't ask for, refactor files it shouldn't touch, silently introduce bugs, and produce 400-line diffs that take longer to review than the feature would have taken to write. The "vibe" part is real — the speed is real — but it needs structure underneath it or you're not shipping, you're firefighting.

Good vibe coding is: high-trust prompting within a tight constraint system. You give the agent latitude on implementation; you lock in the boundaries. This guide shows you how to set that up and run a real project through it from zero to deployed URL.

The setup that makes it work

Before you write a single prompt, you need a rules file. Whether you call it CLAUDE.md, .cursorrules, or AGENTS.md depends on your tool — the content is the same either way. The rules file is how you encode the constraints once so you don't have to restate them in every prompt.

A minimum viable rules file for a weekend project contains four things:

• Stack declaration: language versions, framework, DB, package manager. If the agent thinks you're on npm and you're on pnpm, every install command it gives you will fail.
• File map: what lives where. src/lib/ for pure logic, src/app/ for routes, src/db/ for queries. The agent needs to know where to put things or it invents its own structure mid-project.
• Guardrails: things the agent must stop and surface before doing. New dependencies. Touching more than 4 files at once. Any change to auth, billing, or database schema. Without this one rule, you will spend Sunday untangling a Saturday mess.
• Definition of done: a checklist the agent must verify before declaring any task complete — tests pass, lint clean, diff minimal, no debug logs.

If writing this from scratch feels tedious, the free DEVKIT rules generator builds a complete CLAUDE.md + .cursorrules + AGENTS.md from your stack answers in about 60 seconds.

Start with a tight brief

The most important prompt you'll write is the first one. Before the agent touches a file, give it a brief that answers three questions:

1. What does it do? One sentence. "A web app where users paste a job description and get a tailored CV critique."
2. Who uses it? One sentence. "Solo job seekers, not recruiters."
3. What does success look like? The minimal thing that ships. "User pastes text, hits submit, sees five bullet-point critiques. No auth. No storage. Just that."

Write this down before you open Cursor or Claude Code. If you can't answer all three in three sentences, the project isn't scoped enough to build in a weekend. That's not a vibe coding problem — it's a product problem, and no amount of prompting fixes it.

Saturday: scaffold and first vertical slice

Saturday's job is to go from zero to one working feature, deployed somewhere with a URL.

Morning: scaffold

Give the agent your brief, your rules file, and a single instruction: "Scaffold the project. Create the directory structure, install dependencies, set up config. Do NOT implement any features yet. Show me a plan first."

Review the plan. Check that the structure matches your rules file. Approve it, then let it run. You should have a bootable project skeleton in under 10 minutes.

Push to Git immediately. This is your clean baseline. Every meaningful chunk of work should get a commit — not because you're being precious about history, but because "undo everything from the last hour" is a real command you will want to run.

Afternoon: first vertical slice

A vertical slice is one complete unit of user-facing functionality: UI + logic + persistence, all working together. Pick the one that is the heart of your app and implement it first.

Prompt pattern: "Implement [feature]. Only touch these files: [list them]. Run lint and tests when done. Show me a summary of the diff."

When it's done: run the app, click through it, verify it actually works. Then review the diff. Any file not on your list? Ask why it was touched. Any new dependency? Make sure it's intentional. Any test weakened or skipped? Reject the change.

Ship that slice to your deploy target (Vercel, Fly, Railway). Get a URL. Show it to someone. This is the most important moment in the whole project — making it real before you're done keeps you honest about whether it's working.

Sunday: finish, harden, ship

Sunday is for completing the remaining slices, then hardening before you call it shipped.

Remaining features

Work through your feature list one slice at a time. Same prompt pattern: specify files, run tests, review diff. Resist the urge to ask for multiple features in one prompt — the diff gets unreviable and the agent starts making assumptions you'll have to correct.

Hardening checklist

Before you ship publicly, run through this:

• Error states: what happens if the API call fails? If the user submits an empty form? Every happy path needs a sad path.
• Environment variables: nothing hardcoded that shouldn't be. No API keys in source.
• Basic input validation: you don't need Zod and a PhD — just reject obvious garbage at the boundary.
• Mobile: open it on your phone. Fix anything broken.
• One user test: send the URL to one person who isn't you. Watch them use it. You'll find the worst bugs in 3 minutes.

The actual ship

Deploy. Write two sentences about what it does and post the URL somewhere — a Discord, a Reddit thread, your own notes. The act of showing it to someone is what closes the loop. A project that's "almost done" and not deployed is not shipped; it's abandoned.

The 4 mistakes that kill weekend projects

1. Starting without a rules file

This is the most common mistake and the one with the most compounding damage. Without guardrails, the agent makes unconstrained decisions from the first file it touches. By Sunday afternoon you have a codebase where the agent invented its own conventions, installed three versions of the same library, and moved your config in two different directions. Spend 20 minutes on the rules file before you start anything else.

2. Implementing multiple features in one prompt

It feels faster. It isn't. A 400-line diff takes longer to review than two 200-line diffs, you can't roll back half of it, and bugs are harder to localize. Feature by feature, slice by slice.

3. Not running the app between commits

The agent reports done based on whether it believes the code is correct — not whether it actually runs. Run the app after every slice. If you go two hours without opening a browser, you're accumulating debt you'll pay on Sunday night.

4. Skipping the brief

Scope drift is the other project killer. "While we're at it, let's also add..." is how a weekend project becomes a six-month project. Write the brief, decide what's in scope, stick to it. Everything else goes on a list for next weekend.

3 habits of productive vibe coders

Commit at every meaningful checkpoint

You don't need a ceremony — just git add -A && git commit -m "slice: user auth". The ability to git reset --hard to a working state is worth more than any amount of careful prompting. The agent doesn't have undo; git does.

Ask for plans before implementations

Any time you're about to ask for something that touches more than 2-3 files, ask for a plan first. "Tell me which files you'd touch and why. Don't write any code yet." This catches wrong assumptions before they're in the codebase, and it takes 30 seconds. It saves hours.

Review diffs, not summaries

The agent's summary of what it did is optimistic. The diff is honest. Get in the habit of running git diff HEAD~1 or using the diff view in your editor after every agent task. You're not checking whether the feature works — you're checking whether the changes make sense and nothing unexpected was touched. This is the skill that separates devs who ship clean AI-assisted code from the ones who don't.

Vibe coding is genuinely fast. The ceiling — how much one person can ship in a weekend — has moved dramatically in the last two years. But the floor, how badly wrong a session can go without structure, has moved too. The workflow above is the structure. The speed is already built in.