So I've been using Semgrep for client security reviews for about a year now. It's a fantastic tool, genuinely. The rules are powerful, and it slots into CI/CD pipelines beautifully. But their pricing model? It's like they've never met a security consultant.
The core issue is the per-seat licensing. I'm a solo consultant. I don't have a "team" of engineers to license. My workflow is:
* Client A hires me for a 3-month engagement. I need to add their entire dev team (20 engineers) to their dedicated Semgrep dashboard for the duration.
* Client B hires me for a one-off code review. I just need to run the CLI locally and share a PDF report. No dashboard needed.
* Client C wants ongoing, lightweight monitoring. They need maybe 2-3 of their leads to have access.
Under the current seat model, I'm forced into a painful choice for every client: either I eat the cost of licensing their entire team under *my* account (financially absurd), or I have to guide each client through their own procurement process (a massive project management overhead that kills profitability). The pricing actively punishes the intermittent, project-based workflow that defines consulting.
It feels like Semgrep, Inc. is only optimized for selling to a single, monolithic engineering org. For those of us who operate across multiple orgs, the model is a brick wall. There's no "consultant" or "agency" tier. No easy way to spin up and tear down isolated instances without the licensing becoming a nightmare.
I'd love to see a model based on **active repositories scanned** or **compute minutes**, with user-based pricing decoupled from the engineers just viewing results. Or even a simple "bring-your-own-license" setup where the client's seat count is their problem, not mine.
Until then, I'm stuck with awkward conversations and manual workarounds. A tool built for automation shouldn't create this much manual overhead.
Just my 2 cents
Trust but verify.
You've precisely identified the classic consumption versus subscription mismatch that plagues variable-workload professions. This isn't just a Semgrep problem, it's a widespread SaaS pricing failure. The financial model forces you to over-provision for peak capacity (Client A's 20 seats) while you're only realizing value from that capacity for a fraction of your billing cycle.
A parallel in cloud infrastructure would be if you had to buy 20 reserved instances for a year to handle a three-month client spike, leaving them idle for nine months. Any competent FinOps practitioner would reject that as unsustainable waste. Your workaround of guiding clients through procurement is essentially a manual, error-prone form of cost allocation, which is pure overhead.
Have you explored whether their enterprise sales team would entertain a true consumption model, perhaps based on lines of code scanned or active project hours? If not, you're effectively subsidizing their revenue recognition simplicity with your own operational complexity.
Every dollar counts.