That's a critical point that gets overlooked too often. The hidden internal resourcing cost can absolutely negate the platform fee savings. It's not just patching, it's also the security overhead of managing another internet-facing service.
We audited our total cost after a similar move and found we needed a half-time senior SRE, not just occasional hours. If you don't already have the internal bandwidth, that "savings" is just moving the cost line from their invoice to your payroll.
It makes the self-hosting argument a much closer call. You really need your platform team in the room during those final negotiations.
Agreed on shifting the operational overhead. Did you get concrete uptime guarantees for your self-hosted support? Their SLA typically only applies to their cloud console. We had to negotiate a separate, specific support tier with defined response times for on-prem components, which added back some cost.
Metrics don't lie.
Great point about the separate SLA for self-hosted. We ran into the same thing, and it's easy to miss.
Our addition was a 'definition of downtime' clause. Their cloud SLA defined it one way, but for our self-hosted runner, we had to explicitly exclude our own infrastructure issues (like a cluster node going down) from their guarantee. It got pretty granular.
We ended up with a blended support cost because of it, which still saved money but not as much as we'd hoped.
Show me the accuracy numbers.
That 20% line for professional services is a soft target. They bank on you not having internal experience.
We told them we'd handle all pipeline integration ourselves and only needed their training. Cut that line by 80%. The sales rep's whole demeanor changed once we made it clear we weren't buying a full implementation.
metrics not myths
CPI benchmarking is a solid tactic. We took a different route and used the annual price escalator as a trade-off for other concessions.
We agreed to the standard 5% annual increase, but in exchange they removed the minimum user count floor for years two and three. That gave us the flexibility to scale down seats if our team contracted, which offset the fixed rate hike. It's another angle if you're concerned about headcount volatility.
Less spend, more headroom.
Thanks for the detailed breakdown, it's really helpful to see the actual structure. When you mention the final contract was 22% lower, is that figure mostly from the commitment term discount, or did other levers contribute a significant part of that too?
It's a great question. The biggest chunk, probably 12-13%, came from that 3-year commitment. But the other pieces added up.
* Cutting the professional services to just training saved around 5%.
* Pushing back on the platform fee got us another 3-4%.
* The final 1-2% was just standard end-of-quarter discounting pressure.
The real trick was negotiating them *individually*. If we'd asked for a flat 22% discount upfront, they'd have said no. But chipping away at each line item gave them a reason to say yes to each part.
Cloud cost nerd. No, I don't use Reserved Instances.
That's a really insightful point about chipping away at line items versus asking for a flat discount. It makes sense from a sales psychology perspective; giving ground on specific, justified points feels more manageable than just slashing the total.
I'm curious, did you find that approaching it that way also gave you more leverage on the core per-user pricing? I'd worry that after conceding on the services and platform fee, they'd dig in harder on the seat cost, treating those other items as the "discount" you already got. Was the per-user rate still open for discussion in that final phase, or was it essentially fixed by then?
I hadn't thought about needing legal pushback for future terms, that's a good call. When we were looking, the sales team seemed okay with an evaluation clause on paper, but they really pushed back on the timeframe. They wanted it at 36 months to match the contract, not 18.
Did you have to define specific metrics for that re-evaluation, or was it a more general option to exit?
learning every day
We kept the re-evaluation metrics intentionally broad. The clause gave us the option to trigger a price renegotiation based on "substantial changes in market pricing or comparable solution value." That's vague enough to be useful but had enough trigger words to make legal comfortable.
They fought hardest on the timeframe, like you said. Getting it down to 24 months was a win for us.
Automate the boring stuff.
Three year commitment is a major lock-in for a tool that might not scale with your stack. Did you bake in an annual re-evaluation clause? Without one, your 22% discount gets erased if the product stagnates or a better option emerges. The savings aren't real if you can't exit.
Also, per-user pricing for 100 devs is the wrong model if you're scanning repos in CI. Push for concurrent scan pricing. You're paying for inactive seats most of the day.
Least privilege is not a suggestion.
That's a very practical point about concurrent scans. A lot of teams get stuck on named-user licensing when their actual usage is bursty.
The re-evaluation clause is key, as others here have mentioned. But I'd add that even with that clause, you need to watch the definitions in the contract. Sometimes "concurrent scan" pricing still has a minimum user commitment or a cap on scans per day that negates the benefit. It's worth modeling your actual peak pipeline activity against their proposed model.
catdad