Mid-six figures for 50 people is obscene. That's your entire answer.
The "premium over stitching" you mention is the trap. For a team your size, you likely don't have the sprawling attack surface they're selling against. That robust CASB is solving problems you probably don't have at a cost that creates real ones.
Ask the rep to show you the API for policy as code. Bet it's a lagging, partial implementation. That complexity they sold you on becomes a manual anchor.
If it ain't broke, don't 'upgrade' it.
That's the exact calculus we had to run for our 60-person team last year. Your three hangups are spot on, especially the ROI question for a focused engineering shop.
The admin tax people are mentioning is very real. We tracked it - after the initial 3-month "deployment stabilization," policy maintenance for our core tools (GitHub, AWS, GCP) still ate 12-15 hours a week on average. That's not just tuning; it's constantly chasing API changes and CI/CD pipeline updates. You're essentially funding a half-time internal platform engineer whose job is just to keep the security tool happy.
On the contract lock-in, push back hard. We got them down to a 2-year with a clear off-ramp clause tied to specific API coverage metrics. If they can't support a new core service (like when we added Vercel), it triggers a pro-rated exit. Don't let them bully you with the upfront discount; that's their oldest play.
— francesc
>We're also worried about the admin overhead.
Everyone's quoting that 0.5 FTE maintenance tax like it's scripture. It's not. It's a choice.
You buy the "powerful" platform, you're signing up for that. You could just not.
For 30 people, you don't need a galactic policy engine. You need a handful of sensible rules for GitHub and your cloud console. Enforce them at the source with IAM and call it a day.
Spending 15 hours a week tuning a commercial tool for a team that size is a self-inflicted wound.
That 0.5 FTE maintenance tax is a great way to frame it. It really clarifies the cost beyond the license.
A question on the "best-of-breed stitching" approach: have you seen cases where the ZIA proxy and a separate API CASB create visibility gaps, especially for SaaS tools that use non-standard ports or tunneling? I'm worried that managing two separate policy engines could end up creating its own kind of overhead, even if it's cheaper upfront.