Methodology

How Boost.cards builds its calculators, comparisons and editorial frameworks. Formulas, assumptions, review cadence, accessibility.

MethodologyLast verified 2026-09-22Updated
Illustration of Boost.cards research methodology with source documents, citations, verification, comparison criteria and update checks.
Illustration of the Boost Cards methodology.

How calculators are built

Every calculator on Boost.cards runs client-side in your browser. The inputs are private — they are not transmitted to a server. The formulas are written in plain math and published on the calculator page itself.

The formulas are deliberately simple enough to be auditable in five minutes by anyone with a calculator. If a formula becomes more complex than that, it is replaced with a simpler equivalent.

  • Inputs: declared in plain language with units.
  • Formula: published on the page.
  • Assumptions: named, with their default values shown.
  • Output: clearly labeled — what number is shown, what it means.
  • Limits: stated where applicable.

How software comparisons are built

We do not maintain a leaderboard. Each comparison is a transparent evaluation framework: the criteria are listed, each criterion explains what to look for, and named vendor archetypes describe the kinds of products you will find.

Where we link to a vendor we cite a public page from their documentation, not invented test scores. We do not invent review scores, customer counts or satisfaction figures.

Illustrated loyalty-program ROI calculator with inputs, net contribution, break-even result and an incremental-revenue chart.
Example values only; formulas and live calculator outputs take precedence.

Editorial review cadence

Each pillar, guide, resource and comparison carries a "last verified" date. We re-check material on a rolling basis, prioritized by what is most likely to change (compliance rules, vendor archetypes, calculator formulas).

We do not promise real-time updates. Where a number is sensitive to recent change, we say so on the page.

Accessibility and performance

We target WCAG AA accessibility and strong Core Web Vitals. Build sizes are small; pages render on slow connections; keyboard navigation works everywhere; reduced-motion behavior is honored.