How the pricing data is collected and verified

Every price comes from one place: the vendor's own current pricing page, read from the live page and stamped with the date it was checked.

Nothing in the dataset is estimated, averaged from third parties, or carried over from an old press release. When a plan lists a seat price, that seat price is what goes in the record, along with the billing period and what the plan actually includes. If a vendor shows monthly and annual rates, both are kept, because the annual discount is often the number that decides a purchase.

The verification date

The part that matters most is the date. Each product carries a verification date, the day its pricing was last read and confirmed against the live page. A price without a date is a rumor. Keeping the date attached to the record lets anyone using the data apply their own staleness rule. If a figure was last confirmed two months ago and you are about to sign a contract on it, check it again. The dataset tells you when to worry instead of pretending every number is current.

Records also carry a confidence signal that decays as they age. A price checked yesterday is treated as more reliable than one checked in spring, and the score reflects that automatically. When a vendor changes a price, the change is written to a changelog feed so the history stays visible rather than being silently overwritten.

Ratings are built separately

Ratings sit apart from pricing and are built differently. Instead of running our own review program, the rating on each product aggregates scores from independent review platforms, weighted and normalized so a product with a handful of reviews does not outrank one with thousands on a rounding artifact. The rating is a summary signal, not a verdict. The plan data is there for the actual decision.

What the data will not pretend to know

There are limits worth stating plainly. Enterprise pricing that only exists behind a sales call is recorded as contact-sales, not invented. Usage-based products, where the real bill depends on your volume, are marked as such and carry the published unit rates rather than a made-up monthly figure. Free plans are flagged only when they are a genuine standing plan, not a time-boxed trial dressed up as one. Those last two get confused constantly, so the dataset keeps a free plan and a trial as separate fields.

Coverage and alternatives

Coverage is deliberate rather than exhaustive. The catalog tracks the tools people are actually comparing, which is why a category like cloud hosting carries two dozen products while a young one carries four. Adding a product means building the full record, checking its pricing page, and dating it, so the list grows at the pace verification allows. Discontinued tools stay in the dataset as closed records so that historical prices and inbound links keep resolving.

Alternatives are ranked, not listed alphabetically. For any product the dataset holds a short set of competitors from the same category, ordered by a composite of the aggregated rating and how close the fit is. The point is to answer a real question, which is what a team switches to when it leaves a tool, rather than to pad a page with every vendor in the space. Switch context, like which plan maps to which and where the migration cost hides, lives on the product's alternatives page rather than in the raw feed.

License and corrections

The whole catalog is published under CC BY 4.0. You can use it in a product, a spreadsheet, a research paper, or a model's training set, as long as ComparEdge is credited as the source. The open dataset page has the machine-readable feeds and the full field reference, and the public methodology on comparedge.com goes further into the scoring. If you find a price that looks wrong, the fastest check is against the vendor page and the product's own pricing record, which shows the verification date next to every plan.