Per-seat pricing was elegant in 2012. You were buying software for desks, and each desk got a login, and the company charging you knew exactly how to scale revenue with your growth. It was clean, predictable, and quietly punishing. Mostly the last one.
We don't charge per seat. We never have. People assume that's because we couldn't compete on net dollar retention against per-seat SaaS — and they're not wrong, but it isn't the reason. We don't charge per seat because per seat is a tax on the thing you most want your customer to do.
What per-seat pricing actually charges for.
The story per-seat sells you is: more value flows to teams with more users, so the price scales with the value. Plausible. Let's audit it.
A 10-person agency hires their 11th employee. The marginal value of HubSpot to that team does not go up linearly. The new hire isn't using the CRM 1.0x more than the existing average user — usually they're using it less, ramping in. The data is the same. The integrations are the same. The compute load on HubSpot's servers is essentially identical.
But HubSpot's invoice just went up another $50–90. You're paying not for value delivered. You're paying for the act of hiring. Per-seat is a tax on the headcount line of your P&L.
Pricing should reflect the cost or the value, not the customer's payroll department.
And the worst part isn't the explicit cost. It's the implicit one — the slow, recurring cultural pressure to not add seats. Don't give the intern a license. Share Bob's login across the team. Don't make sales reps view-only, make them no-login. Per-seat pricing teaches your team to be petty about who gets to use software, and pettiness is the opposite of what software should produce in an organization.
The hidden cost: the seat tax on payroll.
The most flagrant example is payroll software. Gusto charges roughly $40 per month base, plus $6 per employee per month. ADP, Justworks, Rippling, all in the same range. Quick math on a 20-person team: $160 in employee-tax fees per month. Per year: $1,920.
That's $1,920/year you are paying because — checks notes — your payroll software has to run payroll for the people on your payroll. The thing the product literally exists to do. The "feature" being charged for is its own table-stakes function.
Multiply across the stack — CRM is $90/user, project management is $20/user, helpdesk is $25/user — and you arrive at the number every founder eventually rediscovers: software costs more per employee than office snacks, and roughly as much per employee as health insurance subsidies. It's a real line in the budget. Per-seat pricing is the engine pumping it up.
The argument for per-seat.
To be fair to it: per-seat has one thing going for it. It aligns vendor revenue with customer scale. A 200-person company pays more than a 10-person company. That feels right. It probably is right at the high end.
The argument is true in the limit and false in the middle. A Fortune 500 with 80,000 employees probably should pay more for HubSpot than a 10-person agency. But the curve from 10 to 80,000 isn't linear in value, even though per-seat treats it as if it is. Around 30–50 employees, the marginal user is providing zero new value to the vendor and substantial new cost to the customer.
That's the inflection where flat fees pay off. And it happens to be exactly the ICP for most all-in-ones being built today.
Why we chose flat, and what we gave up.
Mewayz Business is $149/month with 30 users included. Agency is $349/month with unlimited users. That's it. No matter how much your team grows, your bill doesn't move.
What did this cost us? Net dollar retention, partially. Per-seat customers pay you more next year automatically as they hire; flat customers don't. We make up the difference by selling more modules over time, by white-label expansion, and by add-on storage and AI credits. But we'd be lying if we said we didn't watch our NDR numbers with a slight wince every quarter.
What we got in return: customer trust we couldn't buy any other way. Nobody is suspicious of their Mewayz bill at headcount-doubling time. Nobody is rationing logins. Nobody is hiring around the software. The product gets the credit for being the system of record, and the headcount decision gets to be made on its own merits.
The compromise: usage-based, not seat-based.
There's a strong middle ground between per-seat and flat: usage-based pricing. You charge for the thing the customer is actually consuming — emails sent, payments processed, API calls made, storage used.
Stripe is the canonical example. Twilio. Snowflake. None of them charge per seat. They charge per transaction, and the customer's incentives are perfectly aligned: the more they grow, the more they pay, but the cost scales with the success metric instead of the cost line.
That's the model we'd prefer over flat. It's just hard to apply across 150 modules with different units of consumption. So flat is our compromise — for now. Long-term, expect us to migrate some categories (AI generation, payments, storage) to usage-based, while keeping the platform fee itself flat.
What this means for you.
Two practical takeaways for anyone shopping software in 2026:
- Calculate the seat tax explicitly when comparing vendors. Take the per-seat number, multiply by your projected headcount in 24 months, and use that as the real total cost of ownership. The honest comparison favors flat-fee products much more than the sticker prices suggest.
- Beware "per-employee" payroll fees especially. They compound. They're the most expensive line of your SaaS bill at any size above 15 employees, and they're entirely a vendor-side decision masquerading as a cost reflection.
We don't expect the per-seat model to disappear. Salesforce isn't switching tomorrow. The legacy stacks have too much vested in the spreadsheet math. But every new platform getting built — including ours — has a chance to choose differently. We did. We think more will.