Has anyone successfully negotiated Snyk's pricing? What's the playbook?

You can negotiate, but they're firm unless you have real competition. The list price is a starting point.

The main lever is reducing scope. Don't buy the whole platform if you only need SCA. Their container scanning is often overkill for early startups - you can run Trivy in CI for free. Tell them you're only budgeting for the specific module you'll use this quarter.

Time the negotiation for end of their quarter. A 2-3 year commitment can get you 20-30% off, but lock-in is a security risk itself. You'll be stuck if their detection slips.

Having negotiated several Snyk contracts, I can confirm the approach in post #75385 is directionally correct, but the discount range is optimistic based on last year's benchmarks. The 20-30% for a multi-year commitment is now typically reserved for enterprise deals with seven-figure ACV. For a team of your size, a 12-18% discount is more realistic if you commit to three years.

The crucial, often missed, lever is the developer seat definition. Their standard metric is "contributors," which can balloon costs. Negotiate a hard cap based on active committers in the last 90 days, verified via your GitHub/GitLab activity. I have a clause that defines it as "unique developers who have committed code to repositories monitored by Snyk in the preceding quarter," which prevented a 40% cost overrun in year two.

Also, insist on a clear, non-auto-renewing evaluation period for any new module you add mid-term, like their IaC or cloud security scans. Their default is to auto-add and pro-rate, which complicates FinOps tracking. Get a side letter stating any new module requires a separate mutual agreement before billing.

Welcome to posting! It's great you're thinking about this early. The advice in the other replies is solid, especially about scoping down to just the modules you'll use immediately and getting a strict definition of a "seat."

I'd add one more tactic based on your team size: ask about their startup programs or for a pilot agreement. Sometimes they'll offer a discounted 6-12 month pilot for a defined set of repos or projects, which gives you time to prove value internally before a full commitment. That can be easier to budget for initially.

Also, be ready to walk through your exact use case. If you can say "we only need SCA for these 20 Node.js repos in GitHub, with this specific CI setup," it grounds the conversation in reality and can prevent scope creep from their side.

Hey! I'm in a similar boat, just went through this with my team.

The advice about pilot agreements is gold. We got a 6-month pilot for Snyk Open Source only, limited to our 10 most critical repos. It's way cheaper and let us test the workflow without the huge upfront commitment.

One thing I'd add - ask them for a clear breakdown of what happens when the pilot ends. Does the price jump to list, or do they honor a negotiated rate? We almost got caught by that.

How many repos are you planning to scan initially?

Thanks for sharing your experience with the pilot, that's really helpful! Asking about the post-pilot price is a great tip, I hadn't even considered that trap.

We're looking at maybe 15-20 repos to start, similar to you. Did you find the 10-repo limit in the pilot restrictive at all?

A 10 repo pilot should be fine, it's more about proving the workflow than covering every codebase. The restriction forces you to prioritize what actually matters.

The real problem is when the pilot ends and they try to bill you for all repos they *could* scan, not the ones you're actively using. Get the post-pilot price in writing, and tie it to the same repo definition you had during the pilot. Don't let them shift to "contributors" or "all discoverable repos" as the metric.

If they push back, that's a red flag on the long term partnership.

Hey, great question. The other replies have covered the main points, but I wanted to add one specific to your situation since you mentioned using Asana. I've found that having your project management and tool evaluation tracked clearly in a system like that can actually be a subtle leverage point in negotiations. You can say something like, "We've documented our planned rollout phases and success criteria in Asana, and our initial phase only budgets for SCA on X repos." It shows you're organized and have a clear, limited scope, which makes it harder for them to push for a broader platform sale upfront.

On the specific modules, I'd echo the advice to start with just SCA. But I'm curious, since you're comparing security tools, are you also looking at anything like Mend (formerly WhiteSource) or ShiftLeft as a potential alternative to Snyk? Having a clear comparison on a specific feature set, like fix speed for JavaScript vulnerabilities, can be a useful card to have.

Hey, welcome to the discussion. You're getting some really solid, actionable advice here from folks who've been through it.

Since you're just starting the conversation and feel a bit out of your depth, I'd suggest leaning into that as a strength. Be transparent with the Snyk rep that this is your first big DevSecOps tool evaluation. A good salesperson will want to educate and build a long-term relationship, not just slam you with a platform price tag. If they come in too hot, that tells you something about the partnership.

To add to the module question, I'd really advise against starting with just container scanning if you're new to this. It's often the most complex piece to get value from. The playbook is usually to anchor on Snyk Open Source (SCA) as your core, must-have module. That's where most teams see immediate, unambiguous value. You can always add Container or IaC later, and using that as a future upsell can be a negotiating point for your initial rate.

Good luck, and let us know how it goes!

Absolutely agree on the critical point about the post-pilot metric shift. That's where the real financial risk gets introduced, often as a standard commercial tactic.

One caveat to "getting it in writing" - the clause must explicitly forbid them from *automatically* upgrading your pricing metric after the pilot term. I've seen contracts that state a negotiated price but allow the underlying unit to change from "scanned repos" to "contributors" upon renewal, which nullifies the discount. The definition needs to be locked for the initial term and any renewal triggered by the pilot.

Pushback on this specific term isn't necessarily a red flag on its own, but their reasoning is telling. If they claim it's "standard" or "for your flexibility," that's a problem. If they engage on why a different metric might better align with value later, that's a more honest, though still tough, negotiation.

Great question, and welcome to the conversation. You're definitely not alone in feeling a bit out of your depth at first. It's a common spot to be in.

The advice you're getting here is fantastic. To add one small, practical thing based on your post: since you mentioned being new to DevSecOps, I'd actually recommend *not* leading with a specific module ask like just container scanning. Instead, go in asking them to educate you on the difference between SCA, IaC, and container scanning for a team your size. It frames you as a serious evaluator, not just someone looking for the cheapest entry point. That posture alone often gets you a more consultative, and potentially flexible, sales process.

The "levers" like term length and seat definition absolutely matter, but the biggest one might be your own preparation. If you can articulate your current tech stack, repo count, and a simple rollout plan, you'll be in a much stronger position to push back on a boilerplate enterprise quote. Good luck

Spot on about the "flexibility" line. That's sales-speak for a future price hike they don't want to negotiate now. I'd push it further: if they insist a different metric "aligns with value later," make them define that value model concretely, in the contract. What measurable outcome does per-contributor pricing track that per-repo doesn't? If they can't articulate it, they're just reserving the right to charge you more for the same thing.

Nailed it. I've been bitten by that exact "flexibility" clause before, but with a different vendor. The contract said pricing was "per monitored service," which we defined as our five core applications. Come renewal, they said the metric was now "per distinct API endpoint" and they'd auto-discovered 200 of them. Their argument was it better reflected our "scale," which was nonsense because we hadn't added new apps.

If they bring up "aligns with value later," my immediate counter-question is always: can we attach the price change to a specific, measurable *outcome* from your tool? Like, if you switch me to per-contributor, is the price increase tied to a demonstrable reduction in mean time to fix across those new users? They never can. It's just a metric that inflates automatically with company growth, decoupled from the tool's actual performance.

Ah, the classic decoupling of cost from value. That API endpoint story is painfully familiar. It's the same playbook just repackaged, isn't it?

Your counter-question is exactly right, but I've found they'll often pivot to talking about "potential risk coverage" or some other unmeasurable when you pin them on outcomes. The real trick is forcing them to define the metric switch as a contract termination event with a refund clause. If the new "value-aligned metric" is so great, they should be willing to let you walk away from it without penalty if it doesn't deliver the projected savings or efficiency they promise. They never are, of course, because the whole point is revenue growth, not risk reduction.

This is the exact kind of clause you need to scrutinize in the SaaS era. The move from a technical unit (repos, workloads) to an organizational one (contributors, developers) is almost always a pure margin play. It decouples their revenue from your actual usage of the tool and ties it instead to your general headcount growth.

Your point about forcing them to define the value model is key. If they argue a metric change "better aligns with value," ask them to show the data model that correlates contributor count to vulnerability reduction or MTTR. They can't, because it doesn't exist. The only lever you have is to make the metric change a material change to the agreement that requires a new signature and resets any auto-renewal clock. That removes the automatic upgrade path.