How to test a web app before launch: a checklist

How to test your vibe-coded app before launch: a checklist

To test a web app before launch, walk through every main path as a new user on a laptop and a phone, try wrong input on purpose, run a few free checks on the live address, and write down each bug as you find it so your agent can fix them in one batch.

Updated 8 November 2026

AI agents write code that usually works on the path you asked for. The bugs hide on the paths nobody asked about: the empty account, the long name, the phone screen, the second click. An hour of testing like a stranger finds most of them before your users do.

1. Make a short list of paths

Write down the five to ten things a user must be able to do. For example: sign up, log in, create a project, edit it, pay, log out, reset a password. This is your test plan. Nothing fancy.

2. Walk through each one as a new user

Use a fresh account. Your own account has data in it. A new one shows the empty states, like "no projects yet", which are often broken or blank.
Use a private window. It has no saved logins or old cached files.
Click everything once. Every button, link and menu on each page.
Read the words. Placeholder text like "Lorem ipsum" or "Your tagline here" is easy to miss.

3. Try to break it

Submit forms empty. Then with a very long name, an emoji, and an email with no @.
Double-click buttons that save or pay.
Press back after a step. Reload in the middle of a flow.
Log out in one tab and keep using the app in another.
Need realistic test data? The fake data generator makes users, products or orders as JSON, CSV or SQL.

4. Check phones and small screens

Open the app on your actual phone. Look for text that spills out of boxes, buttons too small to tap, and menus that don't open. The responsive checker shows a page at phone, tablet and desktop widths side by side, which is quicker for a first look.

5. Run the launch checks

Once it's on the real address, a few free checks catch the things people forget:

Launch checker: title, share preview, favicon, sitemap, 404 page.
Broken link checker: dead links and missing images.
API key leak checker: secret keys exposed in your JavaScript.
Accessibility checker: missing labels, low contrast and more.
Page speed checker: why it's slow, with the top fixes.

6. Write each bug down, then fix in a batch

Don't stop to fix each bug as you find it. You'll lose your place and test less. Note each one with the page, what you did, what happened and what you expected. Then hand the list to your agent in one sitting. The guide on keeping a list of bugs shows a simple file format your agent can read and tick off.

After the fixes, walk the main paths once more. Fixes sometimes break something next door.

If one bug keeps coming back after every "fix", you're stuck in an error loop. Asking again rarely helps. Go back to your last working commit and give the agent the exact error and what should happen. The guide on getting out of an AI error loop walks through it.

Make step 6 one key with Darnly

Writing bugs down is the step that makes testing slow, so people skip it. Darnly is a free Chrome extension that makes it one move. While you test, press Option+Shift+B (Windows is coming soon), click what's broken, type what you expected, press Enter, and keep testing.

Each bug is saved into your project's .darnly/inbox/ with a screenshot that has the broken part boxed in red, the page address, the element, the steps you took to get there, and console errors and failed requests from the last 60 seconds. The steps and errors matter most for testing: a button that silently fails usually leaves an error you'd never have opened the console to see. On localhost the errors are recorded automatically. On the live address, click Record errors on this site once. For a bug at the end of a long path, press Record the steps first in the panel, then click through as usual.

When you're done, type /darnly in Claude Code or Cursor (or say "fix my Darnly bugs" in Codex). It works through the inbox and writes one line per bug saying what it changed, and the Darnly panel lists them under "Take a look", so you know what to check on your second walk-through.

Testing a Mac app or a mobile app in the iOS Simulator or Android Emulator? The Darnly Mac app does the same there, into the same inbox. Get it from darnly.dev.

Questions

How long should testing take before launch?

For a small app, an hour or two is enough to walk through every main path on a laptop and a phone. Write each bug down as you go and fix them in a batch afterwards.

Do I need automated tests?

Not to launch a first version. A careful walk-through catches most of what users will hit. If you want, ask your agent to write a few tests for sign-up and payments later.

What do people forget to test?

Phones, empty states (a new user with no data), wrong input in forms, slow connections, being logged out, and what happens after a payment or email link.

Should I test on the live address or localhost?

Both. Build and test on localhost, then do one last walk-through on the real address, because hosting settings, environment variables and domains can break things that worked locally.

How does Darnly help with testing?

It makes writing each bug down one key: click the broken part, say what you expected, and it saves a report your AI agent can fix later, with the screenshot and recent errors.