The pre-launch checklist for vibe-coded apps

Vibe-coded, in this guide, means you built the app by telling Claude Code, Lovable, Base44, or Cursor what you wanted, then accepting what it wrote. The app can look finished while a stranger still cannot get in. This checklist is the short list to walk before real users see it.

It is not a company launch plan. There is no press section and no legal review hiding in here. It is the product door: the first screen, the signup, the first job, the phone width, and the errors a visitor can actually see. Each line is something you can check with a session, not a feeling.

If you only do the top of the list, do that. A perfect checklist that you never run is worse than three honest goals. The way to run it is at the bottom: paste the URL, edit three visitors, and let each one try a line from this page.

Before you open the list

Write one sentence: the job a new person must finish. "Create an account and see an empty project with a button to add the first client." Put the sentence above the checklist. Any line that does not serve that sentence can wait.

Open the app in a private window, signed out, starting from the public URL. Your logged-in preview is a different product. The checklist is about the public one.

Have a place to write three lines per failure: what you tried, what the screen showed, what should have happened. You will paste those lines into your editor later. A checkmark with no note will not survive the next prompt.

The first screen

The first screen is the only page you can assume a stranger will see.

• The page loads, and the browser tab has a title that says what this is.
• There is one clear heading a person can read without squinting.
• The heading or the line under it says what the app does in plain words.
• There is one obvious next step: a button or a link a new person would tap.
• That next step is visible without hunting in a menu.
• The words match the job you wrote. If you renamed the product in a later prompt, the old name is not still on the button.
• Links in the header go to pages that load. A header link that returns an error is a broken door, even if the hero looks fine.

Read the first screen once as if you have never heard your own pitch. If you cannot tell what to tap, the rest of the checklist does not matter yet.

A page can fail this section in a quiet way. The heading exists, but it is the name of your repository. The button exists, but it says "Submit" under a paragraph about your mission. The title in the tab is "Home." None of those are crashes. All of them make the next click a guess. Fix the words before you add a second section to the page.

Signup

Signup is where AI-built apps most often look done and are not. Give it its own pass. The longer guide is why the signup flow breaks. The checklist lines are these:

• A signed-out person can find signup from the first screen.
• Every field has a label a person can see, not only a placeholder that disappears while typing.
• The email field is a real email field, and a bad email gets a message the person can read on the page.
• Submitting a valid form does something you can prove: a confirmation screen, a logged-in home, or a clear instruction to check email.
• The success message is not a lie. If it says the account exists, the account exists.
• Errors stay on the page. An error that exists only in the browser console is invisible to your user.
• After signup, there is a way to sign in again on a second visit.
• You know what a test signup will leave behind, and you can delete a test account in your own database.

If signup sends email, check that mail in an inbox you control. A practice visitor can reach the "check your email" screen. It will not read your customer's inbox for you.

Try signup twice. The second time, use the same email. The page should say that the account already exists, or it should sign the person in. A second account with the same email, or a silent failure, is a launch blocker. Also try an empty submit. The page should point at the missing field. A shake animation with no words does not tell a new person what to fix.

The first real job

After the account exists, the person should be able to do the one job.

• The first screen inside the app shows the next action. An empty dashboard with no button is a dead end.
• The empty state explains itself. "No projects yet" plus a way to add one is enough.
• Doing the job once produces proof: the item appears, the booking shows, the file is listed.
• Refreshing the page does not erase that proof.
• The person can find their way back to that proof on a second visit.
• Buttons that are not built yet are not shown as if they work. A control that does nothing teaches people to distrust the ones that do.
• If a step needs data the person does not have, the page says so in words, on the page.

Do the job in a private window after a fresh signup, not while you are already halfway through as the owner. Owner state hides empty states. Your database is full. Theirs is empty. The empty state is the product they meet.

If the job has two steps, check the middle. A wizard that loses the first answer when you go back is a classic AI-built bug: the pages exist, the memory between them does not. Write "step one is still here when I return" as its own line if your app is a wizard.

Phone width

You do not need a box of phones to check the lines that block launch. You need a narrow window and honest eyes. Details live in the mobile guide.

• At a narrow width, the page does not scroll sideways.
• The main button is on the screen, and the text inside it is not cut off.
• Text does not overflow its buttons or cards.
• The menu, if you have one, can be opened and closed, and the links can be tapped.
• Form fields are wide enough to type in, and the submit button is not trapped under a sticky bar.
• Headings do not collide with buttons.
• A laptop layout that you only checked wide gets one narrow pass before you call it done.

A phone-width browser catches layout. It does not catch every physical-device quirk. For launch, layout and a working signup at that width are the bar.

Check the first screen and the signup form at that width, not only the home page hero. Forms break more often than heroes. A label that wraps under the field, or a button that sits below the fold under a tall illustration, will not show up in the desktop preview your builder tool likes to show.

Errors a person can see

Crashes that only you can see will still embarrass you, but the launch list is about what the visitor meets.

• A missing page shows a simple message and a way home, not a raw error code with no link.
• A failed save says that it failed.
• A slow page is still usable, or it shows that it is working. A spinner that never ends is a stuck job.
• The browser console is not the only place errors appear. If the session records a console error on the public page, treat it as a real defect even when the page looks fine. Pages that throw often break the next click.
• Broken images are either fixed or removed.
• Images that carry meaning have a text alternative. Decorative images can have an empty one. A report that flags a missing alt is telling you the image is invisible to anyone who cannot see it.

You do not have to clear every low note before launch. You do have to clear errors that block the job or that tell the visitor the app failed.

Trust on the public page

Trust here means "a stranger can tell this is a real, careful page." It does not mean a wall of badges.

• The product name is spelled the same way across the first screen, the tab, and the signup.
• There is a way to reach you, even if it is a single email link that works.
• Prices, if you show them, match what you actually charge. Do not leave a sample price from a template.
• You are not showing another company's name, logo, or quote by accident because a prompt used it as filler.
• Buttons that take payment say so before the person is deep in a form. A practice test will stop at payment. Your own check should confirm the pay button is honest.
• The page has a sane title and one main heading. Those are small, and they are also how a person knows they are in the right tab.

If your template came with fake testimonials, remove them. A made-up customer is not a launch task you finish later. It is a false thing on the page. Delete it before you invite a real person.

The report you keep

A checklist in your head disappears during the next prompt. Keep a report.

• One note per stuck line, with the page and the three lines: tried, saw, expected.
• A screenshot of the stuck screen.
• A replay or a short written path of the clicks, so you can reproduce it after the editor rewrites the file.
• A fix prompt you can paste into Claude Code or Cursor, naming the page and telling the editor to leave unrelated layout alone.
• A second run of the same goal after the fix.

That bundle is the launch log. When a later prompt breaks signup again, you already know the goal to rerun.

Store the passing replay too. "It worked on this date" is a weak memory. A replay of the passing signup is something you can compare when a future prompt breaks it. You will see which click changed.

What can wait

These are real tasks and they are not the door. Do them after a stranger can finish the first job.

• A second visual theme.
• Extra empty-state illustrations.
• A blog, unless the blog is the product.
• Fine-tuning every color.
• Accounts for a team you do not have yet.
• A native app, if the web app is the thing you are launching.
• Integrations you do not need for the first job.
• Perfect scores on every small accessibility note that does not block the path. Fix the ones that hide a button or a field. Schedule the rest. Do not skip a missing form label. That one blocks people.

Waiting is a choice you write down. "No public price until ten real users" is a choice. "I forgot to look" is not.

Also wait on rewriting the whole UI because one screen feels plain. Plain and finishable beats polished and stuck. You can restyle after the goal is reached. Restyling before that is how the button you just fixed moves again.

How to run the list with three sessions

Spreadsheets fail because they ask you to be the stranger. Hand the top of the list to three visitors.

1. Paste the public URL. Skip any domain ceremony. The URL is the setup.
2. Read the three drafted visitors. Edit the goals so they match three lines from this checklist. A solid trio: sign up and see the account, find the price or the way to start, and finish the first job inside the app (or follow the main button if the first job is behind signup).
3. Keep one visitor on a phone. Let a laptop visitor run too. The phone-width check still happens.
4. Accept once. Each visitor gets a real browser. The signup visitor can create an account the way a new customer would, using a test email. They will not pay or send a text.
5. Read the report from the most serious finding. Open screenshots. Watch the replay of anyone who got stuck or who finished without a clear result.
6. Copy the fix prompt into Claude Code, Cursor, Lovable, or Base44. Patch the blocking line. Run that goal again.
7. Tick a line only when a session has reached it after the latest edit.

The difference between this and a checklist you fill in yourself is the record. You get screenshots, a session replay, and a prompt that quotes the visitor, the goal, and the findings. You can still walk the list yourself in a private window. Do that for the email inbox and for any payment test mode. Let the sessions cover the path a stranger takes.

If you want to know which lines are "does the step work" and which are "can a person tell what to do," read usability testing and QA testing. You need a thin slice of both. This list already mixes them on purpose: a missing page is QA, a button you cannot find is usability, and both can stop the launch.

A worked hour on a client portal

Made-up example, so the order is concrete. A freelancer built a client portal in Cursor. The job sentence is "A client signs up and sees the latest file."

First screen: the heading is "Portal," which fails the plain-words line. The button says "Enter." You rewrite the heading to "Your project files" and the button to "Sign up" before you test further, because a test of a meaningless button is a muddy report. You can do that rewrite yourself or with one prompt that only changes those words.

Signup: the drafted phone visitor submits the form. The report shows an unlabeled password field and a return to the home page with no proof of an account. You copy the fix prompt, paste it into Cursor, and ask it to keep the layout. The second run reaches a screen that shows the email. You tick signup.

First job: the empty state says nothing and has no upload button, because you were signed in as the owner when you designed it. The laptop visitor gets stuck. Screenshot, replay, prompt, patch, second run. The empty state now says "No files yet" and offers a way to add one. You tick the job.

Phone width: the file name overflows the card. The report flags the overflow. One more prompt. You tick the phone line.

You do not tick "team accounts" or "dark mode." You send the link to one real client and ask them to sign up and open the latest file.

That is a launch checklist for a vibe-coded app. The lines are few, they can fail, and they leave a report you can paste back into the editor that built the product.

Questions people ask