The seat math: editors, readers, and the cost of a front end

The thesis of this article fits in one sentence: when usage is asymmetric, the seat stops being the right unit of purchase, and a custom read-only front end becomes an economic trade-off worth pricing out — not a technical whim. It is falsifiable, and the cases where it does not apply are listed below.

Here is the asymmetry. In most business tools, a minority creates and edits; the majority reads. Five salespeople enter opportunities; ninety-five people — leadership, finance, operations, customer service — only need to see the numbers. Per-seat pricing bills all one hundred the same way.

The order of magnitude takes one line. At $14 per user per month — an entry-level BI seat as priced on August 12, 2026 — 100 seats cost $16,800 per year. If 95 of those seats are only used to read, 95% of your per-user license cost pays for viewing.

A survey of three tool categories, taken on August 12, 2026:

Three publication regimes coexist: public per-seat prices, "starting at" prices with unpriced reader roles, and full quote-only pricing — including for read-only access. The cost of the reader is the least published variable in the market: a mechanism worth knowing before you negotiate.

Several vendors have already decoupled reading from editing. HubSpot makes view-only seats free and unlimited on its paid subscriptions; monday.com does the same with viewers, Asana with guests. Yet three mechanisms limit how far these free roles go.

First mechanism: read-only is strict — the moment a reader comments, fills in a form, or triggers an action, they flip to a paid seat. Second mechanism: in BI and higher-end CRM, the reader stays paid or conditional — Power BI reserves free viewing for F64 capacities and above, while Tableau and Looker sell reading as a license.

"Smaller F SKUs need a paid license to access shared content" — below the F64 threshold, a free user needs a paid license to read shared content (Microsoft Learn, August 12, 2026).

Third mechanism: the scope of the "free viewer" is a contractual clause, not a law of physics. HubSpot introduced its current model for accounts created after March 5, 2024: the definition of a seat moves. A budget built on a free role rests on one line of the terms of service.

A custom read-only front end — a web application that reads the platform's data through its API — is not free either. An honest comparison requires full business-tool TCO on both sides:

Seat cost (3 years)  = readers × seat price × 36 months
Front-end cost (3y)  = initial build
                     + monthly run × 36 (hosting, maintenance, evolutions)
                     + data access cost (API, capacity, residual licenses)
Tipping point: front-end cost < seat cost

A 2010 study (Journal of Revenue and Pricing Management) shows that under competition, usage-based pricing does not mechanically beat flat per-seat fees, notably because of monitoring costs. Per-seat is not an aberration; it is an optimum under certain conditions. That is exactly why the trade-off must be priced case by case — it is the core of how we build: calculate before you develop.

The stakes go beyond economics: they are about audience. A read-only front end does not shrink access to the platform, it widens it — information rationed to a few seats becomes available to the whole organization, even to customers and partners. The F64 mechanism acknowledges this implicitly: broad free viewing is reserved for organizations that pay for access in bulk.

What doing nothing costs — On average, 36% of purchased SaaS licenses go unused, against a median spend of $9,455 per employee per year (Zylo, 2026). On the example of 95 readers at $14 per month, inaction is worth $15,960 per year and $47,880 over three years — not counting the people who, for lack of an available seat, get no access to the data at all.

The table below gives the number of readers past which a dedicated front end costs less than seats, over three years. Seat prices are public rates observed on August 12, 2026; front-end costs are full-TCO assumptions (build + run over three years), to be replaced with your own quotes. The formula: tipping point = front-end cost ÷ (seat price × 36).

The pricier the seat, the lower the tipping point: at $175 per month, ten readers are enough to pay off a $60,000 front end. Below about thirty readers on entry-level seats, a dedicated front end does not pay for itself on licenses alone. And if your tool already offers sufficient free viewers, the tipping point is infinite: the front end must then justify itself otherwise — user experience, customer access, consolidation of several sources. This calculation is the first step of our method.

This math does not apply everywhere. If your tool includes unlimited free readers and strict read-only covers the need, keep the seats: the front end will never pay for itself on licenses. If your "readers" edit, even occasionally, they are editors — the real ratio shows up in activity logs, not on the org chart. Below about ten users, some tools are free and the question does not arise. Finally, a dedicated front end is a software asset to operate: security, API version upgrades, service continuity. Without operating capacity, license savings turn into technical debt. The prices quoted here move; the pages themselves say so.