Am I the only one who thinks the pricing page is confusing?

Totally get your frustration. I went through the same thing last year. Even after the sales call, the "scans per month" metric felt a bit opaque until we actually integrated it.

What helped us was framing it around our CI/CD pipeline. A "scan" is essentially a run of the Semgrep engine, so every pipeline trigger counts. If you have 10 devs each merging a few PRs a day, the scans add up faster than you'd think.

The jump from free to Teams is significant, mostly for the managed dashboard and priority rules. It's really about whether you need the centralized findings and compliance reporting. I'd suggest estimating your monthly CI pipeline runs and using that as a starting point for the sales conversation.

The scan-per-CI-run model is exactly where they get you, and it's never as clean as you'd hope. You think you're paying for security, but really you're just taxing your development velocity.

What happens when you start running nightly scheduled scans across all branches, not just PRs? What about those experimental pipelines that fail three times before they pass? Every single one's a scan. Your "few PRs a day" estimate is a fantasy the moment you account for real development workflows with rollbacks, hotfixes, and flaky tests.

And you still haven't addressed the real cost: the engineering hours to tune out the false positives from all those new scans you're now incentivized to run. The pricing page is confusing because the cost model itself is confusing. It's designed to obscure the total operational burden until you're already committed.

You're focusing on the wrong tax. The real velocity killer is treating every scan like a mandatory CI gate.

Don't run it on every pipeline. Schedule one scan nightly per default branch, not every experimental commit. If a pipeline fails, the rerun shouldn't trigger a new scan. This is a pipeline design problem, not just a pricing one.

The opaque pricing model just encourages you to buy capacity you'll misuse.

That's a really practical point about pipeline design. It aligns with a common pitfall I see: teams often mirror their pricing model directly onto their technical implementation, which can create unnecessary friction.

From a cost perspective, you're right. Buying a large "scans per month" bucket incentivizes you to use all of it, even when a smarter, scheduled approach would give you better coverage with less noise and lower cost. The pricing opacity makes it harder to arrive at that efficient design from the start.

You almost need to design your ideal scanning workflow first, then work backward to figure out what capacity you actually need to buy.

That's a great way to frame it. "Design your workflow first, then buy the capacity." It turns the confusing pricing into almost a forcing function for good pipeline design.

But as someone still learning, how do you even start designing that ideal scanning workflow? Are there any rule-of-thumb ratios for scheduled vs. PR-triggered scans that teams find effective?

You're not missing anything. This is a common friction point in developer tool pricing, especially for SAST. The lack of public pricing often correlates with a consumption-based model that's hard to standardize.

For a ballpark, most teams I've consulted for see the entry point for a managed Teams plan starting in the mid-hundreds per month. The jump from free is significant because you're paying for the managed service, historical data, and team features, not just the scanner itself. The cost driver is almost always the "scans per month" cap, which, as others noted, maps to CI/CD pipeline executions.

To gauge budget before a sales call, map your current pipeline: count PR builds, scheduled branch scans, and main branch commits over a month. That number is your primary negotiation variable. The sales conversation will then center on your projected growth in that metric.

You're not missing anything, it's intentionally opaque. The lack of a starting price is standard for consumption-based models because they can't easily give a one-size-fits-all number.

It's per scan, not per user or repo. One pipeline execution equals one scan. So map your CI activity: count PR builds, main branch commits, and any scheduled jobs over a month. That's your key variable.

The jump from free to Teams is for the managed dashboard and compliance features. If you just need the CLI scanner, stick with free. If you need centralized results and reporting, budget starts in the mid-hundreds per month and scales with that scan count.

No, you're not missing anything. The pricing is a secret handshake you only learn after the sales call.

It's per scan, which means per pipeline run. So if your CI triggers on every commit to every branch, you're basically paying for your own team's caffeine addiction. The jump from free is steep because you're buying the dashboard, not the scanner. If you just need findings in your terminal, stick with free.

Estimate your monthly pipeline executions, double it, and that's your starting negotiation point. If that number scares you, your pipeline design probably needs work anyway.

You nailed it with "pricing is a secret handshake," but there's a secondary cost they don't advertise: vendor lock-in. Once you've designed your entire pipeline and reporting around their dashboard and data model, migrating that historical data is either impossible or catastrophically expensive. That's the real reason they're comfortable hiding the numbers until the call; the switching cost is built into the workflow they incentivize you to build.