Vibe coding launch checklist

Vibe Coding Launch Checklist

By Ohad Krispin, founder of VibeRaven · LinkedIn

Before launching a vibe-coded app, choose one task a new user must complete and test it on the intended deployment. Verify sign-in, saved data and denied access for another ordinary account. If the app takes payments, verify the resulting access as well. Record code findings, provider configuration and deployed results separately. A working demo or a clean repository check cannot establish all three.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Why it matters

Why this matters

A notes screen can appear to work while its data disappears after refresh or another account can read the same private note. A launch checklist should turn those assumptions into observable checks for the app you actually built.

Checklist

Launch checks for vibe-coded apps

01Define the first-user core task and its expected result. Record the commit, deployment URL and actual hosting and backend before testing.
02Create a fresh ordinary account in an authorized test environment. Complete sign-in and the core task, then sign out and confirm protected requests require the intended identity.
03Save a disposable record and reload or sign in again. Inspect the response and confirm the expected data persists rather than remaining only in browser state.
04Use a second ordinary account in a separate browser session. For private data, verify the owner can read their record and the second user receives no private fields. Document any intentional team or membership access.
05Verify the deployment uses the intended callback URLs, secrets, database migrations and service endpoints. Record provider settings that require a separate configuration change.
06If payments are used, test checkout in the provider test environment, signed webhook handling, duplicate delivery and the resulting entitlement. Mark payments not applicable if the app does not use them.
07Record verified, failed and not tested checks with evidence. Repair one failed check, then repeat the affected allowed and denied requests on the new deployment.

Manual launch workflow

A small launch record and one scoped agent prompt

This is a proposed manual workflow for your authorized test deployment, not an observed customer result. Use disposable test data and keep credentials and session tokens out of saved evidence.

Record the check before claiming a result

Commit and deployment:
Route or operation:
User role and expected access:
Expected result:
Actual response or behavior:
Evidence reference, with secrets removed:
Result: VERIFIED / FAILED / NOT TESTED
Code fix or provider change needed:

Give the agent one failed or untested check

Inspect the private-note read path for this commit and deployment.
Cite the relevant files, identity checks and data ownership rules.
Separate a code fix from provider configuration or unapplied migrations.
Propose the smallest repair for the recorded failed or untested check.
Verify owner access and denied access for a second ordinary account
in an authorized test environment with disposable records.
Report actual evidence and remaining not tested items.

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

What should I check first before launching a vibe-coded app?

Test one first-user task on the intended deployment: sign in, save its result, reload it and verify another ordinary account cannot read private data. Check payment access only if the app uses payments.

Can my coding agent verify the whole launch checklist?

It can inspect code and run authorized tests with the context and access you provide. Provider settings and deployed behavior need their own evidence. Ask it to report anything it could not test.

Does a clean repository check mean I can launch?

A clean repository check covers the rules and files inspected. It does not establish live permissions, payment entitlements, provider configuration or the whole user journey. Keep those results in the launch record.