1,000 hours of vibecoding: everything I learned, start to finish
The whole path from app idea to paying users, in order. The PRD, the plan, the build loop, the hacked and sued audits, deploying, and marketing, with every prompt ready to copy and every tool linked.
I've spent over 1,000 hours vibecoding. This is everything I learned, in the order you'll need it, so you don't have to learn it the slow way. Every prompt is below with a copy button, and every tool is linked.
What you need before you start
- Claude CodeThe AI that writes the code. It needs a paid Claude plan, and Pro is enough to start.
- How to set up Claude CodeMy ten minute setup, with the plugins worth installing.
- GitHubWhere your code lives. Make a free account now, you'll need it in step 5.
Step 1: Get the idea out of your head
Open Claude Code, turn voice mode on, and explain your entire app idea in as much detail as you can. Who it's for, what it does, what every screen looks like, and why someone would pick it over what already exists. Talking gets a lot more detail out of you than typing does.
When you're done talking, paste this:
That's my whole app idea. Before you write anything, ask me every question you need answered to build it.
Then write two files:
1. PRD.md: a concise product requirements doc. What the app does, who it's for, the core features for v1, what's out of scope, and how we'll know it works.
2. CLAUDE.md: the project summary, the stack, the commands, and the always and never rules you'll follow every session. Tell yourself to read PRD.md before starting any work.Make a new folder for the project and put both files in it. Everything after this runs on those two files. If you want Claude to remember where it left off between sessions too, add the other three docs from this guide:
Step 2: Plan the whole build
Switch to the best model you have with /model, then type /plan (or press Shift+Tab until it says plan mode) and paste this. The plan decides how the rest of the build goes, so this is where the smartest model is worth it.
Plan the entire build of this app from PRD.md and CLAUDE.md. Break it into phases small enough to build and test one at a time. For each phase, list the files it touches, what done looks like, and how you'll test it. Flag anything in the PRD that's unclear or risky. Don't write any code until I approve the plan.Actually read the plan before you approve it. If a phase looks too big, tell it to split that phase in two. If it picked a tool you don't want, say so now. Swapping a tool out halfway through the build is a lot more work.
Step 3: Build it in a loop
Now start coding with loop engineering. Claude builds one phase, checks its own work, fixes whatever broke, and only moves on once it passes. That stops it from stacking ten features on top of a bug it never noticed.
Build the next phase of the plan. When you think it's done, check your own work: run the app, run the tests, and compare the result against what done looks like for this phase. If anything fails, fix it and check again. Keep looping until it all passes, then tell me exactly what you checked and what's left.- Paste it once per phase until the whole plan is done.
- Start each phase in a fresh session with /clear, so the model isn't dragging the last phase around in its memory.
- Actually open the app and click around after every phase. Tests passing doesn't mean it works the way you pictured it.
- Commit to GitHub after every phase that passes, so you can always roll back to the last version that worked.
Step 4: Audit it so you don't get hacked or sued
Once it's done building, we need to work on security. The first prompt hunts for the holes that get you hacked. The second hunts for the things that get you sued or taken down. Run them one at a time and fix every CRITICAL before you touch anything else.
Audit this codebase like someone trying to hack it. Check every item below. For each one: PASS, FAIL, or CAN'T TELL. For every FAIL, cite the file and line, rate it CRITICAL, HIGH, or LOW, and give me the fix. Report first. Don't change anything yet.
HACKED
1. Secrets: hardcoded keys, a committed .env, keys in git history or the frontend bundle
2. Auth: routes with no session check, permission checks only in the frontend, user IDs trusted from the request, tokens in localStorage, no email verification or password rules
3. Database: tables with RLS off, policies that let user A read user B's rows, IDs with no ownership check, updates that save the whole request body
4. Input: SQL built from strings, user content rendered as raw HTML, no server-side validation, unchecked file uploads
5. Exposure: no rate limits on login or AI routes, unsigned webhooks, CORS set to *, open /admin or debug routes, stack traces in production, outdated dependencies
Then rank the fails by how likely each one is to hurt me, and give me the fix order.Audit this codebase like someone looking to sue me. Check every item below. For each one: PASS, FAIL, or CAN'T TELL. For every FAIL, cite the file and line, rate it CRITICAL, HIGH, or LOW, and give me the fix. Report first. Don't change anything yet.
SUED
1. Privacy: a missing or incomplete privacy policy (data collected, AI use, third parties), pixels or trackers firing before consent, a cookie banner with no reject, health data sent to analytics, face ID with no consent, unencrypted personal data, public storage buckets, deleted uploads still stored
2. Content: unlicensed images, no report button or takedown route, no DMCA agent, no age gate, missing alt text
3. Sales: fake testimonials or fake urgency, cancelling harder than signing up, trials that charge with no reminder, texts without opt-in, emails with no unsubscribe, pricing based on user data with no label
4. AI: unproven "AI-powered" claims, AI output with no label, a chatbot with no self-harm response, acting as a therapist, or quoting prices and policies on its own
Then rank the fails by how likely each one is to hurt me, and give me the fix order.Run both again after every big feature, because new code ships new holes. Each item comes from one of these, if you want the full breakdown:
- 20 security holes in your vibe-coded appWhat each hole costs you and the fix.
- 5 security prompts for vibecodersDeeper audits, one per attack surface.
- 10 ways to get your app sued or taken downPrivacy policies, public buckets, fake reviews, dark patterns.
- 10 ways your app is breaking the lawCookie banners, AI labels, takedown rules.
- 10 more ways your app is getting suedTexts, emails, age gates, accessibility.
Shipping to the App Store or Google Play? They have their own rules on top of the law. Have Claude check your app against these before you submit:
- App Store Review GuidelinesApple's rules. Check account deletion, in-app payments and user content before you submit.
- Google Play policiesGoogle's version, including the data safety form.
Step 5: Deploy it
Push your code to GitHub, then connect it to a host. After that, every push goes live on its own. You need one host, one backend, and Stripe for payments:
- VercelHosting. The easiest option if your app is built with Next.js.
- NetlifyHosting. Same idea, works well for most frontend frameworks.
- Cloudflare PagesHosting. Also has a free tier.
- SupabaseBackend. A Postgres database, logins and file storage in one place.
- FirebaseBackend. Google's version, common for mobile apps.
- StripePayments. Build it in test mode, then switch to live.
Then paste this and let Claude walk you through the setup:
Get this app ready to deploy. I'm using [Vercel / Netlify / Cloudflare] for hosting, [Supabase / Firebase] for the backend, and Stripe for payments.
1. List every environment variable the app needs, what it's for, and exactly where I get each one.
2. Make sure no secret key is in the code or the frontend bundle.
3. Set up the database tables and security rules from our schema, with row level security on for every table.
4. Connect Stripe in test mode first, with a webhook that checks the signature.
5. Walk me through every click I need to make in each dashboard, one step at a time.- 3 Stripe mistakes that almost got my account bannedRead before you go live.
- 20 things to do before you launch your appThe launch checklist.
Step 6: Market it
Film the process of building it and post every day. People follow a build a lot more than they follow a finished product. When it's live, get it in front of as many people as you can:
- Product HuntLaunch day. Line up people to check it out on the day, not the week after.
- r/SideProjectBuilt for exactly this. Then find the subreddits where your users hang out, and read each one's self-promo rules first.
- 5 prompts to scale an app from $0 to $10k a monthThe funnel math, ASO keywords and marketing material.
Post the same clips to Instagram, TikTok and YouTube Shorts: the build, the app working, and what broke along the way. Do whatever you can to get eyes on your app.
