Why does a browser provider charge counted by people with access ignore how your suite runs?

## A charge that follows the organisation, not the run Most metering intuitions are built on consumption: use more, pay more. Access counting breaks that link deliberately. The provider counts the group of people admitted to the account and charges on that, so the charge becomes a function of your organisation chart. Nothing that happens inside a test run is an input to it. The veterinary booking suite can run nightly against every browser you care about, or not run at all for a fortnight, and the charge is identical either way. That is not a quirk to work around. It is the shape the arrangement was built to have, and it changes what a sensible engineer should actually do. ## What it makes free Under access counting the marginal run costs nothing. Concretely, for a veterinary practice booking system: - Promoting the regression pack from weekly to nightly adds nothing. - Running the appointment-calendar journey against another browser adds nothing. - Leaving a session open through the whole vaccination-reminder flow, slow as it is, adds nothing. - Re-running a suspicious failure to see whether it is stable adds nothing. Every one of those would carry a direct cost under metered time, and would at least consume capacity under a reservation. Here they are genuinely free, which means the frugality a metered charge trains into a team is not merely unnecessary — it is actively wrong. Under this shape an under-tested release is a real cost and the extra run is not, so the correct instinct is usually to run more rather than less. ## What it makes expensive The only variable is the breadth of the group holding access. - Every additional person who needs to reach the provider directly moves the charge. - Someone granted access for one investigation and never removed keeps moving it. - Teams that each maintain their own direct access pay for the overlap between them. This is why access counting pushes hard towards a **shared pipeline**: one automated consumer running on everyone's behalf keeps the group narrow while the amount of testing done grows freely. The cost of that design is the usual one — the pipeline becomes a bottleneck and a single point of failure for everybody's feedback — but under this shape the economics push in that direction unmistakably. ## The first thing to establish Before designing anything around an access-counted arrangement, find out **whether an automated consumer counts as a person**. That single answer changes the design completely: 1. **If automation counts**, your pipeline is a consumer like any other, and every service that quietly acquires access of its own widens the counted group. The charge then grows with your infrastructure as well as with your team. 2. **If automation does not count**, the pipeline adds nothing to the charge at all, which makes *route everything through the pipeline* not merely convenient but the cheapest arrangement available to you. This is a question to ask rather than to assume. Getting it wrong in the second direction is the more expensive error, because it hides a growing charge behind infrastructure nobody thinks of as a person. ## The lever is not an engineering lever The uncomfortable part for engineers is that no change to the harness moves this charge. Not shorter sessions, not better utilisation, not fewer reruns, not a smarter teardown. The only quantity this charge is a function of is the size of the group holding direct access, and that quantity sits outside the harness entirely. Who belongs in that group, and who revisits it, is a different question with a different owner; what this shape tells you is only that the bill will not move until the group does. | lever | what it normally moves | effect under access counting | |---|---|---| | shorter sessions | a duration-shaped charge | none | | higher utilisation | cost per run under a reserved width | none | | fewer runs | a duration-shaped charge | none | | a narrower access group | an access-counted charge | the only thing that works | Two footnotes matter. First, *who should hold access* and *what access costs* are different questions with different owners, and merging them produces a review that satisfies neither: the cost conversation wants the group small, the trust conversation wants it correct, and those are not the same shape of argument. Second, none of this means the suite should stop improving. A faster veterinary booking suite still returns feedback sooner, still holds a shorter window in which a remote session can be terminated underneath it, and still keeps the shared pipeline from becoming the bottleneck that access counting pushes you towards. Those benefits are real. They simply do not appear on the bill, and saying so plainly is far better than letting a team conclude its optimisation work failed.