Methodology

How we score and compare fitness software

This page documents the data model, scoring system, and editorial standards that govern every page on this site.

Data model

The platform is built on a structured database, not a content management system. Every public page is generated from the following data entities:

  • Vendors — software platforms with factual attributes (headquarters, founding year, pricing model, target segments)
  • Categories — software categories (e.g., gym management, class booking, studio management)
  • Features — individual product capabilities that can be compared across vendors
  • Vendor features — which vendor supports which feature, with notes and source linkage
  • Scoring rubrics — defined criteria per category, each with a weight and maximum score
  • Vendor scores — a vendor's score for each rubric criterion, with source linkage
  • Sources — public evidence backing factual claims (vendor documentation, press releases, public filings)

Scoring system

Each ranking is scored across nine top-level criteria, each weighted by importance and scored out of 10 points. Every criterion is broken down into subcriteria — specific buyer outcomes like "Class scheduling depth", "Mobile member experience", or "Core business reporting" — with each subcriterion using predefined depth levels.

Production criteria and weights

  • Scheduling & Booking (25%) — class scheduling, self-service booking, waitlist, staff scheduling, multi-location, booking rules
  • Member Experience (15%) — mobile app, branded app, member self-service, communications, check-in, engagement
  • Payments & Memberships (15%) — recurring billing, memberships, integrated payments, failed-payment recovery, discounts, billing admin
  • Studio Operations (10%) — multi-location, staff, roles & permissions, check-in/access, rooms, data admin, automation
  • Marketing & Growth (10%) — lead management, CRM, marketing automation, email/SMS campaigns, attribution, referrals
  • Reporting & Analytics (10%) — core reporting, revenue, attendance, membership/churn, marketing, multi-location, custom/export
  • Integrations & Ecosystem (5%) — API, webhooks, integrations directory, accounting, marketing, hardware, automation connectors
  • Pricing Transparency (5%) — pricing page, starting price, plan names, plan prices, fees, quote requirements, contract terms
  • Customer Satisfaction & Support (5%) — independent review satisfaction (weighted by publisher group) and support depth

Each subcriterion uses predefined depth levels: NONE, BASIC, STANDARD, STRONG, and COMPREHENSIVE. The rubric defines which evidence predicates are needed for each level before any vendor is evaluated. The evidence determines the level — no subjective judgement or LLM scoring is applied. A perfect 10/10 requires evidence against every subcriterion including depth dimensions — table-stakes features alone are not enough.

The overall score for a vendor is computed as follows:

normalized = raw_score / max_score

weighted = normalized × weight

overall_percentage = (sum(weighted) / sum(weight)) × 100

Two separate outputs are tracked for each criterion: fit score (how strongly the evidence demonstrates the vendor satisfies the buyer requirement) and evidence readiness (how completely we can evaluate the vendor against the rubric). Fit score is not inflated by more complete evidence, nor reduced by less complete evidence. Instead, readiness determines whether a score is reliable enough to publish.

Vendors are classified as EVALUABLE (sufficient evidence for a reliable published score), PROVISIONAL (useful but incomplete evidence), or INSUFFICIENT_EVIDENCE (not enough evidence to rank reliably). Insufficient evidence is displayed as "Insufficient evidence" — never as 0/10. Ordinal ranking positions (#1, #2, #3) are only published when at least three vendors are EVALUABLE. Until then, vendors are shown as "Currently evaluated" with scores but no definitive ranking position.

Editorial standards

  • No fabricated data. We never invent prices, ratings, features, integrations, review counts, statistics, quotations, rankings, or sources.
  • Traceable claims. All factual claims shown publicly must be traceable to database evidence, including a linked source where available.
  • No promotional language. Vendor descriptions are factual and neutral. We do not write promotional claims because a vendor is commercially important.
  • Defined rankings. Rankings derive from published scoring criteria — not subjective editorial judgment.
  • No paid placements. Vendors cannot pay to improve their ranking or position in any index.

Verification cycle

Data is re-verified on a rolling basis. Each vendor page displays its last verified date. Sources are checked for continued availability. When a vendor changes pricing, features, or product positioning, the database is updated and the verified date is refreshed.

How we handle unverified capabilities

When we cannot verify a capability from approved sources, we display it as "Unverified" — never as "No" or "Not supported". This distinction is critical: "Unverified" means we have not yet found sufficient evidence, while "No" means we have verified the capability is absent. Conflating the two would penalise vendors for our incomplete research rather than for actual product gaps.

Unverified capabilities do not reduce a vendor's score. They reduce the evidence readiness, which may classify the vendor as PROVISIONAL rather than EVALUABLE. This ensures scores reflect what we have verified, not what we have not yet checked.

Review-source independence

Independent review platforms (e.g., Capterra, G2, GetApp) are treated as separate observations. Ratings are not combined or averaged into a single score. Each platform's rating is shown individually with its review count, so readers can assess consistency across sources.

Review publishers are grouped by ownership or affiliation to prevent double-counting. Where two platforms share a parent company or data pipeline, their ratings are weighted as a single independent observation rather than two.

Architecture

Presentation, database access, scoring logic, and content generation are kept separate. Public pages are generated from reusable templates driven by database queries — no vendor rankings or factual claims are hard-coded into page components. This ensures that updates to the database automatically propagate to every relevant page.