The Vibe Coding Checklist: Before You Share or Launch

This checklist is a prelaunch decision record, not a build tutorial or a score that turns uncertainty into confidence. Complete it against one named build before you invite beta testers or accept money. The result should tell the owner what was observed, what remains unknown, and which failures hold the launch.

How to record a result

Use exactly four statuses. Pass means the check was performed on this build and the observed result matched the stated expectation. Fail means it was performed and did not match, or exposed unacceptable harm. Not tested means no current evidence exists. Not applicable means the capability genuinely does not exist in this product; record the rationale, because N/A must not become an easy way to skip difficult work. Missing evidence is never a Pass.

Every row needs an owner, evidence, test date, and build or version. Evidence can be a screenshot, stored test record, provider sandbox event, request result, or concise observation. A previous build's Pass does not automatically transfer after a relevant change.

1. core journey

• Can the intended visitor state the product's promise from the public copy?
• Can that visitor start and complete the primary journey without coaching?
• Does the final result match the promised outcome rather than merely showing a success message?
• Have safe invalid, cancellation, and retry paths been exercised?

A broken primary path is a launch blocker. Record the exact starting page, actions, expected outcome, actual outcome, and evidence.

2. saved data and returning sessions

• Does work that should persist survive reload, logout and return, or a fresh session?
• Are edits reflected in the authoritative stored record?
• Does cancellation or deletion follow the documented retention and recovery behavior?
• Is duplicate submission bounded so one action does not silently create multiple records?

Lost work is a blocker. Use only controlled dummy records, and do not test destructive operations against production data.

3. public copy and proof

• Are audience, offer, price, terms, limitations, and next step consistent across the journey?
• Are testimonials, statistics, customer names, and screenshots authentic, permissioned, and supportable?
• Do buttons name the action or outcome they trigger?
• Are errors and empty states specific enough to guide recovery?

A cosmetic wording preference can wait. A misleading price, invented proof point, or material contradiction cannot.

4. mobile, keyboard, and input

• Can the primary journey be completed at a phone width without overlap, clipping, hidden controls, or forced horizontal scrolling?
• Can a keyboard user reach controls in a sensible order and see focus?
• Do labels remain available when fields contain values?
• Do zoom, long text, empty input, and validation states remain usable?

Basic checks are not an accessibility certification. Mark deeper review Not tested when it was not performed rather than converting a quick pass into a compliance claim.

5. accounts and access controls

• Using accounts and records the tester controls, can each role see and change only what it should?
• Does a logged-out visitor remain outside private areas?
• Does a copied link or identifier preserve the same boundary as normal navigation?
• Are administrative actions verified by the system rather than hidden only in the interface?

Any exposure of another account's private data is a blocker. Stop the test, preserve minimal evidence without copying sensitive material, and fix the enforcement before sharing the build.

6. payments and email in safe environments

• Were purchases, cancellation, declined payment, delayed confirmation, retry, and duplicate provider events checked in a sandbox?
• Does the stored payment state agree with the provider's authoritative result?
• Do transactional messages go only to controlled test inboxes, with duplicate-send protection where relevant?
• Is marketing consent separate from a necessary service message?

Wrong charges or granting access without verified payment are blockers. Never create live charges or message real contacts merely to complete this list.

7. failure, recovery, and support

• Does a failed request preserve input where appropriate and explain the next step?
• Can the visitor retry without creating duplicate effects?
• Does the product behave predictably after refresh, back navigation, timeout, or lost connection?
• Is support contact information findable and accurate?

Recovery should match the product's real behavior. Do not promise restoration, refunds, response times, or retention that the owner cannot provide.

8. privacy, permissions, and operating boundaries

• Is the privacy notice accessible before personal information is submitted?
• Does the product collect only data needed for the stated purpose?
• Are consent choices honored by the visible flow and measurement tools?
• Are high-risk legal, security, or accessibility questions assigned to an appropriate specialist rather than marked Pass by assumption?

Record the public checks performed and the limits of those checks. A product review is not a security or legal certification.

9. discovery and metadata

• Does each important public page have a useful title and description matching visible content?
• Do canonical URLs identify the intended destination?
• Do shared previews and search-facing pages avoid draft or private claims?
• Are broken links, missing pages, and redirects checked without adding unpublished pages to a live sitemap?

For an invite-only beta, public discovery may be Not applicable with a written reason. For a public paid launch, discovery and accurate sharing details are part of the customer path.

10. measurement and rollback

• Is the completed outcome measured instead of only the button click?
• Are consent choices respected, and are test events distinguishable from real activity?
• Is there a known checkpoint or narrow rollback plan for the release?
• Can the owner identify the affected build and restore working application behavior without deleting production records?

Measurement should support a decision, not create surveillance. A rollback is scoped recovery, not permission to erase a database or unrelated work.

Beta and public launch are different decisions

An invite-only beta may proceed with some Not tested rows when participants understand the boundaries, support is available, and the primary path, saved data, and access controls have evidence. A public paid launch requires stronger evidence for payment, email, privacy, recovery, and public copy. Neither launch type excuses data leakage, lost work, wrong charges, or a broken primary path. Those are explicit blockers; small visual inconsistencies can be logged for later.

Hypothetical decision record

This row is hypothetical, not a result from a real product. The decision is “hold,” because missing evidence is not a Pass and payment access is material. After the owner runs the sandbox cancellation, records the provider and stored results, and confirms no access was granted, the row can become Pass on that build. Use the Lovable testing workflow for platform-specific evidence and the vibe-coded app guide for scenario-based testing.