Start Today: A Creative's Toolkit for Vibe Coding
What I actually use, and what you'll need to start shipping.
I keep getting a version of the same DM. “I want to start building stuff. I don’t know where to begin.”
Here’s the map I used. Not a comprehensive one, but one to get you building TODAY. These are the tools and the moves I used to ship two products in 60 days, having never written a line of code before this year.
Buckle up. Grab a White Monster. This is a long one, but it’s worth it.
Start with a brief
Before Claude Code does anything, you need to know what you’re making.
I don’t mean a feature list. I mean a brief, a strategy, an insight. At the very least concept. Sundree started as a fleeting idea as I was falling asleep one night, and a quick note in my notes app.
Claude Code isn’t a magic button. Without a solid foundation, Code will just create more slop.
Spend an afternoon in Figma or a notes app or a Pinterest board. Pick three reference brands. Pick a name. Pick two fonts and four colors. Write down the one feeling the product should give someone in the first three seconds. Then, and only then, open Claude Code.
The brief is the part of the work that puts you in the driver’s seat. Don’t let Claude Code direct you, you direct Code.
Where to write the code
VS Code
You can technically use Claude Code without ever opening VS Code. You shouldn’t. Not if you want to actually get more comfortable with coding languages and the process of building and debugging.
VS Code is a code editor, you can download for free here. This tool is incredible because it has the option to install Claude Code directly into the app. Here you can both chat with Code, AND see the files Claude is writing. You watch them update in real time, and start to absorb what’s going on.
The terminal is intimidating at first. I avoided it for a long time. It’s the difference between being a tourist in your project and actually living there.
You don’t need to become a terminal wizard. You need to stop being afraid of it. Having Claude Code right there with you is a game-changer.
Claude Code
Type your ideas, updates, features, and feedback in plain English. It writes the code, runs it, fixes it when it breaks. I built Resolut using Claude Code in VS in under ten days.
One thing nobody warns you about: get on Pro at minimum. Anthropic just upped its usage limits this week, but upgrade to Max if you can swing it. The free tier will rate-limit you mid-build, and there’s nothing worse than getting throttled when you’re three hours into something that’s almost working. Pro and Max share usage between Claude Code and the chat at claude.ai, so you’re paying for one subscription and getting two surfaces. Treat it like the cost of a tool that does part of your job, because it is.
Two Claudes are better than one
This is the move that changed everything for me. Run two Claudes at once.
Claude Code is in your terminal, doing the actual building. The chat at claude.ai is where I think.
Before I send a serious prompt to Claude Code, I draft it in chat first. I describe what I want to build, what could go wrong, what edge cases I’m worried about. I let chat pressure-test the approach, poke holes in my logic, suggest a cleaner architecture. Then I take the refined prompt back to Claude Code and run it.
When something breaks, I paste the error into chat and ask what’s actually going on before I let Claude Code start patching things. Half the time chat spots the real issue while Claude Code would’ve slapped a band-aid on the symptom.
Same model. Different jobs. Claude Code is heads-down building. Claude chat is heads-up advising. The two of them together are sharper than either one alone, and you’ll burn fewer tokens because you’re not letting Claude Code thrash through five wrong solutions before finding the right one.
Feedback: Use your words
The skill that translated most directly from my fifteen years as a creative was giving feedback.
When I tell Claude Code “make this look better,” I get garbage. When I tell it “the spacing on this card is too tight, bump the vertical rhythm, the headline and subhead are too close in weight, the headline should be heavier and the subhead lighter, and the whole thing should feel closer to Linear and further from a generic SaaS template,” I get something close to what I wanted on the first pass.
You’re not casting spells. You’re directing a partner who’s fast, eager, and has read every textbook but has never had a senior look over their shoulder. Treat it that way. Use real design language: hierarchy, rhythm, contrast, density, and tension. Point at references. Tell it what’s wrong and what good would look like.
The same is true for the chat side. The more precisely you brief, the better the output. Vague feedback gets vague work, from a person or a model.
If you’ve ever critiqued a designer’s work, you already know how to do this. If you haven’t, start learning the vocabulary now. Specific, direct, constructive. It’s the highest-leverage skill in vibe coding, and almost nobody talks about it.
Code isn’t magic
The part nobody romanticizing AI coding tells you: it doesn’t work the first time. Or the second. Sometimes not the tenth. I’m currently on version 50 of Sundree, including bug fixes and feature updates.
You’ll ask Claude Code to fix one thing and it’ll break another. You’ll ship a feature that worked locally and watch it die in production. You’ll spend two hours chasing an error that turned out to be a missing semicolon. This isn’t the model failing you. This is what software has always been.
The authentication flow on Sundree alone took days. Sign in with Apple worked. Then it didn’t. Then it worked but password reset broke. Then password reset worked but the share extension failed. Each fix surfaces the next thing that’s wrong, and that’s not a bug in the process. That IS the process.
The skill that gets you through it is patience, and patience is mostly a willingness to stay specific. When something breaks, don’t say “this is broken, fix it.” Say what you tried, what you expected, what actually happened, and what you’ve already ruled out. Same precision you bring to design feedback, applied to debugging. Same skill, higher stakes.
Three habits will save you:
Commit often. Every time something works, commit it to GitHub. When the next fix breaks three other features (and it will), you have a clean version to roll back to. This is one of the five git commands worth learning.
Read the error messages. Actually read them. They look scarier than they are, and they tell you exactly what’s wrong more often than you’d think. You’ll learn more from parsing one error than from any tutorial.
Listen to your customer. What sucks, what's broken? What do THEY need? What AREN’T they using? Keep your beta testers close, bug friends and family for feedback. At this stage, all their insight is a gift.
The reward for all of this is a product that runs. Not a demo. Not a mockup. A real thing on the internet that other people can use. The patience to debug is what separates the people who post screenshots from the people who post App Store links.
Lessons within lessons
Vibe coding isn’t just shipping. If you do it right, it’s also school.
Every project will surface terms and concepts you’ve never heard of. Webhook. Environment variable. CORS. SQL. Race condition. The temptation is to copy-paste Claude Code’s output and move on. Don’t.
When something comes up that you don’t understand, slow down and make Claude teach you. Open chat. Say: “Explain SQL like I’ve never built software before. Use a real-world analogy. Walk me through how they’re being used in my project. Then quiz me.”
You’ll get a mini-curriculum: a plain-language explanation, a case study tied to your actual code, and a few test questions that force you to internalize it. Five minutes. No textbook. No course. Just the concept you needed, sized exactly to the moment you needed it.
This turned out to be the most unexpectedly joyful part of building for me. For fifteen years I worked alongside engineers without speaking their language fluently. Now I do — not because I took a course, but because every concept I needed got taught to me at the moment I needed it. The lesson sticks because it’s anchored to something real.
The compound effect is what matters. After two months of these mini-lessons, you start understanding the conversations happening around you. You stop feeling like a tourist. You become someone who can actually evaluate what’s being built and why.
Build your product. School yourself along the way.
Where your stuff lives
Supabase
Every app needs somewhere to store stuff. Users, passwords, recipes, resumes. Supabase is that place. It handles authentication (Sign in with Apple, Google, email and password), your database, and a stack of backend things you’d otherwise need an engineer to wire up. Both Sundree and Resolut run on Supabase. The free tier is generous enough to ship a real product on.
GitHub
This is where your code lives. Every change, every version, every “what did I just break.” Claude Code uses it. Vercel uses it. You will use it.
You will not understand git for a while. That’s fine. You’ll fight with it. That’s fine too. Eventually you’ll figure out the four or five commands you actually need and forget the rest exist.
How the world sees it
Vercel
If you’re building a website or a web app, Vercel is where it goes. You connect it to GitHub, push your code, and your site is live at a real URL in about thirty seconds. Free tier covers most personal projects. resolut.tools and sundree.app both run on Vercel.
Expo
If you’re building an iOS or Android app, Expo is Vercel for mobile. It handles the genuinely painful parts of getting an app onto a phone and into the App Store. Sundree is built with Expo. Without it, I would not have shipped a mobile app this year.
Apple Developer Program
If you want your app on an iPhone, this is the toll booth. $99 a year. Non-negotiable. Sign up the same week you decide you’re shipping mobile, because enrollment can take a few days and you don’t want to be waiting on Apple at the wrong moment.
What you get: TestFlight for beta testing (the way you let real humans try your app before it goes public), App Store Connect for managing builds and submissions, and the Apple-blessed certificates that let your app actually run on a phone that isn’t yours.
What you don’t get: a fast App Store review. Apple’s reviewers will flag things you didn’t know were rules. You fix the issue, resubmit, maybe get flagged for something else, fix that. This is normal. Build it into your timeline.
It’s the slowest, most analog part of shipping a mobile product, and the part where patience matters most. The reward is a real App Store link to send your friends. And a potential path to real revenue.
How to Start Today
Pick one project. Make it small. Make it something you’d actually use yourself.
Write the brief before you write a prompt. Name. Two fonts. Four colors. Three reference brands. One sentence on how it should feel.
Get on Pro or Max. Install VS Code. Install Claude Code. Make accounts on Supabase, GitHub, and Vercel. All free to start. (If you’re going mobile, budget $99 for Apple Developer and start enrollment early.)
Then build. Use Claude chat to plan and pressure-test. Use Claude Code to do the work. Give it precise feedback when things look wrong. Paste errors into chat before you let Code patch. Commit to GitHub when things work.
The thing you ship in a week will teach you more than the three-month course.
If you’re a creative who’s been on the fence about building, I’d love to help you kick off your project. Drop it in the comments and I’ll respond with the most specific advice I can give.
If you’re building a team where this kind of work — where shipping lives next to brand and concept — is part of the assignment, I’d love to talk. madebyhook@gmail.com.
Stay Sharp, Adam