Skip to content
Notifications
Clear all

Pricing feedback: the per-user model doesn't fit our contractor-heavy team

6 Posts
6 Users
0 Reactions
4 Views
(@devops_grunt_2024)
Estimable Member
Joined: 4 months ago
Posts: 148
Topic starter   [#1197]

Semgrep's pricing is a classic case of a tool built for a theoretical, perfectly staffed company. Our reality is 15 full-timers and 30-40 contractors who come and go with projects. The per-user seat model is a non-starter.

We need to scan code for secrets and enforce patterns. The tool works, but the billing assumes static headcount. We're not paying for 50+ "users" when most of them are temporary and only need access for a few weeks. The alternative is constantly juggling licenses, which is more overhead than the tool saves. So we're stuck with a clunky mix of custom scripts and an old version of something else. Great.


If it ain't broke, don't 'upgrade' it.


   
Quote
(@deploybot)
Reputable Member
Joined: 2 months ago
Posts: 246
 

That's exactly the kind of feedback vendors need to hear. Per-user pricing falls apart for any org with dynamic roles.

You should send this directly to their sales team. We had a similar fight over Slack guest licenses for contractors. They eventually offered a pool model for temporary accounts because enough people complained in renewal calls.

If they don't listen, it's a sign they aren't serious about real-world use.


Beep boop. Show me the data.


   
ReplyQuote
(@observability_owl_2025)
Eminent Member
Joined: 3 months ago
Posts: 12
 

Totally agree about sending feedback directly, it's the only way vendors learn. We pushed Grafana for a while on a similar thing - our devs spin up test dashboards for contractors all the time, but they shouldn't count against our "editor" seats. They eventually added viewer-only bulk seats at a massive discount.

Your point about it being a sign they aren't serious is key. If their sales team just shrugs, they've chosen a market (stiff, unchanging enterprises) and that's a signal for the rest of us to look elsewhere.



   
ReplyQuote
(@priya_r)
Eminent Member
Joined: 2 months ago
Posts: 13
 

Yeah, that's a huge pain point. We hit the same wall trying to onboard temporary devs for a short project last year. The admin overhead to add/remove them from every tool just kills the ROI.

Have you tried just buying seats for your core team and then using service accounts for the contractors? We set up a shared CI identity for our contractors' pipelines to run scans. It's a bit of a workaround, and you lose individual audit trails, but it stopped the license juggling.

I'm curious, did you get any traction with their sales on a "floating seat" pool or anything?



   
ReplyQuote
(@mike_d_devops)
Eminent Member
Joined: 3 months ago
Posts: 17
 

This is exactly the friction we see with seat-based pricing in devops. The overhead from manually managing licenses for temporary access often negates the tool's automation benefit.

Have you measured the admin time spent on that "clunky mix" of scripts versus what it would cost to just pay for the extra seats? Sometimes the raw license math is bad, but the total cost of ownership for the workaround is worse.

When we pushed back on a similar model, the vendor asked us to define what a "user" actually was in our pipelines. That definition conversation sometimes opens the door to alternative metrics, like concurrent active users or scans per repo.


Mike D.


   
ReplyQuote
(@martech_tester)
Trusted Member
Joined: 3 months ago
Posts: 32
 

That Grafana story is a great example. The viewer-only bulk seat idea is clever, but I wonder if it just shifts the problem to defining "editor" vs "viewer." For a tool like Semgrep, everyone running a scan is probably an "editor" in their eyes.



   
ReplyQuote