In this guide
The first seven days tell you whether the launch worked, and they are when problems are cheapest to fix. This list is time-boxed so you do not stare at dashboards all day. Each item has a reason and a way to check. Your tools will differ; the questions stay the same.
Day 0 (launch day): is it alive?
| # | Item | Why | How to check |
|---|---|---|---|
| 1 | Install the live store version on a clean device | The store build can differ from your test build | Install from the store, not from a test link; do the core task |
| 2 | Check crash and error reporting shows the live build | No data means you are blind | Find the live build number in the dashboard |
| 3 | Check the backend: errors, response times, load | Launch traffic hits real limits | Open your server dashboard at set times (for example morning and evening) |
| 4 | Check sign-up and, if you sell, purchase with a real account | These are where launch problems cost most | Complete both yourself |
Days 1-3: what breaks?
| # | Item | Why | How to check |
|---|---|---|---|
| 5 | Read every crash group once a day | Early crashes are usually few and fixable | Sort by affected users; note device/OS patterns |
| 6 | Read every store review and support message | Early reviews set the tone | Answer politely and specifically; see replying to reviews if you have not set a style |
| 7 | Check onboarding drop-off, if you track it | The biggest leak is usually early | Compare steps completed vs. started |
| 8 | Ask a few real users one question | Numbers say what, people say why | Send a short message to those you can reach |
| 9 | Decide hotfix or not: crash on a main flow, data loss, payment error | These justify a fast update | Write the rule down before you need it |
Days 4-7: what to learn?
| # | Item | Why | How to check |
|---|---|---|---|
| 10 | Group feedback by theme | Repeats matter more than single complaints | Fill a tracker and count |
| 11 | Decide what to fix next | Without a decision the list just grows | Use impact over effort: how to prioritize app feedback |
| 12 | Check the store listing: do screenshots/text promise something the app does not do? | Mismatch shows up as bad reviews | Compare review wording with your listing |
| 13 | Reply to anyone who got a fix | Closing the loop earns trust | Mention the version in your reply |
| 14 | Write a short review of the week | Next launch benefits | Three lines: what broke, what surprised you, what to change |
Template: daily log
Date: [ ] Live version: [ ]
Crashes (new / total): [ ] Top crash: [ ]
Reviews / messages read: [ ] Themes: [ ]
Backend issues: [ ]
Decision today: [ ] none [ ] hotfix [ ] next release
Adapt it
Solo developer: do days 0-3 in two short sessions per day. Team: assign one owner per row. Skip rows you have no tooling for, but note that you are blind there. Do not ask users to rate the app in exchange for anything; replies and fixes are your job, ratings are theirs.
Related
- Hub: Mobile app testing checklist hub
- App update release checklist
- Checklist for releasing a new app language
AppReviewX gives you private, structured feedback you can use in days 4-7 before more users see the same problem. One feedback = 1 credit; new accounts start at 0. Start free.