The Vibe Coding Checklist: Before You Share or Launch

An AI-built app is ready to share when its main journey works, saved data survives a return visit, other people's data stays private, and any payments or email behave in a sandbox. Mark each check as Pass, Fail, Not tested, or Not applicable for one named build, and remember that if you have no evidence, it isn't a Pass.

Treat this as a decision record you fill in before launch. It won't teach you how to build the app, and it isn't a score designed to make you feel surer than you are. Run it against one named build before you invite beta testers or take anyone's money. When you're done, it should tell the owner what you saw, what you still don't know, and which failures mean waiting.

How do you record a result?

Give every check one of four statuses. Pass means you ran the check on this build and what happened matched what you expected. Fail means you ran it and it didn't match, or it showed something that could really hurt someone. Not tested means you have no current evidence either way. Not applicable means the feature truly doesn't exist in this product. I'd write down why, so N/A doesn't turn into a polite way of skipping the hard stuff. No evidence never counts as a Pass.

Each row gets an owner, some evidence, a test date, and the build or version. Evidence can be a screenshot, a test record you saved, an event from a payment provider's sandbox, the result of a request, or a short note about what you saw. A Pass on an earlier build doesn't carry over automatically once something relevant has changed.

1. Does the core journey work?

Start with the thing the app promises, since that's what a visitor came for. Ask yourself:

• Can the person you built this for say what the product promises after reading the public copy?
• Can they start and finish the main journey without you helping?
• Does the end result match the promise, or does it just show a success message?
• Have you tried the safe wrong turns, like invalid input, cancelling, and trying again?

A broken main path holds up the launch. Write down the starting page, what you did, what you expected, what happened, and your evidence.

2. Does saved data survive returning sessions?

When someone puts work into the app, it ought to still be there when they come back. Try these:

• Does work that should stick survive a reload, a logout and return, and a fresh session?
• Do edits show up in the actual stored record?
• When someone cancels or deletes something, does the app do what the product says about keeping or restoring it?
• If someone submits twice, does it stop at one record instead of quietly making several?

Lost work is a blocker. Stick to dummy records you control, and please don't try destructive actions on production data.

3. Does the public copy tell the truth?

Read your own pages the way a first-time visitor would, looking for anything that promises more than the product does. Check these:

• Do the audience, offer, price, terms, limits, and next step all say the same thing from page to page?
• Are testimonials, numbers, customer names, and screenshots real, permitted, and something you can back up?
• Does each button say what it will do?
• Do error messages and empty screens say enough to help someone recover?

A wording preference can wait. A misleading price, an invented proof point, or a real contradiction can't.

4. Does the primary journey work on mobile and by keyboard?

Most people will meet your app on a phone, and some will only ever use a keyboard. Check these:

• Can you finish the main journey at phone width with no overlapping, clipped, or hidden controls, and no sideways scrolling?
• Can someone using a keyboard reach the controls in a sensible order and see where they are?
• Do field labels stay visible once a field has something in it?
• Do zooming, long text, empty input, and validation messages still work?

These quick checks aren't an accessibility certification. If you haven't done a deeper review, mark it Not tested, and don't stretch a quick pass into a compliance claim.

5. Can each role see and change only what it should?

Each kind of user should only be able to reach their own stuff, and the way to know is to try it. Check these:

• Using accounts and records you control, can each role see and change only what it should?
• Does a logged-out visitor stay out of the private areas?
• If you copy a link or an ID, does it respect the same boundaries as clicking around normally?
• Does the system itself check admin actions, or are they just hidden in the interface?

If one account can see another account's private data, that's a blocker. Stop testing, keep only the smallest bit of evidence without copying anything sensitive, and fix the rule before you share the build. Our guide to vibe coding security explains the database rules and sign-in checks behind this row.

6. Do payments and email work safely in a test setup?

Do all of it in a sandbox, where nothing real can go wrong. Check these:

• Did you try purchases, cancellations, a declined payment, a delayed confirmation, a retry, and duplicate events from the provider, all in the sandbox?
• Does the payment status your app stored match what the provider says?
• Do automatic messages go only to test inboxes you control, with protection against sending the same one twice where it matters?
• Is marketing consent kept separate from messages people need in order to use the service?

Charging the wrong amount, or giving access without a confirmed payment, is a blocker. Please don't make live charges or message real contacts just to finish this list.

7. What happens when something fails?

Sooner or later something will fail, so the useful question is how kindly the app handles it. Check these:

• When a request fails, does the app keep what the person typed and say what to do next?
• Can they try again without causing duplicates?
• Does the product behave sensibly after a refresh, the back button, a timeout, or a dropped connection?
• Can people find support contact details, and are they right?

Describe recovery the way the product really works. Please don't promise restores, refunds, response times, or retention that the owner can't deliver.

8. Are privacy, permissions, and limits covered?

Look at what a visitor can see and what the product asks of them, and be clear about where your checking stops. Check these:

• Can people read the privacy notice before they hand over personal information?
• Does the product collect only the data it needs for the stated purpose?
• Do the visible flow and your measurement tools both honor people's consent choices?
• Have high-risk legal, security, or accessibility questions been handed to the right specialist, instead of getting a Pass by assumption?

Write down the public checks you ran and where they stop. A product review doesn't amount to a security or legal certification.

9. Can people find and share the right pages?

Search and sharing previews are part of how people reach you, so they're worth a quick look. Check these:

• Does each important public page have a useful title and description that match what's on it?
• Do canonical URLs point to the page you actually want people to land on?
• Do shared previews and search-facing pages avoid draft or private claims?
• Have you looked for broken links, missing pages, and redirects, without adding unpublished pages to a live sitemap?

For an invite-only beta, public discovery can be Not applicable, as long as you write down why. For a public paid launch, discovery and accurate sharing details are part of the customer's path.

If you want a scored second opinion on your public pages before you launch, Is My App Slop audits them and lists the fixes to tackle first.

10. Are you measuring the right thing, and can you roll back?

You'll want to know whether the launch worked, and you'll want a way to undo it if it didn't. Check these:

• Are you measuring the finished outcome, and not just the button click?
• Do you respect consent choices, and can you tell test events from real activity?
• Is there a known checkpoint or a small rollback plan for this release?
• Can the owner tell which build is affected and get working behavior back without deleting production records?

Measuring is there to help you make a decision, and it shouldn't drift into surveillance. A rollback is a scoped recovery. It doesn't give anyone permission to wipe a database or undo unrelated work.

How are a beta and a public launch different decisions?

A beta can go ahead with some rows still Not tested, while a public paid launch needs more proof. An invite-only beta is fine when participants understand the limits, support is available, and there's evidence for the main path, saved data, and access controls. A public paid launch asks for stronger evidence on payments, email, privacy, recovery, and public copy. Neither one gets a pass on leaked data, lost work, wrong charges, or a broken main path. Those are blockers every time, while small visual quirks can go on a list for later. When you're ready for the domain, email, and search side of going public, our website launch checklist puts those steps in order.

What does a hypothetical decision record look like?

One row, filled in the way we'd fill it in, for a product we made up:

This row is hypothetical and doesn't come from a real product. The decision is "hold," because missing evidence isn't a Pass and payment access matters. Once the owner runs the sandbox cancellation, records what the provider and the stored data say, and confirms no access was granted, the row can become a Pass for that build. For platform-specific evidence, try the Lovable testing workflow, and for scenario-based testing, see the vibe-coded app guide.