Editorial standards

How We Review Wellness Apps

A public method for checking workflow, access, evidence, privacy, limitations, and conflicts of interest.

Direct answer

We compare apps by the task they help a person complete.

Star ratings alone do not decide a recommendation. Every comparison checks the current workflow, platform, account and price model, AI use, public privacy disclosures, evidence and claims, accessibility information, safety limits, meaningful drawbacks, and who may be better served by another option.

A public-source comparison is not the same as a hands-on test, privacy audit, security audit, healthcare endorsement, or legal-compliance review. Each page states which level of checking was completed and when the facts were last reviewed.

Ownership disclosure

Alex Zah creates and sells some products that may appear in these comparisons. When an AlexZah product is included, the comparison says so near the first recommendation, applies the same fields to every option, names meaningful drawbacks, and explains when another product may fit better.

What we check

  1. The decision. We define one concrete job instead of mixing unrelated needs to make a longer list.
  2. Inclusion. A product must be currently available, directly relevant, and documented well enough to compare. There is no paid inclusion.
  3. The workflow. We record what a person actually does: write, choose fixed options, listen, use a timer, chat with AI, track progress, or follow a guided sequence.
  4. Access and total cost. We check platform, region, account need, free access or trial, one-time price, subscription, and the date and currency reviewed.
  5. Privacy disclosures. We read the store label and public policy, then separate reflection content from accounts, analytics, identifiers, AI processing, export, and deletion.
  6. AI use. We check what input AI receives, whether writing or voice is required, what memory is described, and whether a non-AI route exists.
  7. Evidence and claims. We look for research on the exact product first and keep broader method evidence separate from product evidence.
  8. Usability and accessibility. Public documentation can support platform or declared accessibility facts. Quality judgments require a dated hands-on check.
  9. Safety and scope. We make limits visible, keep urgent-support guidance separate from promotion, and do not present an app as a replacement for professional or crisis support.
  10. Conflicts and fair concessions. Owned products receive the same criteria, and comparisons name cases where native mobile access, free use, a different workflow, community, or another documented feature is the better fit.
  11. Freshness. Official product, store, price, AI, account, and privacy sources are rechecked before a deployment manifest and after material changes.

The three evidence layers

Developer claims, independent evidence, and editorial fit judgments do different jobs. Repeating a store or developer claim does not make it independently verified.

LayerWhat it can supportHow it is written
Official product or store sourceFeatures, platform, current price model, developer privacy statements, and version date.Attributed to the developer, store, or policy when the source matters.
Independent sourceGeneral evidence, official guidance, or research on the exact product.With the design, population, date, limitation, and whether the exact app was studied.
Editorial inferenceA best-fit or limitation judgment drawn from disclosed facts.Labelled as a fit judgment, never turned into an effectiveness fact.

How we label the level of checking

Level 1

Official sources checked

Current developer, store, and privacy pages were reviewed. No runtime claim is implied.

Level 2

Hands-on flow checked

A dated session record covers the named flow, device, platform, and checks described on the page.

Visible limit

Claim not verified in app

A material feature, price, AI behavior, offline mode, account behavior, or other fact could not be checked directly.

What store privacy labels can and cannot tell you

Apple requires developers to describe data practices for their own code and integrated third-party partners, and to keep those answers accurate and current. Google likewise states that developers are responsible for complete and accurate Data safety declarations, including third-party libraries.

Those labels are useful first-party disclosures, not independent audits. We also check the full public policy for writing or voice input, account storage, analytics, session replay, advertising identifiers, AI providers, export, deletion, and regional details. An app is not described as “private” merely because a developer says it does not sell data.

How we handle AI

AI is treated as a decision factor, not a quality badge. A comparison records whether AI is present, what it processes, whether writing or voice is required, whether history or memory is described, and whether a non-AI route exists. If the public policy does not explain the processing, the comparison says that the detail could not be verified.

How we handle owned products and alternatives

Ownership is disclosed before the first AlexZah recommendation and beside the relevant action. The comparison uses the same source date and fields for owned and third-party products. It also names a meaningful limitation and points to alternatives when they offer a better documented fit.

The default is a fit-based set of options, not a universal “best overall” winner. There are no self-serving star ratings or aggregate review scores.

What this method does not claim

  • It is not a legal or regulatory compliance opinion.
  • It is not a penetration test, code audit, or independent verification of a developer's privacy statements.
  • It is not professional-care guidance or an assurance that an app fits every person.
  • It does not guarantee effectiveness, safety for every situation, or continuous availability.
  • Store labels and public policies can be incomplete, inaccurate, or changed; every comparison therefore shows a review date.

Correction policy: When a material fact is wrong or becomes stale, the visible comparison and its source record are corrected together. A price, access model, privacy statement, or availability conflict is not kept merely because it once matched a source.

Common questions

Do you test every app yourself?

No. Every product is labelled as official-sources checked, hands-on flow checked, or not verified in the app. The label states what was and was not checked.

Do companies pay to be included?

No paid inclusion is accepted under this method. Any future sponsorship or affiliate relationship would need a separate visible disclosure and could not change the criteria.

How do you review apps made by Alex Zah?

The page states Alex's ownership, applies the same fields and review date, names meaningful limitations, and points to alternatives when another option fits better.

Why do privacy labels need a full-policy check?

Store labels summarize developer declarations. A full policy may add detail about accounts, writing or voice input, analytics, session replay, AI providers, deletion, and regional differences.

How often are comparisons updated?

Facts are rechecked before publication, after a material product change is discovered, and during scheduled portfolio reviews. Every comparison shows its review month.

Does a high app-store rating mean an app works?

No. Ratings can be useful user-feedback context, but they do not establish evidence quality, privacy quality, accessibility, or fit for a particular person.

Sources and version record

Method version 1.0 · Published August 2026 · Facts rechecked before every comparison release