All news

Business model

Seats vs concurrency: what you're actually charging for

Most SaaS pricing bills by headcount without ever treating that as a choice. Two BIXSO apps looked at the same decision and wrote the rejection into the pricing code — read against a third app that meters something else entirely.

Seats vs concurrency: what you're actually charging for

A subscription tier meters something. Most SaaS products meter seats — the price scales with how many user accounts exist, whether those accounts are doing anything or not. It’s the default so completely that it rarely gets treated as a decision. It is one.

The alternative is concurrency: meter how much of the resource is actually in flight at any given moment, not how many people are allowed to touch it. Two BIXSO apps — Auslandscape (landscaping) and Service Place (services marketplace) — built pricing this way on purpose, and the pricing code says so directly. Auslandscape’s comment reads that the tiers are set by the number of concurrent projects a provider can run, “NOT seats, NOT a per-month lead-response cap — those concepts are removed.” Service Place’s file opens by calling itself a mirror of Auslandscape’s, with the same rejection written in for the same reason.

SeatsConcurrency
Unit solda user accounta thing actively in flight
Price grows withheadcountsimultaneous throughput
One person running 10 jobs at oncestill 1 seat, same pricemoves to a higher tier
BIXSO built it as— considered, rejected on 2 appsAuslandscape · Service Place
Choose whenaccess is the scarce thingcapacity is the scarce thing

The numbers, read straight out of the pricing files:

  • Auslandscape — Starter A$59/mo for 1 concurrent project, Growth A$79/mo for 3, Unlimited A$199/mo for unlimited. Each tier also carries an Energy allowance (100 / 300 / 500⚡ a month) that pays for AI use and directory boosts, layered on top of the concurrency meter rather than replacing it.
  • Service Place — Starter A$59/mo for 2 concurrent jobs, Growth A$99/mo for 6, Unlimited A$199/mo for unlimited, same 100/300/500⚡ ladder.

Why concurrency and not seats, for a marketplace where the supply side is one person doing physical work: a landscaper or a tradesperson isn’t buying access for a team, they’re buying how much work the platform lets them carry at once. Billing that by seat count would charge a solo operator running three jobs the same as one running one job — and the thing the platform actually protects (lead flow, scheduling load, support capacity) scales with concurrent jobs, not with how many logins exist. Seats would have been the easier default to ship. It was the wrong meter for this shape of business.

A third app answers a different question entirely. Bixsourcing, BIXSO’s B2B sourcing marketplace, doesn’t meter capacity at all — it meters role. One Role ($79/mo) locks an account to buyer or seller; Two Role ($189/mo) unlocks both; Advance ($299/mo) adds reseller capability on top. The question there isn’t “how much are you doing,” it’s “who are you allowed to be on this platform.” Same company, same instinct to reject the generic default, but a genuinely different axis — because a sourcing corridor’s scarce thing is trust and identity, not throughput.

The honest limit: I checked all three apps’ enforcement state directly before writing this, not from memory. Bixsourcing’s plan gate has been running in hard mode since 13/07 — a real 403 fires when the entitlement isn’t there. Auslandscape is still in soft (warns, doesn’t block); Service Place is off (attached but not enforced at all). So the role-based meter has actually been pressure-tested against real usage. The concurrency-based one — the more interesting design decision of the three — hasn’t yet. Everything above about it holding up under load is still a bet the code is placing, not a result.

If you’re setting a subscription meter and not sure which axis fits: ask what actually runs out when your busiest customer pushes hardest. If it’s how many people need a login, seats are honest. If it’s how much of the thing is happening at once, seats will undercharge your best customers and overcharge your smallest ones — meter concurrency instead. If the real constraint is who’s allowed to act, neither fits; meter the role.

This is a M3 (revenue & pricing) question on the Business Solution Canvas — free, CC BY-SA, open for anyone building the same decision into their own pricing.