From vibe-coded prototype to product: the human checklist

Search "vibe coded app to production" and you'll find good technical checklists: audit the AI's security choices, add tests, set up monitoring, harden auth. Do those things — they're real (independent audits find security flaws in roughly half of AI-generated code). But we've watched dozens of builders complete the technical checklist and still never ship. What stopped them wasn't in the codebase. This is the other checklist.

1. Decide what you're actually building

A prototype is an answer to "can this exist?" A product is an answer to "who pays for this, and what am I promising them?" Those are different questions, and the second one can't be delegated to an AI. Write one sentence: who it's for, what it replaces, and why they'd pay. If you can't, that's not a failure — it's the actual work, and it's where a process like structured winnowing earns its keep.

2. Grieve the scope

Vibe coding makes features nearly free, so your prototype probably does eleven things. A shippable product does one thing well enough to charge for. Cutting the other ten hurts in a specific way — each feature was an afternoon of delight — and unacknowledged, that grief becomes procrastination dressed up as "polish." Name it, cut anyway, and keep a someday-list so the cuts feel like deferrals instead of deaths.

3. Audit your motivation, not just your code

Building was fun. What comes next — pricing pages, cold messages, support emails, the same bug three times — runs on a different fuel. Ask honestly: which needs was this project meeting? Play? Mastery? Recognition? Income? If shipping serves none of your real needs, you'll quietly sabotage it. If it serves some, design the launch so those needs keep getting fed. (This is the feelings-and-needs work at the center of our retreat, and it's less soft than it sounds.)

4. Ask for help before you need rescue

The solo builder's trap is asking for help only at the point of crisis — when the security hole ships or the launch lands in silence. Inventory your gaps now: security review, design, distribution, pricing. Then decide, gap by gap, whether it's learn, hire, or partner. Builders who ship consistently aren't more talented; they're faster to admit which seats they shouldn't occupy.

5. Set a public date and a private definition of done

The public date creates accountability; the private definition of done protects you from moving the goalposts at 11pm. "Live, chargeable, announced in three places" is a definition of done. "When it feels ready" is not.

The technical checklist gets your code ready to ship. This one gets you ready. If you're carrying a prototype you can't seem to push over the line, that's exactly the situation an evening workshop was designed for.