How to Start Vibe Coding: A Beginner Tutorial From Zero to a Live App

What vibe coding is (and what it isn’t)

Vibe coding means building software by describing what you want in plain language and letting an AI model write the code, while you steer by running the result and asking for changes. Andrej Karpathy coined the term in February 2025 for a style where you “fully give in to the vibes” and barely read the code (source: x.com). It spread fast enough that Collins Dictionary named it its 2025 word of the year (source: kvia.com), and Y Combinator said about a quarter of its Winter 2025 batch had codebases that were 95% AI-generated (source: techcrunch.com).

In practice there is a spectrum. At one end you never look at code and judge only what you see on screen, which is fine for prototypes and personal tools. At the other end, which Kitze calls “vibe engineering”, you still let the AI type but you plan, review and test like an engineer. Anything that stores other people’s data or takes their money needs to drift toward that second end. This guide starts you at the first and moves you along.

It works for real businesses. Sebastian Volkis built TrendFeed almost entirely with AI in about four days and made roughly $12K in its first month (source: indiehackers.com), and Pieter Levels prompted his way to a multiplayer flight simulator in 2025 (see vibe coding a game).

Step 1: Pick a first project you can finish

The most common beginner failure is not the tool, it is scope. Your first project should have one core action, at most three screens and one type of user. Good first builds: a habit tracker, a booking page for your own services, a calculator for your industry, a waitlist with a referral counter, an internal dashboard over a spreadsheet.

• Use it yourself. You will notice what is broken without writing test plans.
• Avoid payments, file uploads, real-time chat and multiple user roles in project one. Each is doable later; together they are where beginners stall.
• Check whether it has been done. Our Can I vibe code it? pages rate how hard common SaaS clones are, and vibe coding ideas lists products indie makers already sell.

Volume beats perfection early on. Jacob Teague started a public challenge in April 2026 to vibe code 100 apps and had 11 iOS apps live by October, most of them small single-purpose tools (source: 100apps.app). Dan Kulkov, who could not code when he started, is vibe coding a batch of small AI products toward a public $10K MRR goal (source: x.com).

Step 2: Choose a tool that matches who you are

There is no single best vibe coding tool, only the right one for your starting point. Pick by background, not by hype. You can switch later: most builders prototype in a browser tool, then move the code into an editor when the project gets serious.

Pricing changes monthly, so we keep current plans, limits and side-by-side reviews on the vibe coding tools page. Two examples of hybrid stacks: Prajwal Tomar, whose agency builds MVPs for non-technical founders, pairs Lovable and Cursor with Supabase, Vercel and CodeRabbit for code review (source: prajwaltomar.co), and Brian Shin lists Figma, Claude Code, Supabase and Vercel behind Once, an event camera app that reached about $35K/mo (2026-05) (source: x.com).

Step 3: Write a one-page spec before the first prompt

A spec is what separates vibe coding from slot-machine prompting. Ten minutes of writing saves hours of the AI guessing. Put it in a file called SPEC.md (or paste it as your first message in a browser tool) with: who it is for, the one problem it solves, every screen, what data you store, what is explicitly out of scope, and what “done” looks like.

Our vibe coding prompts guide has a full copyable PRD template. Then make your first prompt a planning prompt, not a build prompt:

Read SPEC.md. Do not write code yet.

1. Restate what we are building in 5 bullet points.
2. List every screen and every database table you think we need.
3. Propose the smallest version that works end to end (one user can sign up, do the core action, see the result).
4. Split that version into 5-8 build steps, each small enough to test on its own.
5. List anything in the spec that is unclear and ask me before you start.

Planning first is the same habit experienced builders use. Sebastian Volkis turned it into a product: CodeSpring exists to help non-technical founders map features and generate PRDs that coding agents build from (source: codespring.app).

Step 4: Build in small steps and save checkpoints

Work through the plan one step at a time. For each step:

1. Ask for one step only (“Build step 2: the sign-up page. Nothing else.”).
2. Run it and click through it yourself.
3. If it works, save a checkpoint: commit to Git in Cursor or Claude Code, or use the version history in Lovable, Bolt or Replit. This is your undo button when the next prompt breaks something.
4. If it does not, describe what you expected, what happened, and paste the exact error.

Three rules keep a beginner project healthy. Start a fresh chat when the AI starts repeating mistakes, because long conversations drift. Keep a short PROGRESS.md of what is done and what is next so a new chat can pick up. And give the agent standing rules in a project file (CLAUDE.md, AGENTS.md or Cursor rules). Tony Dinh did exactly that while vibe coding a browser game after the AI let one file grow past 3,000 lines: his rules file caps files at 500 lines and bans needless comments (source: news.tonydinh.com).

Step 5: Test it like a stranger would

AI-written code usually works on the happy path and breaks at the edges. Before you show anyone, try to break it: sign up twice with the same email, submit empty forms, paste a 5,000-character name, use it on your phone, log out and press the back button, open it in a private window.

When something breaks, ask the AI to explain the cause before it fixes anything. A fix without an explanation often patches the symptom and creates a new bug elsewhere. If you know a little code, ask it to write a few automated tests for the core action so future prompts cannot silently break it.

Then put it in front of one or two real people. Brian Shin tested a rough web version of Once at a friend’s party, and lined up commitments from potential hosts, before building the full app (source: onbo-hub.com).

Step 6: Lock down the basics before real users

This is the step beginners skip and regret. AI tools will happily ship an app where anyone can read the whole database. A 2025 scan of 1,645 apps from one popular builder’s showcase found 170 with databases exposed to the public (source: superblocks.com), and Alex Slater’s QUITTR, one of the best-known vibe-coded app successes, had a misconfigured database reported by 404 Media in 2026; the team said it fixed the issue and added safeguards (source: 404media.co).

The minimum before launch:

• Row-level security turned on for every table, so users can only read and change their own rows.
• No secret keys in front-end code; they live in server-side environment variables.
• Every page and API route that shows private data checks the user is logged in.
• Spending limits on every paid API (OpenAI, Anthropic, email, SMS).

The full checklist, with prompts to audit your own app, is in vibe coding security.

Step 7: Deploy to a real URL

Browser tools (Lovable, Bolt, Replit, Base44, v0) have a publish button that gives you a live URL in seconds. Connect a custom domain from the same settings screen; it costs about the price of the domain and makes the app look real. If you built in Cursor or Claude Code, push the code to GitHub and import the repo into Vercel, Netlify or Render, which redeploy every time you push.

• Copy your environment variables (database URL, API keys) into the host’s settings; they do not travel with the code.
• Use separate keys for development and production.
• Add simple analytics and error tracking on day one so you know if anyone uses it and what breaks.

Step 8: Get your first users

Shipping is half the job. The makers who turn vibe-coded apps into income treat distribution as part of the build. QUITTR’s Product Hunt launch flopped, so its founders went to the Reddit community their users already lived in, then paid creators to post about it; $3,000 of promotions returned about $35,000 in sales (sources: boringcashcow.com, nymag.com). Rob Hallam grew SuperX through his own posts on X to $22K MRR (SuperX, verified) (2026-10) (source: trustmrr.com).

• Launch platforms and directories: our where to launch list has 80 options with pricing and backlink details.
• Communities: post where your users already talk, as a member first. See indie maker communities.
• Build in public: short posts on X, LinkedIn or TikTok showing what you built and why.
• Search: pages that answer what your users search for keep bringing visitors after launch week ends. You can write them yourself with Google Search Console and a keyword tool, or automate them.

Want proof that this path works? Browse apps built with AI and the revenue pages of makers who share their numbers.