In this guide
A one-star review hurts because you built the thing. That is normal. The trick is to read it as data about a user's experience, and to do so on a schedule rather than at midnight.
1. Create distance
- Read reviews in a fixed slot, for example twice a week, not on every notification.
- Copy the text into your tagging sheet before you react. Tagging is a calm task.
- Do not reply the same minute you read it.
2. Split the review into parts
Most one-star reviews hold three things mixed together:
- Fact: "Crashes when I open settings."
- Feeling: "Terrible, waste of time."
- Expectation: "I thought it was free."
Keep the fact, note the expectation, let go of the feeling.
3. Turn the fact into a test
Write each fact as something you can check.
Example: "Crashes when I open settings" becomes "Open settings on a low-memory phone and on the latest OS version; watch for a crash." Then test, reproduce, fix, and write down the result.
If you cannot reproduce it, ask: is it one device, one OS version, one account state? A few testers on varied devices help here. Private tester feedback is the quick way to learn that.
4. Look for the pattern
One review is a signal; a repeat is a priority. Count tags weekly. The expectation mismatches point to your store page, not your code: fix screenshots and text.
5. Decide, then close the loop
Choose for each theme: fix, investigate, explain, or accept. Then:
- Reply once, politely, when you have something concrete. See how to reply.
- Say in your release notes what changed.
- Look at the next reviews for the same tag.
What not to do
- Do not ask the reviewer to delete the review.
- Do not offer a reward for a changed rating.
- Do not write off every complaint as "a troll". Some are; check before you decide.
Method for the whole backlog: turn app reviews into a roadmap.
Start free to get structured feedback before the one-star review arrives.
Related: hub, tone and law of replies, review count and trust for small apps.