Use App Store evidence to screen a SaaS direction.

Step 1 — Define the user, workflow and claim

Start with a person doing a task, then write the claim you want the sources to challenge. “Contractors need to revise and approve an estimate after a site visit” identifies a proposed workflow. “Existing mobile-first products omit client approval and desk access” is a premise that descriptions can contradict.

A category such as Productivity or a label such as AI does not define that task. Specify what happens before and after the step, who takes part, and what would make the premise wrong. At this stage, the user's problem and willingness to pay are hypotheses.

Use the listing evidence guide to distinguish captured fields, developer claims and your own interpretation before comparing them.

Step 2 — Build a candidate pool you can explain

Search the App Store research catalog with words used for the task, then record the categories, matching field, release window and sample selection. Check each selected full description for relevance. A text match is a candidate, not a confirmed competitor.

The published estimating screen used rule estimates-summary-v1: Business, Productivity or Finance, with invoice, estimate, quote or billing in the first 180 description characters. The US snapshot of 23 October 2026 returned 1,474 candidates. AI-assisted analysis covered the full descriptions of the sixteen with at least 50 ratings; twelve were relevant and four were adjacent or unrelated.

That rating threshold selected a reading sample. It did not prove demand or establish that lower-rating products were irrelevant. A small result set is a reason to check wording, coverage and older competitors, rather than a verdict on the market.

Step 3 — Compare full workflow claims and look for counterexamples

For the same task, note each product's claimed input, action and output. Record who approves, signs, edits or receives the result. Include browser, desktop or team access when relevant; a mobile listing may advertise those steps too.

In the estimating case, the proposed absence of approval and desk access met these counterexamples in the captured descriptions:

Scroll horizontally to see all columns ↔

These are facts about what the developers advertised, not independently tested capabilities. The six-product claim comparison provides the wider comparison and selection limits. Missing wording in a summary or table does not prove that a feature is absent.

Step 4 — Decide what the source check changes

Separate a contradicted premise from an unanswered question. If the claim is that no selected product advertises a workflow, a relevant counterexample is enough to challenge it. If the claim is about quality, adoption or willingness to pay, descriptions alone cannot decide it.

• Contradicted: drop or narrow the specific premise. Keep the source and reasoning so another reader can check the decision.
• Not found in the selected copy: record the gap as unknown. Broaden the search and examine older mobile and SaaS products before treating it as an opportunity.
• Outside listing evidence: define a separate check, such as using the existing workflow or speaking with prospective customers about a recurring problem.

Four shortcuts that weaken a research question

• Category as a customer: listings share an Apple category, but you have not identified the person and task you want to compare.
• Technology as a workflow: several descriptions say AI, but promise different inputs, actions or outcomes.
• Ratings as demand: the public count helps describe the source sample; it does not establish customers, recurring use or SaaS willingness to pay.
• A browser as the opportunity: moving an interface to the web does not by itself establish an unserved task. Check what the mobile products and existing SaaS alternatives already offer.

Write a research brief for the next decision

Use the same fields for each direction so that a source fact, an interpretation and the next research task stay separate. Here is the completed brief for the estimating example:

Proposed user and task

Contractors revising and obtaining client approval for an estimate after a site visit. This is the workflow under investigation, not a recorded customer interview finding.

Premise

Existing mobile-first products omit approval and desk access.

Source scope

US snapshot, 23 October 2026. Rule estimates-summary-v1: 1,474 candidates; sixteen full descriptions analyzed with AI assistance; twelve relevant.

Source result

Selected descriptions already advertise signatures, browser approval or web access. Reject the absence premise.

Still unknown

Workflow quality, older mobile and SaaS competitors, recurring customer problems and willingness to pay.

Next evidence

If pursuing a different claim about quality, test the existing approval flows and investigate a specific customer's current process. Record that work separately before drawing a demand conclusion.

For a new source screen, open the catalog with a task and a selection rule in mind. The source page explains the frozen first-release window; the methodology defines evidence labels and separates App Store facts from Google keyword reports.

Method wording updated 30 October 2026. The worked example uses the recorded 26 October source analysis of the 23 October snapshot; no new capture, product test or customer validation was performed for this guide.