News reaction: Their new funding round - will prices go up?

Oh, that's a really good point. I hadn't even thought about the renewal angle, but you're right. It feels like the story is always about new features after funding, not what happens to existing plans.

I'm using a different SaaS tool for project management, and after their last big round, they quietly moved a bunch of useful reporting features into a higher tier. It wasn't a direct price hike, but it felt like one because we had to upgrade to keep the same value.

Do you think it's worth asking your Cybereason rep for some kind of price lock guarantee before you commit, since you're still evaluating? Maybe that's a naive question, but I'd be nervous too.

Totally feel you on the feature tier shuffle. That's the silent killer. It's not a new price, but your plan just got worse, so you're forced up.

Asking for a price lock while evaluating is smart. I've had some success framing it as needing budget predictability for a multi-year rollout. Sometimes they'll offer a 2-3 year cap to secure the deal, especially if you're a new logo for them.

But honestly, the real move is to bake a clause into the contract about feature deprecation or tier changes. It's a harder sell, but it protects against exactly what you described.

You're right about the contract clause being the ultimate defense, but I've found that approach has a hidden cost. In my experience, vendors who agree to such terms often compensate by baking the risk into higher baseline prices or by becoming inflexible on other, more critical terms later. You're essentially asking them to underwrite future product decisions, and their legal teams push back hard.

The more pragmatic middle ground I've negotiated successfully is a "material degradation" clause. It doesn't lock features per se, but it triggers a right to terminate without penalty if a core, documented capability used at signing is removed from our tier or paywalled. It's less about freezing the product and more about preventing the rug pull.

That said, for a company fresh off a large round, their primary pressure is likely customer acquisition, not squeezing existing ones yet. Your leverage as a new logo is highest right now. I'd push for the multi-year price cap first, as that's a simpler ask, and use the threat of a competitor's offer to maybe get the degradation clause added as a compromise.

Your gut feeling about the funding-renewal link is spot on. I've seen it happen, especially with security vendors pushing for that coveted "platform" status post-funding.

You mentioned per-endpoint pricing already feeling high. That's your key pressure point. When renewal comes, they'll likely push hard to bundle their other modules under a single "platform fee." It looks like a discount at first, but it locks you in and removes your ability to manage costs per product.

For your evaluation, get their discount schedule in writing now. Don't just ask for a "lock." Get the specific per-endpoint rate and the commit period guaranteed in the initial term sheet. Then, add user568's material degradation clause. It won't stop a price increase on renewal, but it prevents them from moving your container-specific detection features into a pricier SKU mid-contract.

What's your current contract length? Anything under three years is risky.

Your focus on the per-endpoint cost for container workloads is the right lens for this. In my last integration project with a similarly funded security vendor, their post-round "platformization" didn't initially raise the list price for our existing endpoints. Instead, they enforced strict new minimum commitments on the *number* of endpoints for any renewal or expansion, which functionally removed our ability to get volume discounts on our actual, smaller count.

> Stricter bundling (forcing you into their full platform)?

In that case, bundling was the primary lever. The full platform SKU became the only option for new agreements, and while it included more modules, its calculation moved from countable endpoints to "protected assets," a nebulous metric that included containers, cloud workloads, and IoT devices under a single, inflated count. Your forecasting concern is valid; that shift to "value-based" metrics is often a prelude to less predictable scaling costs.

I'd recommend requesting their current discount matrix and asking directly how container endpoints map to their pricing model if a consolidated platform SKU is introduced. The answer, or their reluctance to provide it, will be telling.

I've found the "budget predictability for a multi-year rollout" framing works best with vendors who sell to mid-market IT ops, less so with pure enterprise security teams. Their sales cycles are different.

You're right about the contract clause being the ultimate goal, but my experience lines up with user568's point below - you'll almost never get a blanket feature freeze. The legal overhead for them is massive. I've had more luck specifying the exact metrics and thresholds we're buying against. For example, "per-core analysis" or "unlimited historical search for 90 days" - concrete, measurable capabilities tied to the price point. That's harder for them to creatively reinterpret later.

That's an excellent point about framing, and it highlights a critical nuance in how sales teams are incentivized. A mid-market team's success metrics are often tied to initial multi-year contract value and logo acquisition, making the "budget predictability" argument compelling. An enterprise security sales team, however, is frequently measured on account expansion and platform adoption over the full lifecycle, so they're structurally less interested in locking in a low rate for three years.

Your suggestion to specify exact metrics and thresholds is, in my view, the most effective technical mitigation. It transforms a vague "feature" into a verifiable service-level component of the agreement. I'd add that you should also specify the *measurement methodology* for those metrics. For instance, "unlimited historical search for 90 days" is strong, but you need to define what constitutes a "search" (is an API call a search? Is a filtered query one search or multiple?) and how the 90-day retention is validated. Without that, you're open to reinterpretation on a technicality.

You're absolutely right that specifying the measurement methodology is the critical, often missed, second step. I learned this the hard way with an API call quota.

We had "10,000 API requests per month" written into an agreement. Later, the vendor's new platform version started counting a single `GET` request that returned 100 objects as 100 "requests" internally, claiming it was "100 data retrieval operations." The language in the contract didn't specify their counting logic, so we had no recourse. It completely broke our cost projections.

Your example about what constitutes a "search" is spot on. It's not enough to list the metric; you have to define the unit of measurement in the same terms their own system uses for billing. Ask for the exact log field or API parameter that increments the counter, and get a sample of the raw usage data in your contract appendix.

Oof, that API counting story is painful but so familiar. I've seen the same sleight-of-hand with "billable events" in logging platforms, where one user query scanning multiple indices suddenly becomes a dozen events.

Your appendix idea is gold. We started demanding the exact SQL query the vendor uses to generate our monthly usage report. It forces them to document their own logic upfront. Saved us from a similar mess last year.

Yeah, that per-endpoint model for containers gets tricky. It's not just about the number of pods, but how quickly they scale. Your bill becomes a function of your autoscaling groups.

For forecasting, I'd be more worried about them moving from a simple endpoint count to something like "protected assets" that includes volumes, network interfaces, or API calls. That shift is harder to model.

Did you get any clarity on what exactly qualifies as a container endpoint in their current model? Is it the node, the pod, or the running container?

You're right on the money about the renewal playbook. I've seen this exact scenario, where a funding announcement came right before our renewal window opened.

In our case, they didn't raise the per-endpoint rate directly. Instead, they introduced a new "container protection module" that was suddenly required for proper coverage on our Kubernetes clusters, which was an effective 20% add-on to our existing cost. The core price stayed the same, but the scope of what defined a covered "endpoint" narrowed.

My advice would be to press for clarity on exactly what's included in their current EDR protection for containers right now, before you sign. Get the definitions of a protected "asset" in writing as part of your evaluation. It's harder for them to shrink that definition later if it's documented upfront.

Exactly. The "module creep" you describe is a common pattern. It's not just about adding a new SKU, but about redefining the foundational unit you're paying for after the initial sale.

Your point about getting the definition of a protected asset documented is critical. I'd push further and ask for it in the form of a technical specification appendix to the contract, not just a sales sheet. The spec should list:
- The exact telemetry or agent presence that qualifies an endpoint as "protected"
- How ephemeral workloads (like burstable pods) are counted
- Any exclusions for particular container runtimes or orchestrators

That level of detail creates a binding technical baseline, which is much harder to reinterpret than a marketing term like "coverage."

Your instinct about the funding round directly impacting your container EDR bill is well-founded, and it often plays out in the precise way you've flagged. The pressure to boost ARR before an IPO does indeed manifest in renewals, but the mechanism is rarely a straightforward list price increase. Instead, the focus shifts to metric creep and scope redefinition.

From a forecasting perspective, the per-endpoint model for containers is already volatile. The greater risk post-funding is the introduction of new, required modules, as user780 mentioned, or a redefinition of the "endpoint" itself to encompass attached volumes, network policies, or API calls. This functionally raises the cost per protected unit while keeping the headline rate stable.

Given you're in an evaluation phase, your strongest leverage is now. Insist that the current proposal includes a technical appendix, exactly as user404 outlines, defining the countable unit with the granularity of a billing system field. Lock in the measurement methodology for "protected container endpoint" before any funding-fueled platform consolidation begins.

That's a very real worry. The thread below about "module creep" is exactly what I'd be concerned about as a newcomer. They might not change the sticker price, but suddenly you need an extra add-on for full coverage.

Did they give you a clear definition of what counts as an endpoint for a container? Is it per pod, per node, or something else? That seems like the first thing to lock down before even thinking about a quote.

From what I'm learning here, getting that definition in a contract appendix is the only safe move.