What I Check in a Product Audit Before Launch

Most launch problems are not mysterious. They are small, known gaps that nobody had time to look at because everyone was busy building. An audit is simply making time to look, with a checklist, before the gaps become one-star reviews.

Here is the checklist I work through, in the order I work through it.

1. The core user journeys

Before reading any code, I use the product the way a new user would. Sign up, complete the main task, pay (if there is payment), come back the next day. I am looking for the places where someone would give up.

• Can a new user reach the main value of the product in the first session?
• What happens with no internet, a slow connection, or a denied permission?
• Are empty states, error messages and loading states designed, or are they whatever the framework shows by default?
• Does onboarding ask for anything (an account, notifications, location) before the user understands why?

2. Architecture and code health

I am not grading style. I am looking for the things that will make the next three months of changes slow or risky.

• Is business logic separated from UI, or does every screen talk directly to the database or API?
• Is there one clear way state is managed, or several competing ones?
• Are there tests around the parts that handle money, authentication and user data?
• How hard is it to build and run the project from a clean machine? If only one person can do it, that is a launch risk.

This matters even more for codebases built quickly with AI tools. I wrote more about that in Vibe Coding Cleanup.

3. Security and data handling

• No API keys or secrets shipped inside the mobile app or the frontend bundle.
• Database rules (Firestore, Supabase, or your own API) actually restrict who can read and write what. Default-open rules are one of the most common issues I find.
• Passwords, tokens and personal data are stored and transmitted safely.
• Users can delete their account and data, which both app stores now expect.

4. Performance on real devices

Apps are usually built and tested on fast, recent phones. Your users are not all on those phones.

• Startup time and the first screen on a mid-range Android device.
• Image sizes and asset weight. Unoptimized images are the easiest performance win in most apps.
• Lists that load everything at once instead of paginating.
• For web products: Core Web Vitals on a throttled mobile connection.

5. Store and release setup

This is where launches most often slip by days or weeks, because review rejections arrive late.

• Privacy policy, data safety form and App Privacy labels match what the app actually collects.
• Permissions are requested in context, with a clear reason string.
• Subscriptions and in-app purchases follow store rules, including restore purchases.
• Separate development and production configuration, with production keys only in production builds.
• Screenshots, descriptions and review notes (including a demo account if login is required) are ready.

6. Analytics and crash reporting

If you cannot see what happens after launch, you cannot fix it. I check that crash reporting is installed and tested with a deliberate crash, and that a small set of meaningful events is tracked: sign-up completed, core action completed, payment completed. Ten events you trust are worth more than two hundred you never look at.

7. Operational basics

• Who gets alerted if the backend goes down, and how?
• Are backups configured, and has anyone tried restoring one?
• Is there a way to force-update or show a message to users on an old, broken version?
• Are domain, hosting, store accounts and third-party services owned by the company, not by one freelancer's personal email?

What you get at the end

The audit ends with a written list, sorted into three groups:

• Fix before launch: anything that risks user data, store rejection, or the core journey failing.
• Fix soon after launch: real problems that will not hurt the first users.
• Leave for now: things that are imperfect but not worth the time yet.

That third group matters as much as the first. An audit that says everything must be fixed is not useful to a team with a launch date.

If you have a product that is built but not launched, or launched but fragile, this is exactly the work I do. See product and technical audits and launch readiness.