A vibe-coded app can reach the web in an afternoon. That is a gift. It is also how a private experiment becomes a public liability before its maker notices.
The answer is not to spend six months pretending to be a software department. Launch early. Just decide which rough edges are allowed to survive the launch.
Be embarrassed by the empty state. Do not be embarrassed by the data leak.
Draw a red line through the product
Put every part of the app into one of two groups.
The first group may be rough: animation, copy, filters, keyboard shortcuts, the admin panel you alone use. These things can be repaired after a user tells you they matter.
The second group must work now: authentication, permissions, payment, destructive actions, private data, backups, and account recovery. Failure here costs more than attention. It costs trust, money, or information.
This is the useful meaning of “minimum” in a minimum viable product. It does not mean the least code you can deploy. It means the least product that delivers one real result without taking a reckless shortcut.
Test from outside your own account
Founders test the path they remember. Users take the path the interface suggests.
Create a new account with an address that has never touched the product. Use a phone. Use a slow connection. Deny a permission. Paste a strange value. Refresh halfway through. Open an expired link. Try the back button after payment.
Then ask someone else to get the promised result while you remain silent. Do not guide the mouse. Every sentence you want to say is missing product work.
Read what the model actually built
AI-generated code often looks complete because it contains all the expected nouns: middleware, schema, validation, error handler. Presence is not proof.
Trace one important action from the browser to storage and back. Who is allowed to call it? What is checked on the server? What happens twice? What happens after a timeout? What gets logged? Can another user name a record they do not own?
You do not need to understand every line before showing the product to anyone. You do need to understand every path that can charge, expose, erase, or impersonate.
If the prototype works but the code feels unfit for strangers, use the pre-launch rewrite decision to keep proven behavior, isolate uncertainty, and replace only the consequential paths that lack evidence.
Keep the first launch small enough to survive
A launch is not one cannon shot. It is the first loop with strangers in it.
Start with people you can speak to. Watch them use the product. Fix the failures with consequences. Keep a written list of the harmless ugliness. This prevents a crooked button from outranking a broken password reset simply because the button is easier to see.
Paul Graham’s advice to do things that do not scale fits vibe-coded products unusually well. Manual onboarding, personal support, and direct observation are not signs that the product is fake. They are how you learn which parts deserve machinery.
The launch rule
Ship when one narrow promise works for one real kind of user, the dangerous paths have been checked, and you can hear what happens next.
Everything else is a reason to keep moving, not a reason to hide.