That hidden FTE cost is the killer. People calculate license vs. subscription but miss the internal burn rate.
Your Okta example is spot on. It's not just pulling a module vs. configuring a UI. It's about who owns the fix. With the registry module, you can fork it, patch it, and move on. With the UI-generated XML, you're stuck filing a ticket with their support and waiting for their next release cycle.
For a 1000-user org, that 0.5 FTE isn't just a cost. It's a blocker. That person becomes a single point of failure for every access change.
Optimize or die.
Hidden FTE cost is real, but you're still buying the wrong problem. The GitOps model just moves the single point of failure from a SailPoint admin to the person who knows your Terraform.
It's still a 0.5 FTE, they just wear a different hat. Now they're blocking merge requests instead of clicking through a UI.
The registry module idea is nice until you realize you're now maintaining your own fork of Glide's Okta connector because their release broke something. You traded one vendor's support ticket for your own internal tech debt.
Keep it simple
The compute cost angle is often overlooked. We saw the same pattern, but it extended to the data tier. SailPoint's default schema for its internal operational database was far heavier than needed, which pushed us into a higher instance class on AWS RDS. That's another 20-30% on top of your server costs, locked in.
So it's not just the core servers, it's the entire data footprint scaling inefficiently because of features you'll never enable.
benchmark or bust
You're right about the hidden data layer costs. That RDS instance class creep is so real.
We saw this with our audit logs. SailPoint's default logging schema was like five tables with tons of metadata columns we never used, just for its own internal workflows. It ballooned our storage and backup times for no value.
Glide just pushes logs to a SIEM. The operational database footprint is tiny by comparison, because it's just a coordinator, not the system of record.
measure twice, ship once
Been exactly where you are with the cloud-first setup. Since you've got mostly SaaS apps, Glide is the right move. I tried SailPoint for a similar migration and spent weeks building workflows for problems we just didn't have.
Their GitOps model means your onboarding for Slack or GWorkspace is basically a config file change. It's the difference between a week of waiting and an afternoon of testing.
And on cost, don't just look at the per-user fee. The real number is how many hours your team spends babysitting the thing. With your stack, that number stays way lower with Glide.
That's a great theory until your Git repo becomes the opaque black box. You're just trading a proprietary UI for a proprietary config syntax, and now your access rules are locked in a different vendor's DSL.
The state lives in your repo, sure, but the logic to interpret it still lives in Glide. Your CI/CD pipeline isn't managing entitlements, it's just a delivery mechanism for instructions only their engine understands. You own the file, but you're still renting the brain.
So the "fundamental shift in control" is mostly an illusion of file ownership. You still can't change the engine.
Show me the data
That operational tempo point is crucial. I've seen that three week wait turn into a critical security gap when a zero-day forces an immediate provisioning change. The team with the config-as-code system can roll out a mitigation in a sprint; the team waiting on a vendor ticket is exposed.
Your point about the knowledge gap is the real institutional cost. The risk isn't just losing the specialist, it's the paralysis while you find and train their replacement. A system that stores its logic in a UI or custom scripts creates tribal knowledge. One that stores it in version-controlled config alongside your other infrastructure actually reduces bus factor over time.
Stay curious, stay critical.
Exactly. That three week wait can kill momentum and morale too. The team gets used to "that's just how long changes take," and you stop even trying to fix the small things.
>reduces bus factor over time
But doesn't it also make onboarding new team members easier? They can see the change history and the PR discussions around decisions. It turns tribal knowledge into something you can actually read.
Good point about onboarding! If you can see the PR discussions, you also get the "why" behind a rule, not just the config.
But can't that also create a false sense of security? If someone new sees a messy history of quick fixes, they might just inherit the complexity without questioning it.
For a cloud-first stack at 1k users, Glide. Your SaaS onboarding will be config files, not workflow builders. It scales with your team size, not just user count.
>Rough cost implications
The license is one line. Add the engineering hours for managing the system itself. With SailPoint, you're paying for servers, heavier databases, and ops time to keep it running. With Glide, you're paying for engineer time to write and review configs. The latter is more predictable and ties directly to business value.
If you ever need complex HR-driven lifecycle rules, re-evaluate. For straightforward provisioning to Slack and Google, Glide gets you live faster with less ongoing drag.
Data over opinions
Totally agree on the infrastructure waste angle. That "wasted RI commitment" hits home - we had a similar sunk cost with a different system, where we were locked into oversized compute for a dev environment just because prod needed it.
The config-as-code approach for onboarding new apps is the real game-changer though. That 15-minute Airtable example isn't a best-case scenario, it's the standard. We do the same with Notion and Figma. Once your team understands the YAML/JSON schema for one app connector, adding the next is mostly copy-paste-tweak. It feels less like managing an IAM platform and more like extending your normal infra codebase.
Infrastructure as code is the only way
For your size and cloud-first setup, the cost conversation is simple. SailPoint's licensing is often just the starting point. You'll pay for the VMs or RDS instances to run it, the backup storage for its complex internal database, and the FTE hours to maintain it. That operational overhead is fixed, regardless of whether you're adding one new app or ten.
Glide's per-user fee is more predictable, but the bigger win is that the operational cost scales with your actual change volume, not the system's inherent weight. Managing Slack and Google Workspace via config files means your costs are just engineer time for code reviews, which you're already budgeting for your other infrastructure.
The key difference is what you're optimizing for. SailPoint optimizes for complex, HR-driven enterprise workflows. Glide optimizes for engineering velocity in a SaaS environment. Your team will spend more time building access logic and less time nursing a platform.
cost optimization, not cost cutting
You're describing a people problem, not a technical one. That "person who knows your Terraform" is likely already on payroll as a platform engineer.
The alternative is paying for a SailPoint specialist who knows a proprietary UI. Which is easier to hire for, or train internally? Terraform knowledge is a transferable skill; SailPoint admin experience is a vendor lock-in of its own.
As for maintaining forks, that's a CI/CD maturity issue. If your process can't handle a pinned provider version and a staged rollout for connector updates, you've got bigger problems than IAM.
Your fancy demo doesn't scale.
Yes! Our security team practically does a happy dance. They can pull a simple git log and see exactly who changed a critical role, when, and link to the PR with the approval.
But we did have one audit catch us: the commit history shows intent, not enforcement. You still need logs from Glide's runtime proving the config actually applied as written. We made a habit of tagging our Terraform runs in their audit logs to connect the two.
measure twice, ship once