How to Test a Mobile App Before Launch: A Founder's Checklist

Most launch problems I see are not exotic. A sign-up that fails on one phone model. A payment that succeeds but never shows in the app. A screen that looks fine on the office Wi-Fi and spins forever on a train. None of these need special tools to find. They need someone to sit down with a list and try the app the way customers will.

This guide is that list. It is written for founders and business owners signing off a release built by their own team or an outside partner. It does not replace your developers' testing. It is the check you do on top of it.

Know who tests what

Testing an app happens in three layers. Each catches different problems, and skipping one usually means its problems reach your customers.

Ask your team early what their QA covers: which devices, which operating system versions, and whether they run automated tests on the core flows. A clear answer here tells you a lot about how the rest of the project will go. Our mobile app QA and testing page shows what we include.

Step 1: Write down your core flows

Before you test anything, list the five to ten journeys that make or break the business. For a booking app that might be: sign up, search, book, pay, cancel, get a reminder. For a field team app: log in, see today's jobs, update a job offline, sync. Write each one as a short sequence of steps with the result you expect.

If you have a PRD or user stories, start from those. Every flow should map to something in the agreed scope, which makes sign-off a factual conversation instead of a debate.

Step 2: Test on the phones your customers use

• A spread of Android phones: at least one budget phone with limited memory, one mid-range phone and one recent flagship. Budget phones expose slow screens and crashes that flagships hide.
• At least two iPhones: one small screen and one large, including the oldest iOS version you support.
• Large text and dark mode: turn on the largest font size and dark mode on one device and walk through every screen. Text that gets cut off is a common, avoidable problem.
• Accessibility basics: check that buttons have readable labels for screen readers and that contrast is reasonable. The WCAG guidelines are the usual reference.

Step 3: Break it the way real life does

Most apps are tested on fast office Wi-Fi with a full battery. Customers use them on a weak mobile signal, while switching apps, with notifications off. Try each of these on your core flows:

• Switch to a slow or unstable connection, then turn on airplane mode in the middle of a task. The app should tell you what happened and recover, not freeze or lose data.
• Send the app to the background during a payment or upload, then come back.
• Take a phone call in the middle of a flow.
• Deny a permission, such as location or camera, and see whether the app explains why it needs it and still works where it can.
• Log in on two devices with the same account.
• Use the app for a full day and watch battery use and phone storage.

Step 4: Check money, messages and data carefully

The flows that touch money or customer data deserve their own pass, because mistakes there cost trust, not just time.

• Payments: test a successful payment, a failed payment, a cancelled payment and a refund. Check that the order status in the app, the admin panel and the payment provider's dashboard all agree.
• Notifications, SMS and email: confirm each one arrives, reads correctly and opens the right screen when tapped.
• Admin panel: make a change in the admin panel and confirm the app reflects it. Many launch issues sit between the two.
• Accounts: test password reset, logout, account deletion and what happens to a deleted user's data.
• Security basics: our mobile app security checklist lists what to confirm before real customer data goes in.

Step 5: Run a short beta with real users

Both stores have built-in ways to share a pre-release build. Apple uses TestFlight, and Google Play has internal, closed and open testing tracks. Note that Google Play asks new personal developer accounts to run a closed test with a minimum number of testers for a set period before they can publish, so check the current rules early and build that time into your plan.

Keep the beta small and specific. Pick people who match your target customer, give them two or three tasks to complete, and ask what confused them. Watch one or two of them use the app in person if you can. You will learn more from ten minutes of watching than from a week of written feedback.

Step 6: Make sure you can see problems after launch

Testing reduces risk. It does not remove it. Before you launch, confirm with your team that:

• Crash reporting is switched on for both platforms and someone checks it daily in the first weeks. Google's Android vitals also shows crash and freeze rates for apps on Google Play.
• Basic analytics track whether users finish your core flows, so you can spot where they drop off.
• There is a clear process for releasing an urgent fix, and you know who to call.
• Store listings, privacy details and the demo account for reviewers are ready. Our App Store and Google Play approval guide covers the common rejections.

Step 7: Decide go or no-go with clear rules

Agree the sign-off rules before testing starts, not after. A simple version that works for most first releases:

• Blockers: anything that stops a core flow, loses data or mishandles money. Zero allowed at launch.
• Major issues: a core flow works but is confusing or slow. Fix before launch, or launch with a dated plan to fix.
• Minor issues: cosmetic problems and edge cases. Log them and schedule them after launch.

Keep all issues in one shared list with screenshots, the phone model and the steps to repeat them. It makes fixes faster and gives you a clean record of what was agreed. Planning the budget for life after launch? Our guide to software maintenance cost and planning helps, and the app timeline calculator shows where testing fits in an overall schedule.

How we handle testing at Creuto

At Creuto testing runs through the whole build, not just the final week. You get a working build on your own phone early, typically with the first working version in about 4 weeks, so acceptance testing starts long before launch. We test on real Android and iOS devices, handle store submission, and every launch is covered by a 60-day post-launch warranty. Apps like the Make My Look salon app went through this same process before going live.