Guides / Prompting and shipping

How to Test Your App Before Launch: A Practical Pre-Launch Plan

A pre-launch testing plan for small apps: test the main journeys, edge cases, permissions, phones, payments and the live URL, with a checklist to finish.

Mythex Team · 2026-09-29 · 6 min read

To test your app before launch, list the few journeys a user must be able to complete, run each one as a brand-new user on a laptop and a phone, then try the ways they can go wrong: empty data, bad input, a second account, a slow connection. Test anything involving money or private data with extra care, and repeat the main journeys on the live URL after publishing. Finish by watching someone who has never seen the app try to use it.

You don't need a QA team or a testing framework for this. You need a list, an hour or two, and the discipline to actually click through it.

Step 1: Write down the journeys that matter

A journey is a start-to-finish task a user comes to do. Most apps have three to six that really matter. For a booking app:

1. Sign up and confirm the account
2. Find a class and book it
3. Cancel a booking
4. Pay for a class pass
5. Staff: see today's bookings

If you've written user stories, their acceptance criteria are your test cases already. If not, write one line per journey with what "success" looks like.

Rank them. The journeys that make money or that every user hits (sign-up, login, the core action) are tested first and most.

Step 2: Test the happy path as a new user

The "happy path" is the journey going exactly as intended. Test it as a stranger would experience it:

• Use a private browser window, so you're not logged in and have no saved data.
• Use a fresh account with a real email you can check.
• Start from the home page or a link, not a page you bookmarked while building.

New users have no data. Many bugs only show up when a list is empty, a profile has no photo, or nothing has been bought yet. Your own account, full of test data, hides them.

Step 3: Try to break it

Now repeat each journey and do the wrong thing on purpose.

Refreshing is worth calling out: if the app works when you click through but a refresh on a deeper page shows a 404, see how to fix 404 errors after deploying.

Step 4: Test permissions with two accounts

This is the most important test for any app with accounts, and the one most often skipped.

Create two normal users, A and B, and (if your app has them) an admin.

• As A, create a record. Log in as B. Can B see it, edit it or delete it? They shouldn't, unless that's the design.
• As A, copy the URL of one of your records. Log in as B and open that URL directly.
• As a normal user, open admin pages by typing their URLs.
• Log out entirely and try the same URLs.

If you find a problem here, don't launch until it's fixed. The check must happen on the server, not just by hiding a button. Our security checklist for AI-built apps goes deeper.

Step 5: Test on real devices

Open the app on an actual phone, not just a narrow browser window.

• Can you tap every button without zooming?
• Does the keyboard cover the field you're typing in?
• Do tables and wide content scroll or wrap, instead of pushing the page sideways?
• Is text readable without pinching?

Try at least one iPhone (Safari) and one Android phone (Chrome) if you can borrow them. Safari in particular has its own quirks with dates, video and fixed-position elements.

Step 6: Test money and email end to end

Anything that charges cards or sends emails needs a full run-through.

Payments. Use your payment provider's test mode and test card numbers. Check a successful payment, a declined card, and a cancelled checkout. Confirm the order or subscription shows up in your app after payment, not just on the provider's dashboard. If your app relies on webhooks (messages the payment provider sends your server), check they arrive on the published app, not only in development. Then, before launch, switch to live keys and make one small real purchase you refund.

Emails. Sign up with real addresses at two or three different providers. Check that emails arrive, aren't in spam, and that every link in them points at the live domain, not a preview address.

Step 7: Check speed and errors

• Open the browser's developer tools (right-click → Inspect) and look at the Console tab on each main page. Red errors are worth fixing even if nothing looks broken.
• Load the site on a phone using mobile data, not Wi-Fi. If the first screen takes several seconds, look at image sizes first.
• Run a free audit such as Lighthouse in Chrome's devtools for a quick read on performance and accessibility.

Step 8: Test the published app, not just the preview

A preview and a published app are not the same environment. Before telling anyone about the launch, repeat the main journeys on the live URL:

• Are all environment variables and secrets set for the published app?
• Is it using the right database, with the data you expect?
• Do login redirects and email links use the live domain?
• Does a refresh on a deep page load correctly?

Step 9: Watch someone else use it

Give one or two people a goal ("book a yoga class for Saturday"), not instructions. Watch, don't help, and write down where they hesitate. It's the fastest way to find confusing wording and hidden buttons. For a larger version of this, see how to run a beta test.

When they hit a bug, write it down properly, with steps, expected result and actual result. Our guide on writing a good bug report shows the format.

Using AI to help you test

If you build with AI, you can ask it to help plan and run tests:

List the main user journeys in this app and, for each one, the edge cases most likely to break: empty states, invalid input, permissions, and refresh. Put it in a checklist I can work through.

Log in as two different test users and check whether user B can see or change anything user A created, including by opening A's record URLs directly. Report what you find before fixing anything.

Treat the AI's own test report as a first pass. Still click through the money and permission journeys yourself.

Testing in Mythex

In Mythex, the /test command runs App Testing: the agent drives a browser against your live preview, clicks through pages, captures screenshots and reports broken flows in chat. It works best with a specific journey, such as "test sign-up and booking a class". Fix what it finds with /fix or a normal message, then run /test again. App Testing uses the preview, so check the main journeys on the published URL yourself after publishing. See App Testing in the docs, and our guide on debugging an AI-built app for when something fails.

Common mistakes

• Testing only as yourself. Your admin account with lots of data hides empty-state and permission bugs.
• Testing only on a laptop. Most visitors to many sites arrive on a phone.
• Skipping the second account. Data leaking between users is the most serious bug an app can launch with.
• Trusting the preview. The live app has different settings; test it too.
• Fixing bugs without retesting nearby. A fix to one form can break another that shares code.

Pre-launch checklist

• Main journeys listed and ranked
• Each journey passes as a brand-new user in a private window
• Empty, invalid, long and duplicate input handled
• Refresh works on every page
• Users can't see or change each other's data, even by URL
• Admin pages blocked for normal users and logged-out visitors
• Works on a real iPhone and Android phone
• Payments tested: success, decline, cancel, and the app updates afterwards
• Emails arrive, avoid spam, and link to the live domain
• No red errors in the console on main pages
• Main journeys repeated on the published URL
• At least one outside person tried it while you watched