So you want to vibe?
Everything I learned from building Wanderlist turned into a vibe coding guide for friends who want to build their first app with AI.

YOU'VE COME TO THE RIGHT PLACE. Welcome to this vibe coding guide I made for my friends who want to build their first app with AI.
This is everything I learned from building Wanderlist (yeah, shameless plug). The first thing that I think is important to hear is this: you don't need a computer science degree to build something sick. You need an idea, a little patience, and a willingness to think like a product manager more than an engineer. AI will write your code for you, so your job is to know what you want, to be able to articulate it clearly, and to break it into pieces small enough so that your AI can bring it to life efficiently for you.
I'd recommend reading sections 1-3 in full before you get started. The rest of the sections will only be relevant depending on your idea. When you're really ready to go, check out the Quickstart checklist.
GOOD LUCK, AND LET'S VIBE. 🕺
1. Pick the method for your madness
There are two reasonable ways to start, and the right one depends on how comfortable you are in a code editor.
The all-in-one path (Replit, Lovable, Bolt). These tools are awesome and handle the annoying data work for you — hosting, databases, login, deploys — so you can stay focused on building. You can just use their built-in agents to chat normally as you would in GPT or Claude to build what you want. This is the best place to start if you've never touched a code editor. My friend, Téa, built her whole app using Lovable and never had to think about servers once (check out Group Review on THE APP STORE!).
The code editor path (Cursor or Claude Code). You work in a real editor with AI built in, and you configure the supporting services yourself (database, hosting, etc.). There are definitely more moving parts, but you get full control, you can see your files change in your repo easily, you can take the project anywhere, and you learn a TON about how all of these pieces fit together. I went this route for Wanderlist because I was already comfortable in VS Code and wanted to manage my own data and manually edit lines in my repo.
2. Start with exploring your idea in a REGULAR chat, then craft your first prompt for your chosen vibe coding tool
I cannot stress this enough: do not start with your vibe coding tool JUST YET. Treat this like a research project in school - do the actual research, outline your idea/general structure, and then start writing your first draft.
In this case it should look something like this: open a regular chat with Claude (or ChatGPT) and talk through your idea before you generate a single line of code. Not to #scareyou or anything, but the quality of your whole project stems from the quality of that first prompt. So you wanna make it good…
HOWEVER, remember that AI knows how to best communicate with AI, so I'm not asking you to handwrite this entire prompt. In your regular chat, describe what you're trying to make, who it's for, and what the very first version should do. Tell chat you want to create a really good first prompt to start your vibe coding project. Also tell it to ask you clarifying questions so that you can work together on this (see, people CAN be friends with AI!!). Example starting point to start researching:
i want to build a travel app where i can save places i want to visit in a city on a map and categorize them, add notes so i can share my city guides with other people. i'd like to vibe code this app so help me craft an initial prompt for claude code to begin working on my project. ask me clarifying questions about what i'm trying to build so we can come up with the best initial prompt possible.
Once you go through this research stage with your regular LLM, you can decide when you feel good about the initial prompt to get started in your vibe coding tool. A good initial prompt usually includes:
- What the app is, in one sentence ("a travel app where I can save places I want to visit on a map and categorize them").
- The core thing it should do on day one (not every feature).
- The tech stack, if you have a preference (I asked for React + TypeScript so it'd be easy to turn into a mobile app later - if you don't know what that means that's OK).
Aim for a first version that does one thing end to end. Once it's built, you can ask your AI to help you run it on localhost so you can see your changes in realtime.
3. Build one feature at a time (the most important habit)
Here's one thing I absolutely learned the hard way: do not try to prompt all your features at once. It feels faster, but it is always slower. AI does WAY better work when each prompt has one clear job.
Now that you've done your research in a simple chat, picked your vibe coding tool and submitted your beautiful initial prompt, you're ready to get working. From here on out, you'll be building with your vibe coding tool (so when I say chat now I mean sessions in Lovable, Cursor, Claude Code etc.). A few things to keep in mind:
- One feature per prompt. Get it working, click around, confirm it's solid, then move on.
- Start a fresh chat for each new large feature set. Long chats get cluttered and the AI starts losing the thread. A clean chat with focused context produces better code.
Be a PM for your own project. Keep a running list of every bug and feature idea as it occurs to you. Categorize them (in wanderlist it was something like collaboration, trips, guides, styling etc.) and tackle them one at a time instead of firing off whatever's top of mind. We don't need to go crazy here - I did this in notes app.
- Save the pretty stuff for last. It's soooo tempting to get nitpicky over colors, spacing, and animations early, but aesthetic tweaks touch a lot of files and make backend changes harder and messier. Get the function right first, polish the look at the end.
- Of course, aesthetics are fun so feel free to reward yourself with styling changes every once in a while, but as a general rule, for every big feature, get it working, and then style.
4. Store your data: how your app remembers things
Almost any real app needs to store data - for Wanderlist this was saved places, user accounts, lists. If you don't store data and you're developing locally, you'll lose anything you've done in the app when you refresh the page which would be very sad… This is the "backend," and it's where beginners get the most intimidated. Don't be!!!!
On the all-in-one path, this is mostly handled for you. Replit and Lovable will set up a database and connect it automatically. You can often just say "save these to a database" and it does the right thing. So no stress at all.
On the code-editor path, you'll wire up a database yourself. I used Supabase, which is free, gives you a real database with a friendly dashboard, plus login/auth out of the box. I found it pretty easy because I'm comfortable with SQL, but even if you're not, you can ask AI to write the queries you need and explain them.
5. Protect your API keys
If your app uses an outside service (maps, payments, email, anything) you'll get an API key, which is basically a password that proves the request is coming from you.
Two things to remember:
- Never paste keys directly into your code. Put them in environment variables (a
.envfile) and make sure that file is in your.gitignoreso it never gets committed to GitHub. The all-in-one tools have a "secrets" panel that does this for you.- Also if this is confusing at all, you can always ask your LLM to explain it to you. Sometimes I'll literally say "I don't get this explain to me why I have to protect my API keys."
- Restrict where each key can be used if you can. For Wanderlist, I went into the Google Cloud API Console and locked my Maps key down to my own domains, so that even if someone found it, they couldn't rack up charges using it elsewhere.
This may seem extra, but it's important if you don't want to get a surprise bill.
6. Get it on the internet (and preview every version)
Seeing your app live (not just on localhost) is motivating and makes testing more accurate, especially if you're building something for mobile.
On the all-in-one path, publishing is a button. They handle deployment for you and you can test in your web browser on mobile, so you don't need to worry about this one.
On the code-editor path, I used Vercel (yes, even though they had that data breach…). Vercel gives every branch its own live preview URL, so you can try out a half-finished feature as a real working website without breaking your main version. This was a lifesaver for me because Wanderlist is mobile-first. I could pull up any branch's preview on my actual phone in the browser and see exactly how it felt, instead of using dev tools in my desktop window trying to simulate a phone.
The general workflow: build a feature on its own branch → push it → open the preview link on your phone → only merge it into your main app once it feels right.
7. Turn your web app into an iOS app
Once your web app is solid, turning it into a real iPhone app is surprisingly approachable. I used Capacitor, which takes your existing web app and packages it as a native app. You can ask the AI to set this up and walk you through it (I didn't know any of this before I asked):
Help me turn my web app into an iOS app with Capacitor. Tell me how to test it on my phone.
What's going to happen is (and ask your chat to explain this to you) it will create the wrapper for you, you'll sync and open the project in Xcode, and from there you'll be able to build the app directly to your home screen on your phone. You'll need to turn on some development controls on your phone in settings to allow this to happen.
Two (slightly annoying) things:
- You'll have to use Xcode (Apple's code editor for building iOS apps), and it is... not fun. Definitely be patient and paste errors straight into your chat to decode them.
- Expect to make some iOS-specific tweaks. Things that work fine in a browser (the keyboard covering an input, scrolling behavior, safe areas around the notch, tap vs. click) often need small adjustments to feel right on a phone. Tell AI "make this iOS-friendly" and describe what feels off, and it'll usually know how to fix it.
8. A few survival tips
- When something breaks, paste the exact error. Don't paraphrase - the full error message is the most helpful for AI to understand.
- Commit often. Save working versions (in Git, or just by duplicating the project or making branches in the all-in-one tools) so you always have a saved version to roll back to if an experiment goes sideways.
- If the AI goes in circles, stop. This is the hardest thing to do, but you're literally going to go crazy if you keep hammering it in. If you find yourself spending 4 hours trying to fix something that is super simple, start a fresh chat and re-explain the problem from scratch. A clean slate weirdly can fix what twenty follow-up messages can't.
- Ask the AI to explain, not just fix. "Why did that work?" is how you slowly stop being dependent on it for everything and you get better at prompting overtime.
Quickstart checklist
- Talk through your idea with Claude/ChatGPT and craft a strong first prompt.
- Pick your path: A) all-in-one (Replit/Lovable) or B) code editor (Cursor/VS Code).
- if A, these tools will walk you through step by step. Use the prompt you've crafted in regular chat to create your foundation and tweak from there! HAVE FUN!!
- if B, use the prompt you've crafted in regular chat to create your foundation.
- Run locally: you'll need to ask it how to spin up your repo locally (usually
npm run devor something of the sort if you're building React + TS) - this will create alocalhostserver that will open in your browser so you can see your changes live. - Git setup: Create a GitHub repo for your project. Do this now so you can easily branch and manage your version history.
- HAVE FUN!!
- Run locally: you'll need to ask it how to spin up your repo locally (usually
- Decide if you need:
You'll figure out a lot of this by just trying it, and that's the whole point!! It is so fun to learn as you go. The goal isn't to memorize this guide, but hopefully it helps you feel more confident to get started. I CANNOT WAIT TO SEE WHAT YOU CREATE!!!
Also, I am obviously down to be a beta tester always and am here if you have any questions along the way… and please share any tips you have as you work, so I can add them to this guide. 😇
xoxo Syd