How to compare SaaS tools without believing the comparison sites

Comparison sites are not research. Most are paid placement or affiliate lists, and their matrices are assembled from vendor marketing pages. The comparison worth trusting is one you run yourself: the same task in each candidate, done by the person who will do it weekly, on your data, priced at the exit rather than at the entry. The exception is a tool that holds neither money nor records — a diagramming app, a form builder — where an afternoon of use genuinely settles it.

Why the comparison sites say the same thing

They earn when you click through and sign up, their categories exist so that every product fits one, and their tables are filled from the vendors' own lists. Absence is invisible in such a table: a missing capability is an empty cell nobody explains, and a feature that exists but is unusable looks exactly like one that works.

These sites are a directory: good for producing candidates, useless for choosing.

What a feature matrix cannot tell you

A matrix compares nouns. Buying decisions turn on verbs: who may approve, what happens when colleagues edit the same record, how a mistake is undone, what the export contains, how long a deleted item stays recoverable, whether the person at the counter can finish a task without calling support.

None of that is on the vendor's page, because it makes a poor bullet. It comes out in a trial designed to find it.

Start from your own workflows

Before opening any trial, write down the work the tool must carry — not the department, the work. The order that arrives daily; the exception that arrives weekly and needs an argument settled; the failure, meaning the refund, the rejected invoice, the customer who never answers.

For each, write the steps as they happen now: what triggers it, which fields are read, who acts, what comes out, and what happens when it goes wrong. That page is your requirements document and your demo script at once.

Run the same task in every trial

Give each candidate the same sample and task, and put the person who will use the tool in front of it — not the person who signs the contract, and never the vendor's own screen share. Watch where they hesitate, what needs a workaround, what requires another tool.

Record the workaround, not the impression. "Created the invoice but had to re-enter the customer because the search did not find him" is evidence. "Felt modern" is what most evaluations are made of.

Price the exit before the plan

The cost that decides the purchase is the cost of leaving: what the export contains, what must be rebuilt on the way out, how much integration work is discarded, how much notice the contract wants.

Test the export during the trial. Take the sample out, open it elsewhere, and look for what is missing — relations between records, attachments, history, numbering, the audit trail. Ask what happens to the data once the subscription ends, and whether attachments are included.

Then look at the growth shape. Seat-based pricing is cheap for a pilot and expensive for a warehouse; usage-based is the reverse; a module split means the capability you need later is a new purchase. You are not pricing the first invoice, but the one after the business has grown into the tool.

Who owns the data, and who can prove it?

Ask who controls the data you put in, where it is stored, which subprocessors touch it, and what happens when you ask for deletion — in the contract, not in a sales call.

Then look at access: whether roles are granular enough that a warehouse clerk cannot see margins, whether multi-factor authentication exists and is enforced, whether sessions expire, whether an audit log shows who changed what. A tool that cannot say who edited a price makes that somebody's problem later.

The table you can actually fill in

What to compare	What the vendor claims	What you saw in the trial
The daily workflow	supported	completed, or worked around
The weekly exception	configurable	configured by whom, and how long it took
The failure path	full audit trail	what the log showed, and who could read it
Permissions	role-based access	the role you could actually create
The export	open data	what came out, and what stayed behind
Growth in cost	flexible plans	which lever raises the bill
What to verify on the vendor's page	plan limits and termination terms	whether the exit you tested matches

The decision, in order

1. Write the workflows, including the exception and the failure. A page.
2. Shortlist on pass/fail constraints: where the data must live, the language the team works in, the systems it must exchange records with.
3. Book trials with the people who will use the tool, and give them that page rather than a demo.
4. Run the tasks on your own sample and note every workaround.
5. Export the sample and try to leave while you still can.
6. Compare the growth shape and the exit cost, not the entry price.
7. Write the decision down with its reason, and name the person who owns the tool afterwards. An unowned subscription renews by default.

Where this goes wrong

• The trial run by the wrong person. IT evaluates the admin screen, and the team discovers on day one that the workflow does not fit.
• The pilot that becomes production. Nobody tested the exit because nobody planned to leave, so the first export happens during a crisis.
• Configuration as lock-in. The more the tool is bent to fit, the less any replacement can be, and the configuration lives where you cannot export it.
• Believing "supports Arabic" and "integrates with your accounting". Both are claims until you have typed a mixed-script record and watched one cross the boundary.

When neither fits

If every candidate fails the same workflow, the problem is the workflow or the category, not the shortlist. The honest options are to change the process, or to have the missing piece built and connected to the tools that already work. That is no reason to build everything, only to stop repeating a trial that has answered the question.

Where this advice stops

Prices are left out on purpose. Plans, tiers and seat rates change faster than an article can be corrected, quotes differ by country and by negotiation, and any figure printed here would be wrong before the page aged. This is not legal or accounting advice either: data protection, retention and contract terms need the person who handles those for you. And it assumes you are choosing between tools, not deciding whether to buy one at all — that question comes first and has its own arithmetic.

We build and integrate systems around tools like these, we resell none of them, and we take no commission from the choice.