Vibe Coding for People Who Can’t Code: A five-part series. Part III — How you actually build

In Part I of the series, we talked about vibe coding basics, and in Part II, about how to get setup. Today in Part III we start the fun part – the actual build.

One turn of the crank

Here’s a single complete cycle, because once you’ve seen one you’ve seen all of them. An idea arrives. You argue it out in the Project. The Project writes you a handoff prompt in one copyable block. You paste that into the build tool. It writes the code, saves it, and pushes it. The live site updates itself. You look at it. That’s the whole job, repeated a few hundred times.

A few conventions earned their place the hard way:

• Handoffs go in one unbroken block. Splitting instructions across multiple blocks in a single message caused real errors, repeatedly.
• The Project designs, the build tool builds, the spec is the contract between them. The tool implements from the spec; it doesn’t get to rewrite it.
• Ask for the exact version marker of what was just built, and check that — not the tool’s summary of it.
• When you’re confused about what the tool just did, take it back to the Project. The Project has the design context; the build tool has its head down in the files.

What you don’t build

An API is just a way for your software to ask someone else’s software a question and get an answer back. You’re renting a capability (and some or oftentimes the rent is free!) instead of building it — and the instinct to build here is worth teaching yourself out of: if it’s a solved problem and it isn’t your product, rent it. Login is not your product. Sending email is not your product. Your product is the thing only you would have thought of. It’s also the responsible move, since the rented pieces are built by people who do own security — the standard you can’t personally meet by vibe coding.

Worth knowing these categories exist:

• Login and accounts. Never build this yourself; it’s the most common place amateur software gets breached. My two apps solved it two different ways and both were right — one used the login built into its database service, so accounts came essentially free; the other put a single gate in front of the whole site that emails you a sign-in link and only accepts a handful of approved addresses, which took an afternoon and meant authentication was never a project.
• The AI itself, as a piece inside your app. The one people don’t expect. The grocery list’s entire cleverness is one AI call per item — there is no rules engine that can parse “the good olive oil.” Pennies per shopping trip.
• Sending email, blocking bots, limiting abuse. Small, solved, free at your volume.
• Background work, for anything too slow to finish while someone waits on a page.
• Data you don’t have, from services that fill in details or search the web for you. These are the ones with real cost — be careful.
• Payments, which I haven’t needed; when you do, the answer is a service built for it, turned on only when you have a real reason to charge.

Three cautions. Most of these have free tiers that carry you well past a first build. Every one is a dependency that can change price, break, or vanish, so keep the count low and prefer ones you could swap. And “hidden in the browser” is not the same as “protected” — anything that truly must be enforced has to be enforced on the server. Hold that last one; it’s Part IV.

What to build first

The lesson from my Bedrock application: the piece I built first needed no outside data at all — just the quiz answers and a good prompt. That gave me a real, working, shippable feature in hand while the genuinely hard data problems were still unsolved. Sequence by what you’re least dependent on, not by what’s most important. The most important feature usually has the most unknowns stacked behind it, and starting there buys you weeks with nothing working. The corollary: get to something you actually use as fast as possible. Grocery hit daily use in about ten days, and everything good after that came from using it.

Testing when you can’t read code

You don’t test the code, you test the behavior — you use the thing. That’s a skill you already have. The trap is that you’ll test with tidy examples you wrote yourself, and you write like someone who knows how the system works. Clean input hides the bugs that matter.

Here’s the one that taught me. A real family list came in — “Lemons (4),” “Corn – 15-ish ears,” “2 large ripe tomatoes (or more smaller ripe tomatoes)” — and the app stored “Lemons,” “Corn,” “Tomatoes.” Every quantity gone. Nothing was broken. Months earlier the instructions had told it to return a cleaned, normalized item name, and it had been doing exactly that, perfectly, every day, for a month. The bug was an English sentence written in the past that meant something more aggressive than I’d intended. The fix was rewriting that one sentence. No code changed. It only surfaced when a real person wrote a list the way real people write lists.

So: build somewhere to make mistakes that isn’t real life. It’s fifteen minutes of setup, and I never did it — which is how a test email once landed in the live family inbox and had to be deleted before the next sweep pulled it onto the actual shopping list.

Getting other people to test it

You are the worst possible tester of your own thing, because you know how it’s supposed to work and you unconsciously avoid the paths that break. Get it in front of two or three people who’ll tell you the truth, and ask them to use it for something real, not to review it. Then watch someone use it without helping — excruciating, and worth more than any amount of feedback afterward. Ask where they got stuck, what they expected that didn’t happen, and what they’d never use. Nothing will make you feel cooler than having a friend or family member ask for a new feature and delivering it live three minutes later.

The humbling version: with Bedrock, my beta testers had a working experience before I did. My own results page didn’t work correctly on my own profile until two days after launch, because my profile happened to hit the exact edge the engine handled worst. Other people were using the finished product while the person who built it couldn’t.

Which sets up another big shift. You’ve built it, people are using it — and now the difficulty moves one final time, to the fact that when this kind of software goes wrong, it very rarely tells you.