The case against per-seat pricing for small dev teams

Most modern SaaS planning tools charge per user. Linear, Asana, Jira, Notion, ClickUp. The pricing logic is consistent: more users equals more value, so more users should mean more revenue. As a business model for the vendor, this is defensible. As a model for the buyer, especially for small teams, it has problems that don't get talked about enough.

This is the case against the model, and what a better one looks like.

The core problem with per-seat

Per-seat pricing assumes the marginal value of each user is roughly equal. That assumption breaks for most small teams almost immediately.

A two-person team adds a designer for a one-off project. The designer logs in twice a week. They cost the same per-seat as the two founders who live in the tool. The pricing doesn't reflect actual usage; it reflects access. The team responds by either paying for a seat that's mostly idle, or by sharing a login (which violates the terms, but happens often), or by not inviting the designer at all and emailing screenshots back and forth.

None of these outcomes are good. The third one is the worst, because it actively works against what the tool is supposed to do. This is the same dynamic that makes small dev teams need simpler planning tools in the first place: the pricing model and the configuration model both quietly punish the team for using the product as designed.

The model also creates a recurring decision tax. Every new collaborator triggers a "is this person worth $8 per month" conversation. For small teams, where the answer is rarely obvious, this leads to under-invitation. The collaboration features the tool exists to enable get used less than they should.

The "fair" argument

The case for per-seat goes something like: a 50-person team gets more value than a 2-person team, so they should pay more. This is true at the extreme. It's also true that a 50-person team has more revenue and can absorb a bigger bill.

But the curve isn't linear. The 50-person team gets significantly more value, sure. The 10-person team gets roughly the same value as a 5-person team, often. The 3-person team adding a 4th member gets almost no additional value from the planning tool itself, but pays 33% more for it.

Per-seat treats every team as if it's on the same value curve as the largest customer in the tier. For small teams, that curve is wrong, which means small teams are subsidising large ones.

Where flat pricing makes more sense

Flat per-workspace pricing flips the question. Instead of "is this user worth the marginal cost?" the question becomes "is this workspace worth the cost we already committed to?" That's a much easier question, and you only have to ask it once.

For a small team, flat pricing produces a few specific effects:

You invite collaborators freely. Designers, contractors, advisors, the part-time founder, the friend who's helping with marketing. There's no per-head cost, so the friction of inviting drops to zero. The collaboration features get used.

You can predict your bill as you grow. A 2-person team and a 7-person team on the same plan pay the same. You don't have to re-budget every time a teammate joins.

You stop discovering that someone was sharing a login. Because nobody had to, because the math didn't punish them for being honest.

The cost to the vendor is real. Some workspaces over-extract value, others under-extract. For a vendor that targets small teams specifically, this evens out. For a vendor that wants to capture the upmarket too, flat pricing breaks. That's part of why most tools eventually move to per-seat: the upmarket pull is real.

The argument against flat pricing

It isn't all one-sided. Per-seat does encourage admins to remove inactive users, which keeps the tool tidy. Flat pricing tolerates dead weight in the workspace.

Flat pricing also has a scaling problem at the top end. A 200-person org paying the same flat rate as a 5-person team is clearly under-paying. Most flat-pricing models eventually add an enterprise tier with custom pricing to handle that, which is honest about the limit but adds complexity.

The honest summary: flat pricing is better for small teams, per-seat is better for vendors who want to scale upmarket, and the tool you pick should align with the side of that tradeoff you're actually on. If you're a small team or an indie shop, you're being underserved by per-seat economics. That's not a complaint about Linear or Jira; it's a structural feature of how those tools price.

What flat workspace pricing looks like

Frostbyte's pricing is flat per workspace. Free for one project. Indie is $16 per month annually, Studio is $29 per month annually, both for the entire workspace regardless of headcount. Invite as many collaborators as the plan allows; the bill doesn't change. The plan comparison lists what's included on each tier.

This isn't a moral position. It's a bet on the segment. Small dev teams are where the model fits, and small dev teams are who Frostbyte exists for. If your team is past a hundred people and you live across a dozen integrations, Linear or Jira will probably serve you better, and that's fine. For everyone smaller, the case for a simpler tool and the case against per-seat pricing are basically the same argument applied to two different surfaces of the same product.

The signal that you've outgrown per-seat planning tools is when you start having the "is this person worth a seat" conversation more than once a quarter. That conversation isn't a sign of disciplined spending. It's a sign that the pricing model is making your team smaller than it should be.