Method

• App Store customer reviews

  The public reviews feed, two pages, 85 reviews, each carrying its rating, date and app version.

  https://itunes.apple.com/us/rss/customerreviews/page=1/id=6736954854/sortby=mostrecent/json

• App Store listing

  Current version and release dates.

  https://itunes.apple.com/lookup?id=6736954854&country=us

• Google Play reviews

  78 reviews read with google-play-scraper 1.2.7, an open-source reader. Twenty carry a public developer reply.

  https://play.google.com/store/apps/details?id=com.reventure.mobileapp

• Web app page source

  Kept verbatim. Read for the observation on this page, not for a draft.

  https://www.reventure.app/

• Web app sitemap

  Twelve routes, including the cancellation route the second draft starts from.

  https://map.reventure.app/sitemap-0.xml

• Both stores were read in full, every review, rather than counted by keyword. Keyword totals were deliberately not used: they merge unrelated complaints, and they cannot tell a report from an opinion.
• A theme became a draft only where several distinct reviews describe the same thing. A single report stayed a single report, and where it was worth recording it went to the product list in the export instead.
• A developer reply was read alongside the review it answers. A reply can change how a report is read, by explaining a limit or naming a follow-up. None of them is treated as a resolution.
• Two reviews support two drafts each, for different reasons, and both are named below. Nothing is counted twice.
• No priority was assigned. The order is a suggestion with its reason attached, because what is already in flight is not visible from outside.
• The drafts were then read again, cold, against the full corpus and the developer replies, with the option to merge one, demote one, or drop one. What that pass changed is recorded in report.json.

• Every quote is verbatim from the raw corpus kept with the project, and the build fails if a quote is not found literally in it.
• Every count is recomputed from the raw files rather than written by hand, and the page, the CSV and the JSON are checked against each other.
• Reviewers are never named, and no reviewer name is read out of the source in the first place.

A suggested verification order, with the reason for each place in it and the condition for moving it to development. It is not a sprint and it carries no commitment: the team's own backlog and whatever is already in flight decide that, and neither is visible from here.

1. 1Verify paid access when home listings return "unauthorized"First, because it is the only one of the four where money has already changed hands before anything goes wrong, and because the three accounts can be looked up today without shipping anything.
2. 2Confirm purchase channel and subscription state behind reports of billing after cancellationSecond, because it is the other one that touches a charge, and because the first step is reading three account records rather than changing anything.
3. 3Attempt to reproduce the Android startup freeze reported on 44.11Third, because the first step costs one console query, and because the answer may well be that there is nothing there, which is worth knowing early.
4. 4Check how a store review is matched to an account before a public replyLast, because it changes nothing for a user today, and first among the ones that would make every later report easier to answer.

• Google Play, Dec 2025, v43.2, on RVD-2 (body) and RVD-4 (reply). The review text and the public reply under it say different things.
• Google Play, Aug 2026, v44.11, on RVD-3 (body) and RVD-4 (reply). The review text and the public reply under it say different things.

• Everything behind the sign-in wall: the map, the reports, the listing analyser and the cancellation screens. Every draft here is written from the outside, from what people described.
• Crash and ANR rates, which live in the two store consoles. That is why the Android draft starts with a console query rather than with a hypothesis.
• The help desk. The twenty public replies are all that is visible of it.
• Whether a report was already handled, already has a ticket, or was fixed in a release. A version number on a review is what the reporter had installed, not a record of what shipped.

• Store reviews are a biased sample: people write after a delight or a failure, rarely in between. Nothing here measures how often something happens, only that it was written down and when.
• The App Store sample is the United States storefront. Other storefronts hold almost nothing, so anything specific to another country is invisible here.
• A review can belong to more than one theme. The samples are never added into a score, and where one review supports two drafts it is named below.
• Everything here was collected on 13 September 2026. Reviews posted since are not in it.
• These are drafts prepared from public text. None of them has been reproduced in the app.

The CSV is the short path: an admin imports it and maps the columns, which takes a few minutes. The JSON is the same drafts as an API body, with the descriptions already in Atlassian Document Format, for anyone who would rather post them than click. Neither invents a field: no assignee, no sprint, no priority.

A report that something did not work the way the person expected can be investigated, so it becomes a draft. A request for something that does not exist, or a view about what a plan should include, is a product conversation. Those are in the export, not here.

Nothing here was reproduced in the app, no account was accessed, and no cause is claimed. Each draft says what to check first and what would end the check, including the case where the answer is that there is not enough information and the open question has to be asked.

The product requests, the record of what the cold reread changed, and every citation with its identifier are in report.json. The drafts themselves are in tickets.csv and tickets.json.