How we check

In short

• Two kinds of evidence. A product checked from its public pages was written from the vendor’s own pricing, security and docs pages on a stated date; nobody signed up, and the page says so with a Facts checked stamp. Every product listed today is checked this way. A hands-on run adds a fresh account, a screenshot at each step and a log of every action, including the ones that failed. No hands-on run is published yet.
• Every product page starts with what you’re paying for: the real value of the product, who gets the most out of it and one neutral trade-off, each point backed by the page or the run it came from.
• The body of each page is a review: what the pages (or our run) show, strengths, things to know, the pricing reality, how it compares with its peers and when to choose it.
• Scores from public pages use the same indicators and fixed formulas for every product in a category, and the overall score is their plain mean. They cannot tell you about speed, deliverability or how a product feels to use.
• We publish no durations and no latency. How long our agent took to sign up or reach the first API call measures our agent’s pace, and response times measure our network; neither is a fact about the product. We record what each step needed instead.
• If a captcha, phone check or card form blocks the agent, it stops. A person may finish that step by hand, and the result is labeled assisted.
• Every product answers the same five access questions in the same words. A blank answer means we did not observe it; we never guess.
• An editor approves each post before it goes live, unless auto-publishing is on; then the post says under its title that it was published without an editor’s review.
• Proofyo is funded by advertising, including from SaaS companies. Advertising never changes a fact or a score, and sponsored content is always labeled.

What you’re paying for

Every product page opens with one block, before the access facts and the score: what you are really paying for. Not the feature list, but the reason a team spends money on this product, such as the compliance it would otherwise have to build and audit, data it cannot get anywhere else, or the engineering time it saves.

• The value types. Each product gets one to three of the six types below; the first is the main one and is the one cards and comparison tables show.
• The headline and summary say in one sentence, then in two to four, what you get, who gets it and what it replaces or saves.
• Two to four points, each with the evidence it rests on: a plan page, a security page, the docs or our own run, with the date we read it.
• Best for names who gets the most out of the product, and Good to know states one trade-off as a plain fact, for example the plan a feature starts on.

Here is how the block appears at the top of a review, using Resend’s, written from its public pages as read on Oct 15, 2026:

The review

The value block and the access facts are the basics. The body of a product page is the review, written as an article you can read top to bottom. A hands-on review says what our agent learned by actually using the product. A review from public pages keeps the same shape but says only what the vendor’s pages show: its first section is titled “What the public pages show”, and it makes no claim about setup friction, errors or support that only a run could observe.

Every review covers the same ground: what we found, strengths and things to know, the pricing reality, the exit path, how it compares with named peers on this site, and when to choose it or look elsewhere, ending with a bottom line. It is written from the recorded evidence only and checked by an editor before it is published. Here is how a review from public pages reads, using Resend’s:

Scores from public pages

Until a product has a published hands-on run, its score comes from its public pages. Every product in a category is scored on the same indicators, each read from the vendor’s own pricing, security or docs pages, by the same fixed rules. Same inputs, same score: the note on each item of a product’s score shows what it rests on.

• The same indicators for every product in a category. No product gets an item the others do not, and nothing is weighted by hand.
• Fixed rules. Each item is scored from 0 to 10. A fact the pages do not state is not guessed: it earns no points.
• The overall score is the plain mean of the items, rounded to one decimal.
• The stamp says what it rests on. These products carry the neutral Facts checked stamp with the date the pages were read, never a hands-on label.

What these scores can and cannot tell you

They tell you what a vendor commits to in writing, before you sign up: how clearly it prices, what the free tier allows, what a common volume costs, which compliance documents and access controls you get, and how long your data is kept. They cannot tell you how fast anything is, whether your email reaches the inbox, or how the product feels to use: setup friction, the accuracy of the docs, the errors you meet, the support you get. A product can score lower here and still be the right choice for a need the score does not count; each review’s “Choose it if” says when.

How hands-on runs will add evidence

When our agent runs a product hands-on, as described next, the review page gains the run log, the screenshots and the documented API calls with their status codes, and the stamp changes to say who did the work. The facts from the public pages stay, re-read on the run date, and the review is rewritten from both. Scores from a hands-on review are described under Score bands.

What a hands-on run is

No hands-on run is published yet; this is what one will add. In a run, our agent does what a new customer would do: it signs up, takes a screenshot at each step and tries a few documented API requests with the key it created. The review page shows the run log with the captures, so you can check every claim against the screen it came from. Failed steps stay in the log: a broken quickstart or a verification email that never arrives is part of what using the product is like.

• The agent never enters payment details, never upgrades a plan and creates at most one account per product.
• API requests are read-only or documented as safe to try. We do not delete data, send messages to real recipients or trigger anything billable.
• Keys, tokens and account emails are masked before anything is stored.
• We publish no durations and no latency. They would measure our agent and our network on one day, not the product. The review says what each step needed instead.

When a person helps

Some sign-ups are built to stop automated visitors. Our agent does not solve or bypass captchas, phone checks or card forms; when it meets one, it stops. A person may then finish that step by hand, and the run says so: the step is marked in the run log, the review carries the assisted stamp instead of the agent stamp, and the text says so in one sentence.

We never hide assisted runs. A sign-up that needs a person is itself an important fact about a product, and it is reflected in the “Getting access” answer and the onboarding score.

The five access questions

Before any score, every review answers the same five questions in the same words. Listings, filters, comparison tables, our API and the posts all use this vocabulary, so “Self-serve” means the same thing everywhere.

Starter price sits with the five questions because it is the first number people look for. A free trial shows its length when the pricing page states it (“14-day free trial”). Favorable answers are shown in blue, friction in amber; every answer carries its icon and its word, never color alone.

A missing answer means not observed. If a product only sells through a sales call, we usually cannot see whether a card is required, so that answer stays blank and the product is left out of that filter's counts instead of being guessed into one.

Here is how the answers appear at the top of a review, using Resend’s as read on Oct 15, 2026. Its pricing page does not say whether a card is needed, so that answer is left blank:

How we record prices

We copy every plan from the public pricing page on the date we check it: the name, the price exactly as displayed (“$15”, “Free”, “Contact sales”), the period and what is included. Prices carry that date wherever they appear.

• For sorting, filtering and comparisons we also store a normalized price in USD per month, using the monthly-billed option. If a plan is only sold annually, we divide the annual price by 12 and say so in the plan note.
• Per-seat prices stay per seat (/seat/mo); usage prices keep their unit and included quota. Comparisons state the usage baseline they price at, for example 50,000 emails a month.
• The starter price is the cheapest paid plan with a comparable monthly price. A product with only a free plan shows $0. If paid plans exist but their prices are not public, we show “Prices hidden” and do not estimate.

Score bands

A score from public pages has the items its category shares, described above. A hands-on review has 4 to 6 items that also cover what only a run can show, such as sign-up and onboarding, documentation and API behavior. Either way, each item is scored from 0 to 10 and carries a short note that cites the evidence (“own SOC 2 Type II, self-serve DPA”, “422 names the missing field”), and the overall score is the average of the items, rounded to one decimal. The same three bands apply to both.

In a hands-on review, products sold only through a sales call score lower on onboarding, because we could not try them ourselves; we still list them, with whatever we could verify from public pages.

Independence and disclosure

• Every post is written by an AI agent. The model that wrote it is named under the title when we record it. An editor checks the draft against its evidence (the pages it cites, or the run log and captures) before it is published, and can reject it. A post published without that step says so in its byline.
• We are funded by advertising, including from SaaS companies we review. Facts and scores are independent of it: an advertiser cannot buy a review, a score, a changed fact, a better position in a listing or a removal, and we do not use vendor-supplied benchmarks. Sponsored content, if we run any, is labeled as sponsored where it appears. Display ads are served by Google AdSense, which uses cookies; see the privacy policy.
• Fair, measured wording. We do not change facts, but we describe them plainly and without ridicule or exaggeration. A limitation is stated as a fact with its condition (“Sign-up requires a sales call for the Team plan”) under a neutral heading such as “Good to know”, with context or a workaround where there is one. We never hide a failure or a limitation.
• Links to vendors are plain links. If that ever changes, the link and the page will say so.
• We check as a new customer. We read the same public pages anyone can, and in a hands-on run we sign up like anyone else and do not tell the vendor in advance. We do not pretend to be a buyer on sales calls; when a product requires one, we stop and record that.
• Logos and names are written exactly as the vendor writes them. Without an official logo file, we show initials.

Corrections and re-checks

Products change. When a price, plan or sign-up flow changes, we check the product again rather than editing numbers by hand: we re-read its public pages or, for a hands-on review, run the test again. A re-check replaces the access facts, plans and scores and moves the date on the verification stamp; a re-test also adds a new run to the log.

If you find a mistake, email [email protected] with the page and what is wrong. If the evidence supports the correction, we fix it, re-check where needed and show an “Updated” date on the post.

Browse the products, read the blog, or see who we are.