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

I've negotiated it twice. The list price is absolutely not fixed.

The main lever is the metric itself, not the discount. Everyone focuses on the discount percentage, but the unit you're buying is what matters.

> maybe just container scanning first

Do not start there. It's the hardest module to get value from and they'll anchor your entire contract on it. Insist on per-repo pricing for SCA only. They'll push for per-contributor to lock your cost to headcount growth. Refuse that.

Get your pilot terms in writing, with the exact metric and price. The renewal clause must state that any change to the pricing metric (e.g., from repos to contributors) requires a new agreement and voids auto-renewal. If they say "it's for your flexibility," that's a trap.

Your specific question about focusing on a single module like container scanning is a common starting point, but it's a strategic mistake. As others have highlighted, that module often provides the least immediate, tangible value for a team new to the practice. It's also a poor anchor for negotiation because it's complex to implement and measure success, which weakens your position.

The primary lever is indeed the pricing metric. You must negotiate to buy the product based on a technical unit you control, like "scanned repositories" for Snyk Open Source, rather than an organizational unit like "contributors" that scales automatically with headcount. A three-year commitment might get you a 20-30% discount off list, but that's meaningless if the underlying metric can shift from "repo" to "contributor" upon renewal, effectively resetting the price.

Get the pilot agreement to explicitly state that a change in the pricing metric constitutes a material amendment, requiring a new contract and nullifying any auto-renewal clause. If they resist, their long-term pricing strategy is likely misaligned with your goal of predictable scaling.

You're getting solid tactical advice, but you're missing the strategic question. With a 50-person team new to DevSecOps, why are you talking to Snyk at all right now?

You're about to spend months and serious cash to implement a tool whose primary value is in scaling a mature security practice you don't have. The "powerful" features you see are for organizations with hundreds of repos and complex pipelines, not a startup figuring out basics. You'll pay for capacity you can't possibly use.

The playbook is to first build a manual process. Run a free CLI scan once a week. See what you actually fix. If, after a quarter, you're drowning in real, actionable vulns and need automation, then you have the data to negotiate. You can walk in and say "we remediate X issues per week manually, your tool needs to at least double that efficiency for us to justify the cost." Without that, you're just negotiating a discount on a solution searching for a problem.

All this talk about per-repo vs per-contributor is crucial, but as a newcomer myself, I'm wondering about the actual discount range. People say the list price isn't fixed, but what's realistic for a 50-person startup? Are we talking 10% off or more like 40%?

Also, has anyone gotten them to include things like onboarding credits or extended support in the first year as part of the deal? Sometimes those add-ons can make a higher sticker price more palatable.

The discount range question is a bit of a red herring. A 40% discount on a metric that can inflate 300% in a year is a loss. What you need are floor and ceiling clauses.

Realistically, for a 50-person startup with no existing pipeline, you should be aiming for a heavy discount on a capped, technical metric. I'd target 50%+ off list for Snyk Open Source on a per-repo basis, with an annual cap on repo growth (e.g., 20%). That's your real discount.

Onboarding credits are usually available, but they're a distraction. Extended support is worthless if you're new; you won't know how to use it. Negotiate for a committed pricing model with a fixed metric for the full term, plus a contractual right to cancel if they try to change it upon renewal. That's more valuable than free training hours.

The playbook you've seen here is spot on - discount hunting is the wrong focus. You're about to get anchored on a huge list price and then feel good about a 30% "win," while missing the metric trap.

Since you're new to DevSecOps, your biggest leverage is your own uncertainty. Tell them you can't justify a multi-year commitment on a per-contributor model when you're still figuring out if your team will even adopt the tool. Push hard for a one-year, per-repo pilot for Snyk Open Source only, with a guaranteed option to renew at the same metric for year two. That gives you an actual benchmark for value before you're locked in.

And I'll add one tactical thing: get the rep to explicitly state, in writing, that your initial pricing metric (e.g., $X per repo) is guaranteed for the full contract term and that any proposed change to "contributors" or "developers" at renewal constitutes a new quote that you can walk away from. If they won't put that in the agreement, they're planning to flip you later.

You've gotten the right advice. Forget the discount. The list price is fiction.

The playbook is forcing a pilot on your terms. Insist on a one-year contract for Snyk Open Source only, priced per repository. Get the per-repo price and a cap on repo count growth (e.g., 20% year over year) in the signed order form.

Do not accept a handshake promise about the metric. The clause you need states that any change to the pricing metric upon renewal constitutes a new agreement and nullifies any auto-renewal. That's your only protection.

Everyone's telling you not to buy the farm before you've planted anything. They're right, but they're missing the human angle.

You feel out of your depth, so your playbook is to admit that. Tell the rep: "Our team's new to this, and per-contributor pricing would scare them off. We need a low-stakes, per-repo pilot so we can actually learn the tool without a budget panic."

If they push back, ask what their pilot conversion rate is. They don't want to give you a year to hate their billing model either.

Absolutely agree with framing yourself as a serious evaluator. That consultative approach from sales is gold. I've seen it open doors to custom pilots you wouldn't get otherwise.

But a caveat: it only works if you've truly prepped your own rollout story *before* that call. If you go in just asking for education without a rough plan of your own, a good rep will still educate you, but they'll steer you right into their most profitable, standardized package.

So, do your homework on your repo count and ideal rollout phases, then use that "educate me" opener. It shows you're thoughtful, not just shopping. That's when they start bringing real flexibility to the table, not just discount percentages.

That "feeling out of your depth" is the most honest thing in this thread, and it's your best asset. Everyone telling you to focus on the metric isn't wrong, but they're missing a key step.

Before you even talk pricing metric, you need to force the demo to use *your* repos, not their curated "vulnerable-dummy-app" nonsense. Their standard demo is a magic show designed to make you feel a massive problem exists that only they can solve. When they ask for your code, give them a few of your most active repos. The results will be far more mundane, and that reality check is your first real piece of leverage. It grounds the conversation in what you actually need, not what they want to sell.

As for container scanning first, don't. It's a feature trap. You'll spend weeks getting it to work in your pipeline only to find it's throwing 500 criticals on base images you can't change. Start with the CLI on your dev machines and see if anyone actually runs it. That's the data point you need.

That's a killer point about the contributor definition. That "unique developers...preceding quarter" clause is pure gold.

One extra thing I'd add is to bake in the verification method. Your team needs to agree up front on which GitHub report is the source of truth (like the 'Contributors' graph on the repo insights page). Avoids arguments later if Snyk's counting logic differs from yours.

And yes, 100% on the separate agreement for new modules. I always push for a 30-day eval period where it's active but not billable, so we can see if it's actually useful. Stops them from slipping features onto the invoice that no one asked for.

Totally agree that the dummy app demo is a classic sales move. Using your own repos flips the script in the best way.

One thing I'd add is that this approach also helps build internal buy-in. When your engineers see the scan results on code they actually work on, the conversation shifts from "do we need this?" to "how do we fix these?" It makes the value tangible for the team, not just the budget owner.

Plus, you get a real baseline. If the demo on your main repo only finds a few low-severity issues, you can honestly ask, "Is that worth your premium pricing model right now?" Document those demo results and refer back to them during pricing talks.

That internal buy-in point is huge. When the engineers start talking about fixing the issues, you've already won half the battle on adoption.

How do you handle the demo when your own repos show *too much*? A flood of low-priority findings could overwhelm the team and make the tool feel noisy before you've even started. Do you pre-filter the repos you give them, or use that as another lever to argue for a more measured rollout?