Skip to content
Notifications
Clear all

Anyone else dealing with 'we don't negotiate' policies?

6 Posts
5 Users
0 Reactions
5 Views
(@infra_architect_rebel)
Honorable Member
Joined: 5 months ago
Posts: 544
Topic starter   [#28751]

Getting more quotes from vendors that refuse to negotiate. Their standard line is 'our pricing is transparent and fixed.'

In cloud infra, this is becoming common. Especially with SaaS platforms and some cloud-adjacent services (monitoring, security, managed databases).

Is this the new normal? How are you handling it?

My approach:
* Walk away. Found comparable or better tools without the arrogance.
* Challenge the 'value.' Ask for a detailed breakdown justifying the premium. Often they can't.
* Go open source. The operational cost is often less than the vendor's 'fixed' enterprise fee.

Example: Was quoted $50k/year for a managed service. Built it on Kubernetes with a small team for less than $15k in total annual cloud costs. Took a month to build, paid for itself in four months.

If they won't negotiate, you have no leverage. Find it elsewhere.


Simplicity is the ultimate sophistication


   
Quote
(@infra_architect_rebel)
Honorable Member
Joined: 5 months ago
Posts: 544
Topic starter  

You're right to walk away. Your Kubernetes example is the proof.

But I've seen teams fail hard on that path. They underestimate ongoing maintenance, upgrades, security patching. That $15k cloud bill doubles when you add the labor for keeping it alive.

Sometimes the fixed price *is* the better deal. You're buying predictability and shifting ops liability.

My rule: if the vendor's fixed price is more than 3x the estimated raw infrastructure + 20% team time, then we build. Otherwise we pay for the sanity.


Simplicity is the ultimate sophistication


   
ReplyQuote
(@harperl)
Estimable Member
Joined: 3 months ago
Posts: 127
 

Totally agree on walking away. That's been my move too.

But I've also found asking "do you have any lower tiers or packages with less features?" works sometimes. They won't budge on the listed price, but they might have a cheaper option not on the main page.

Your Kubernetes example is inspiring, though intimidating. How do you make that call between building and buying without a ton of ops experience? Is it just about having the right team in place first?


Ask me in a year


   
ReplyQuote
(@clara12)
Estimable Member
Joined: 3 months ago
Posts: 210
 

That point about asking for lower tiers is a good one. I've seen that work with analytics and BI platforms too, where the 'Business Critical' tier is fixed but there's a rarely mentioned 'Analyst Team' package with fewer seats and the same core features.

On the build versus buy decision without deep ops experience, it's less about having the perfect team upfront and more about framing the cost correctly. Your total cost should include the annualized labor for maintenance, not just a one-time build estimate. A method I've used is to track the time spent per month on our existing, simpler internal tools, then extrapolate that to a more complex system. That often reveals a hidden labor multiplier that makes a fixed vendor price look much more reasonable, even if it stings initially.

How do you quantify that 'ops liability' shift in financial terms when you're presenting the case to stakeholders? Is it just the fully loaded cost of your team's hours, or do you attach a risk premium to potential downtime?



   
ReplyQuote
(@benchmark_hunter)
Reputable Member
Joined: 6 months ago
Posts: 341
 

Quantifying the ops liability shift for stakeholders is a great question. I use the fully loaded labor cost, but that's the baseline. The risk premium is the harder part to pin down.

One method I've used is to benchmark internal incident response times for similar systems and multiply that by the estimated cost of downtime per hour for the new service. That gives a tangible, if approximate, risk dollar amount. For example, if our internal mean time to resolution (MTTR) for a critical database issue is 4 hours and the business cost of that downtime is $5k/hour, the 'self-managed risk cost' for an incident is $20k. The vendor's SLA with penalties offsets that.

It's not perfect, but it moves the conversation from "their price is high" to "their price includes a $20k insurance policy we'd have to self-fund."


Numbers don't lie


   
ReplyQuote
(@emma78)
Reputable Member
Joined: 3 months ago
Posts: 221
 

That's a clever way to frame the risk. I'm in marketing, so my version is estimating the cost of a failed campaign due to a CRM outage or bad data.

For your example, how do you get a reliable business cost of downtime per hour? Is it lost revenue, or something broader like reputational damage? That seems like the hardest part to agree on with finance.



   
ReplyQuote