Chapter 9: Secrets from People Who've Done This

One-line summary: Real advice from actual vibecode builders — the stuff they wish someone told them on day one.

---

#These Came From Real People

These tips are from builders who entered the vibecode competition — some who won, some who submitted multiple times, all of whom learned things the hard way so you don't have to.

Names are kept private. The wisdom is real.

---

#"Start small. My winning app started as a single-page balance checker."

The temptation is to go big. Build the whole thing. Every feature. The full vision.

Resist it.

Every project that actually shipped started simple. One page. One feature. Something that works. Then you add to it.

A clean, working balance checker beats a broken DEX every time.

---

#"Don't try to build a DEX on day one. Build a tip jar. Then add features."

Start with easy. Win with easy. Get used to the process: describe → build → see → tweak.

Once you've done that loop three times on a simple app, you'll be ready for something ambitious. Skip ahead and you'll get stuck and frustrated.

The tip jar teaches you everything you need to know.

---

#"When Bob gives you something that's 80% right, don't start over. Fix the 20%."

This is huge. When your app is almost right, your instinct might be "ugh, this isn't what I wanted, let me try again from scratch."

Don't.

Instead: look at the 20% that's wrong and describe exactly what needs to change. "The colors are off — change to X." "The button is in the wrong place — move it to Y." Bob will fix the specific things. The 80% that's right stays right.

Incremental wins beat restarts every time.

---

#"Take screenshots as you go. You'll need them for submission."

You need a screenshot to submit. And your best version of the app might be from three hours ago before you changed something.

Screenshot after every big change. Takes two seconds. Saves you from scrambling later.

Ctrl + Shift + S (Windows) or Cmd + Shift + 4 (Mac). Do it constantly.

---

#"Read the error messages out loud. They're less scary that way."

Okay, you still don't need to understand them. But reading them out loud to yourself (or to Bob) makes them feel less like a wall of doom and more like... a weird sentence.

And then you paste it to Bob, and he translates it in 10 seconds.

Errors are just messages. They tell you what happened. Bob speaks that language. You don't need to.

---

#"My second app was better than my first. My third was better than my second."

There's a learning curve, but it's not a coding learning curve. It's a describing learning curve.

You get better at telling Bob what you want. You get better at seeing what to fix. You get better at knowing what looks good and what doesn't.

That curve is fast. Most people feel significantly more confident after their second project.

Submit your first one even if it's not perfect. Build a second one right after.

---

#The Mindset That Wins

The people who do best in this competition share one trait: they ship.

Not "they built the most technical thing." Not "they had the most experience." They shipped something real, on time, and stood behind it.

A simple tip jar that works > an ambitious DEX that's 70% done.

Done beats perfect. Always.

---

#The One-Line Summary of All of This

Build something small, make it work, make it yours, ship it, repeat.

That's the whole game.

---

Next up: Quick answers to every question you might have. →