How to read the per-user table on this site

Every table here has the same columns: published per user, the billing basis, the minimum users, the fixed charge, and the effective cost per user at a stated team size. The ordering is that last figure, ascending.

Two things mislead a fast reader: a table read at the wrong team size, and an optional charge mistaken for a required one.

The pages on this site are generated from one dataset by one script, so the columns behave identically everywhere. Learning them once makes the whole site readable.

The columns

Published per user. The figure the vendor prints, copied exactly and never converted between currencies.

On. Whether that figure is the annual-billing or the monthly-billing rate. Vendors advertise the annual one more often, and where both are published the table shows both.

Min users. The number of users billed regardless of how many you have. Where a plan has one, every computed figure already includes it.

Fixed charge. A monthly amount that does not change with headcount, marked *required* or *optional*. Only required charges are counted.

Effective per user. The computed figure: the monthly total divided by the people who will actually use it. Tables sort on this, at the team size named in the caption.

Above published. How far the effective figure sits above the vendor's own per-user price. A plan at 1.0x charges what it advertises at that size; 4.3x means the advertised price described a different customer.

The formula, in full

users billed = max(users you have, minimum users the plan bills) monthly total = per-user price x users billed + required fixed charge effective per user = monthly total / users you have three-year cost = monthly total x 36 + setup fee

Nothing else is added. Optional add-ons, taxes, device overages and the work of moving are all excluded — what is not in the price lists each one.

Why the ordering is one number

Because a weighted score is a place a commercial interest can hide.

The directories in this category rank by star ratings whose inputs and weights are not published. A single computed sort key removes the possibility: there is no weight to nudge, and anyone can recompute the order from the published dataset and get the same rows back. What a star rating is not is the longer version of this argument.

Ties break on the published per-user price, then alphabetically. That is the whole rule.

The first place a quick read misleads you

Reading a table at the wrong team size. Every ranking page names its size in the caption, and the order genuinely changes between two users and fifty. NordLayer Core, with a five-user minimum and a $40 fixed charge, is the most expensive plan on the page at two users and mid-table at fifty.

If your number is not the one in the caption, use the calculator, which takes any team size and re-ranks the whole dataset against it.

The second place a quick read misleads you

Treating an optional charge as required. A dedicated IP or extra gateway is sometimes a requirement of the plan and sometimes a shopping choice, and the tables mark which. Our arithmetic counts only the required ones, so a row can look cheaper here than a vendor's own configurator suggests if you add extras the plan does not require.

The tables show the optional charges so you can disagree with where the line was drawn.

The pages this dataset produces

Four kinds, all generated from the same rows:

Vendor pages — every published plan for one vendor, with the effective cost at 2, 5, 10, 25, 50 and 100 users.
Head-to-head pages — two vendors' cheapest plans at every one of those sizes, plus the point where the answer flips.
Alternatives pages — the nearest vendors in the same category, in cost order, at three sizes at once.
Size pages — every plan a team of a given size could buy, in order.

None is written by hand and none can be edited by hand: a hash check fails the build if a generated page differs from what the script would produce. If a figure is wrong, the fix goes into the data and every page carrying it changes at the next build.

Rows you cannot rank

Some vendors price per server or per device rather than per user, and some publish nothing at all. Those rows are kept, shown, and left out of the per-user rankings rather than forced into them — the units article explains why mixing them would be a category error, and the vendors that publish nothing covers the rest.

Who this is not for

If you want to be told which product to buy, these tables will not do it. They order plans by one published-price computation and stop. They know nothing about how these products behave on a bad network or how their support desks answer.

Questions people ask

Why is ten users the default? Because it is the size where most of these self-serve plans are actually bought, and because it sits above the common five-user minimum so the ranking is not entirely about minimums. Every page states its size.

Can I get the underlying data? Yes, at data.json under CC BY 4.0, with the source URL and check date on every figure. Recomputing the tables from it is the intended use.

What happens when a price changes? The row is re-read and re-dated and every page carrying it is regenerated. Any figure older than 90 days is automatically labeled as not re-checked.

Sources

All figures and counts come from data.json, which carries a source URL and check date for every row.
The sort key, tie-break rules and the full formula are on the method page.
Individual vendor pricing pages are linked from every row in the vendor list.

Written by Kaz (pen name). Figures are copied from providers' published pricing pages on the dates shown. We have not used these products. Corrections: contact form.