Skip to content
Notifications
Clear all

ELI5: Why does each 'developer seat' need a separate 'reviewer seat'?

4 Posts
4 Users
0 Reactions
0 Views
(@emilyl)
Reputable Member
Joined: 2 weeks ago
Posts: 169
Topic starter   [#22747]

Hey everyone! 👋 I've been trying to convince my team to switch to a new development platform (looking at Vercel and a couple others), and I keep hitting this same confusing wall in their pricing pages.

I'm not a developer myself, I'm on the project management side, but I'm trying to understand the costs. I see plans with "developer seats" that can push code, and then separate "reviewer seats" for teammates who just need to view deployments, leave feedback, or maybe approve a PR. Why are these almost always separate line items?

Like, if I have 5 developers, and then my PM, designer, and QA person just need to see previews and comment, does that really mean I need to pay for 5 developer seats AND 3 reviewer seats? That feels like it doubles the cost for non-coding collaborators. Isn't the whole point of these modern tools to get *everyone* involved in the review cycle, not just devs?

From a pure logistics angle, I don't get why a "developer seat" doesn't automatically include "reviewer" permissions for, say, one or two other people on their team. Or why it's not just one seat type with role-based permissions. Is there a technical or security reason for this split, or is it mostly a pricing model thing?

Trying to build a business case and this is the part that makes my head spin. Any simple explanations or experiences from your teams would be super helpful!

Thx!



   
Quote
(@ci_cd_enthusiast)
Reputable Member
Joined: 5 months ago
Posts: 152
 

Yeah, this pricing model is super common and honestly, it often feels like a pure business decision, not a technical one. The technical reason given is usually about "concurrency" or "active build minutes" - a developer seat might trigger more expensive compute/resources when they push code, while a reviewer just hits a static preview URL.

But you've hit the nail on the head: it actively punishes you for involving non-devs in the process. My team ran into this too. We ended up just sharing a single "reviewer" login for our PM and designer, which is obviously a security/compliance no-no, but we couldn't justify the cost.

Some smaller platforms are starting to bundle "collaborator" seats for free with a certain number of developer seats, which feels more aligned with how modern teams actually work. Might be worth asking sales if they can offer that.


Pipeline Pilot


   
ReplyQuote
(@annak8)
Trusted Member
Joined: 2 weeks ago
Posts: 40
 

Oh, totally feel your pain. The "collaborator tax" is real! You're right on the money thinking about role-based permissions - from a pure tech standpoint, there's zero reason it couldn't work that way. It's a pricing and packaging choice, full stop.

I compare these feature matrices for fun, and the trend I'm seeing is that platforms charge for any distinct login that touches the "preview" or "feedback" layer because they can. It gates a highly valuable feature - stakeholder visibility. The good news is, this is becoming a major differentiator. Some newer platforms are starting to include a pool of free reviewer seats, exactly as you suggested, because they know it's a pain point.

Have you checked if any of the platforms you're looking at have a "team" or "business" tier that might bundle those reviewer seats? Sometimes the jump isn't as bad as buying them all à la carte. It's still frustrating though, you shouldn't have to pay a premium just to let your designer see their own work.



   
ReplyQuote
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 204
 

You're right that it's a packaging choice, but there is a real cost difference they're capitalizing on. A "developer seat" ties up build minutes and concurrency slots, which directly hits their infrastructure bill. A reviewer hitting a static preview is negligible.

The business move is to charge for the *value* of the feature, not the cost. Getting stakeholder feedback into the pipeline earlier prevents expensive rework, which is hugely valuable. They price it because teams will pay it.

Look for platforms that use a "contributor" model instead, where seats are based on repo access or active code commits, not just login roles. That often aligns better with actual usage.


Build once, deploy everywhere


   
ReplyQuote