Vibe Coding for People Who Can’t Code: A five-part series. Part II — Setting up
In Part I of the series, we talked about what vibe coding is and how to figure out what you’d build (and if you should build something. Today in Part II, we’re talking about how tools, prices, and signup flows change fast and to treat the specific how-tos as current-as-of-writing and the reasoning as durable.
I run a Linux server and have forgotten I ever didn’t know how. My friend Andrew Winston built and shipped Context Coach as a genuine non-engineer, recently enough to remember every place he got stuck. So we wrote this part together — my structure, his fresh scars, and his real setup list at the end as the worked example. It’s more useful than either of us would be alone.
Two notes before we start. This is written for Claude, because that’s what I use; the same shapes apply to ChatGPT with different names. And here is the single most important habit in the entire post, which we’ll repeat on purpose: every time you get stuck, go back to your design Project, say “I’m not technical, explain this like I’ve never seen it,” and paste in whatever you’re looking at. Andrew and I both screenshot every problem and occasionally paste in code from menus we’d never opened before in applications we only barely understood. That’s not failure. That’s the job.
Step 0 — Accounts, and what this costs
Get a paid Claude subscription; the free tier won’t carry this. Usage works on a rolling session window — you get a chunk of capacity, and when a long build burns through it there’s a wait or a top-up, so treat a big session as a real resource and plan around it rather than discovering the limit mid-build. When it offers you a more capable model for a hard problem, it’s usually worth it.
One thing Andrew hit that’s easy to miss: the app you build may need its own account, separate from your subscription. Context Coach needed a separate developer account to validate its numbers against the real thing. So the tool you design in and the service your app calls can be two different accounts with two different bills.
Know that you’re setting up two things that do different jobs: a Project for design and thinking, and a Claude Code session for building. Same subscription, different tools. The whole method is moving between them.
The cost will vary. If you can get away with a Pro account, it’s something like $20/month. If you’re going to be a heavy user in terms of large amounts of code production every day, you’ll want a Max account for $100/month. Using the ClaudeAPI behind the app can usually fold into those costs but sometimes costs more. I occasionally got tired of waiting for my next session window to start and just bought “extra credits” as well. But all in, the expense isn’t that great, and most of the other resources you’ll need are free or have a meaningful free tier.
Step 1 — Set up your design Project first
Do this before any infrastructure, because the Project is what walks you through the infrastructure. Create it and open with a prompt that does two jobs at once:
I want to build [thing] for [who]. I am not technical — explain every technical term the first time you use it, and assume I’ve never seen a terminal. Be my design and thought partner. Propose the least complex version that would actually work. Before we write any code, help me decide what this does, what it deliberately won’t do, and how I’ll know it’s working. Then draft Project instructions capturing everything a future session needs to know without me re-explaining — and from now on, whenever something changes that belongs in those instructions, tell me and give me the revised text to paste in.
Those Project instructions are the standing context that makes every later session cheap, so it’s worth knowing what belongs in them: who you are and that you’re not technical; what the thing is in two sentences and who it’s for; where the code lives; the key files and what each is for; where it’s hosted; the stack in one line; how you work; and what’s currently in flight.
Then keep them true. At the end of any session where something changed, ask: does anything here need to go into the Project instructions? Instructions drift the same silent way a spec does, and then you’re getting confident answers built on stale context. Ten seconds a session.
One hard rule: no passwords or keys, ever, in the Project instructions. They get read on every single message, so a credential sitting there is exposed continuously. I rotated the same one four times before this sank in.
Know what a good first session looks like: it produces no code. Grocery’s opening conversation produced a data model, six categories, a decision to use email, and a spec — and nothing else. That’s why it shipped in a weekend.
Step 2 — How this actually works
Nothing after this makes sense without it, so here’s the geography.
Your app is a folder. An actual folder on your actual computer, full of files. Everything the build tool does is create and edit files in that folder. That’s the whole thing.
There are three copies of it, in three places. One on your computer, where you work — always a little messy. One on GitHub, a web site owned by Microsoft that every software developer in the world knows and uses but which you may never have heard of, which also keeps the complete history of every version that has ever existed. And one on the server, the live copy other people can reach. Almost all beginner confusion is “wait, which copy am I looking at?” You work on the first, push to the second, and the third updates itself from the second. One direction, always. A drawing of exactly this is the thing Andrew most wishes someone had handed him on day one.
The terminal is just a window where you type instructions instead of clicking them. Terminal on a Mac, PowerShell on Windows, same idea. It looks like an old fashioned DOS prompt from the era before Macs and Windows in the 1980s and early 1990s. You need it for one reason — it’s where the build tool lives — and you’ll type very few commands yourself: one to move into your folder, one to start the tool, and after that you’re writing English. The rule: if a command looks scary, paste it into your Project and ask what it does before you run it. Every time.
Step 3 — GitHub, and why it’s more than a backup
GitHub is that cloud copy plus the full history. Four things you’re actually getting: a real backup; an audit trail, where every change is labeled, dated, and reversible; collaboration, which is how a second person doesn’t overwrite your work the moment they show up; and a hub — your hosting watches it, your automated checks run off it. It’s the center of the wheel.
One correction to advice you’ll see elsewhere: default to private. A private repository is right unless you’re deliberately building open-source software. The AI can read a private repo perfectly well, so there’s no access reason to go public — and public means your code is visible to everyone and can be copied into anyone’s project. If you do open it, learn what the open-source licenses mean. Either way, nothing secret ever goes in the folder.
Two files you create on day one and keep for the life of the project. A spec — what it does, what it deliberately doesn’t, how it’s put together — which the build tool reads at the start of every session so you never re-explain yourself. And a decision log — date, decision, why — ten minutes a week. Two rules keep them honest: the spec changes first and the code follows, never the reverse; and a spec change ships in the same batch as the code that implements it, or it quietly stops being true. Do this (meaning – have the Project do it for you) on day one. It takes an hour, and every one of my three projects either did it or wished it had. Do NOT just turn on Claude Code and start “writing code!”
Step 4 — Hosting: pick a managed platform
Hosting means a computer that’s always on, so your thing works when your laptop is closed. My reviewers were unanimous and blunt here, so I’ll be blunt too: use a managed hosting platform. Vercel, Netlify, Railway, and the like. You push your code; ninety seconds later it’s live. No server to run, no certificates to renew, no traffic to route. It costs a little money and a little control, and for nearly everything you’ll build that is the correct trade every single time.
I do the other thing — I rent a Linux machine and run my own tools on it — and I’m telling you not to. It’s cheap and I have total control and I am also, personally, the entire operations department: domains, routing, certificates, all of it. Martin, who runs a far more serious version of this setup, regrets it daily, does it only to save a few dollars, and once lost the lights in his own house when a security certificate expired. Unless operations is your job, just don’t.
Here’s the tell. When I sat down to write this, I didn’t even know where my relationship application was hosted — I had to go look. That’s not a charming quirk; it’s evidence that self-hosting spreads knowledge you then have to carry in your head.
Step 5 — Domains, or skipping them
A domain is the name people type to reach your thing. For your first build you probably don’t need one — the free address your host gives you works fine, and you can add a real one later without rebuilding anything. If you do want one, you buy it somewhere like GoDaddy or Network Solutions or Namecheap, and the one concept that trips everyone up is pointing the name at the right place — DNS nameservers, which are just “who’s in charge of answering when someone types your name.” A service like Cloudflare can take that over and add speed and protection; email forwarding is the trick that makes a support@ address land in your real inbox.This is useful if you’re building an application that you want others to use, or if you already own a personal domain. It’s not required to tinker.
Step 6 — Connecting it to your own data
Most useful things need to reach stuff you already have, and that’s almost always Google or Microsoft. Three levels, easiest first: connectors in your Project, where you click to authorize and there’s no setup; exports you download and hand over, which is how LinkedIn works; and proper programmatic access, for an app that reaches your data on its own. That third one is where people hit a wall — a cloud console, creating credentials, an authorization dance — and it’s the exact moment to paste screenshots into your Project and say you’re not technical. One firm rule throughout: credentials never go in a file, never in Project instructions, never pasted into chat.
Hard stop. Everything above assumes it’s your data. The moment you point any of this at a company system — your work Slack, your CRM, anything behind a corporate firewall — you stop being a hobbyist and become a security surface, and your IT department is right to stop you. I found that out by doing it. Part V.
The habits that carry you
- Toggle constantly. Stuck in the build tool, go to the Project. Decision made in the Project, hand it to the tool. That back-and-forth is the method. Yes, you will have a moment where you say to yourself, “hmmm…is Claude working for me, or am I working for Claude?” but that is ok!
- Screenshot everything you don’t understand and paste it in. Andrew’s most-used technique, by a distance.
- Say “I’m not technical” as often as you need to. It changes the answer you get.
- Always ask for the simplest version that would work. You can add later. You can’t easily subtract.
The worked example: Andrew’s actual setup list
Everything a genuine non-engineer needed to ship one browser extension. In Andrew’s words, he knew basically none of this going in.
Already in place by the time Context Coach shipped: GitHub, holding the code. Namecheap, for the domain, DNS, and email forwarding so support@ reached his inbox. Netlify, hosting the marketing site via drag-and-drop. A Chrome Web Store developer account, required to actually submit the extension. And a separate developer/API account, used to check the extension’s estimates against the real thing.
Not set up yet — only needed if he adds features: paid backend hosting, payment billing, and a second store listing. All deferred until there’s a reason.
The point of showing you the whole list: it isn’t that much, none of it is writing code, and every item is a thing you can ask the AI to walk you through, one screenshot at a time.
That’s setup — mostly clerical, and mostly a test of whether you’ll keep going. Next in part III is the actual building, where the difficulty moves again: to specifying clearly, and to choosing what not to build.