Tester feedback is only useful once it changes the app. If you build mostly by prompting, the shortest path from a tester's note to a fix goes through a good prompt. A vague prompt gets a vague change, and a change you do not verify can break something else. This page gives you a loop you can repeat for every round of feedback.
The loop
- Collect
- Prioritise
- Write the prompt
- Apply and read the change
- Verify on a real device
- Tell the tester
1. Collect structured feedback
Free-form "it's broken" is hard to act on. Ask testers for the same few fields every time: what they did, what they expected, what happened, device and OS version. A report in that shape can be pasted into a prompt almost unchanged. See how to write feedback a developer can act on and the bug report template.
2. Prioritise before you prompt
Do not send ten reports to the assistant at once. Sort by impact and effort (guide): crashes and blocked core flows first, polish last. Work one issue per prompt. Small changes are easier to check and to undo.
3. Write a precise prompt
A good prompt carries four things:
- Context: which screen or feature, in one or two sentences.
- The report: steps, expected result, actual result, device and OS.
- The limit: "change only what is needed; do not refactor unrelated code".
- A check: how you will know it works, including one nearby behaviour that must stay the same.
Copy-paste version: prompt template from tester bug report to fix.
If you cannot reproduce the problem yourself, say so in the prompt and ask the assistant to explain its guess before it changes code. Do not ask it to "fix everything in this report".
4. Read the change
You do not need to understand every line, but look at what changed: which files, how many lines. A one-line bug that produced a change in ten files is worth a second look. Keep each fix in its own commit or save point so you can step back.
5. Verify on a real device
Run the exact steps from the report on a real phone, ideally the kind the tester used. Then run the nearby behaviour you named as "must stay the same". An emulator is a first pass; the real phone is the proof. See why an emulator is not enough.
6. Close the loop
Tell the tester what you changed and ask them to re-check. People who see their notes used tend to send better notes next time. We do not claim a rate for that; it is simply how feedback becomes a habit instead of a one-off.
When the fix does not hold
- The assistant "fixed" it but the steps still fail: send the same report again with what you observed after the change.
- The fix broke something else: revert, then add the broken behaviour to the "must stay the same" line.
- Two attempts, no progress: describe the problem in your own words, smaller and with less context.
Keep a short log
One line per report: date, issue, device, prompt used, result. After a few rounds you will see which kinds of reports produce clean fixes.
Where AppReviewX fits
AppReviewX gives you private, structured feedback from other developers in a format that fits this loop. One feedback you write earns one credit, credits buy feedback on your own app, and new accounts start with 0 credits.
Related: Vibe coding hub, getting your first honest store reviews, store rejection reasons, real-device testing.
Start free and put the loop to work.