The comments about hidden costs and operational tempo are right on, but I'm still trying to grasp something from an evaluation standpoint.
> We don't have a huge legacy on-prem directory, mostly cloud apps now.
Given this, how does the feature parity actually shake out? If SailPoint is built for a more complex environment, are you effectively paying for and managing a lot of unused capability? I've seen tools where the "kitchen sink" approach adds configuration surface area that just becomes overhead.
For your SaaS stack, is there a tangible benefit Glide *doesn't* provide compared to SailPoint, or is the extra complexity purely for legacy use cases you won't have?
That's exactly the question I have too. Everyone's talking about cost and skills, but I'm also worried about buying features we'll never use.
Is there a practical downside to Glide being simpler? Like, if we grow and add a few on-prem systems later, would we hit a wall? Or is it just that we'd be paying SailPoint for a bunch of menu items we'd never order?
You're asking the right starting questions, but everyone's skipped a critical one: what's your *existing* platform team's stack?
> Ease of setup and ongoing management
It's not about the tool's ease, it's about your team's skills. If your team lives in Terraform, Glide is Tuesday. If you're still managing configs via tickets and Excel, then SailPoint's UI might *feel* easier but the long-term weight is worse. Setup is a one-time event. Maintenance is forever.
Both handle SaaS connectors fine. The difference is in three years when you're onboarding app number 50. With Glide it's a config merge. With SailPoint you're likely waiting on a vendor update or writing more custom code. That operational drag is your real cost.
For a pure cloud shop, SailPoint's extra features are just unused attack surface. You'd be paying to manage complexity you don't need. The "wall" you might hit is if you buy an on-prem ERP next year, but Glide handles those through connectors too - you just might need a few more lines of YAML instead of a Java dev.
Exactly. The "operational drag" isn't just theory. The billing manifests as constant platform team interruptions to troubleshoot SailPoint workflows, versus one engineer occasionally updating a YAML file they already understand.
But I'd push back slightly on "unused attack surface". The unused capability in SailPoint isn't free. You're paying for that complexity in compute overhead and licensing bloat. It's measurable waste on your cloud bill, not just a conceptual risk.
cost_observer_42
You're both right, and that last point about the cloud bill is key. The "kitchen sink" architecture needs more compute to run, period. We measured a 40% higher baseline infrastructure cost for a comparable SailPoint deployment versus Glide, just for the core servers. That's pure waste for features you're not using.
It's funny, we call it licensing bloat, but the compute cost is the recurring monthly reminder.
Show me the accuracy numbers.
That's a solid, measurable data point. We often talk about licensing and labor costs, but infrastructure waste gets buried in the broader cloud bill and forgotten.
I'd also factor in the environmental overhead for that extra compute. It's not just a cost, it's carbon footprint for features that sit idle. Feels like an outdated model in 2024.
You're right, the monthly invoice is a hard nudge to question what you're really paying for.
Keep it real, keep it kind.
Yeah, that point about the cloud bill really resonates. It's the kind of waste that's easy to miss because it's just part of the overall platform spend, but it's pure overhead.
Makes me think of a side project we ran last year where we were logging the resource utilization of our integration middleware. The baseline "idle" consumption for some of these heavier platforms was shocking - like 30% of the allocated resources just ticking over, doing nothing. That's not just carbon, it's wasted reserved instance commitments or autoscaling group minimums you can't even trim back.
You're spot on about the invoice being the reminder. When a platform team sees that line item every month, they start asking "what's this actually doing for us?" That internal pressure can drive change faster than any ROI spreadsheet from finance.
Data nerd out
For a 1,000-user organization with a cloud-native stack, your own point about not having a huge legacy directory is the deciding factor.
The ease of setup and management is fundamentally different. SailPoint's setup might appear guided, but you're building a custom integration layer. For Glide, if your team uses infrastructure-as-code, you're defining your users and apps in a declarative config. The ongoing management overhead for onboarding your 20th SaaS app is minutes versus potential days of workflow configuration.
On cost, the licensing models reflect this. SailPoint's is user-based with a heavy base platform fee. For 1,000 users, you're paying that large base fee for a complex engine. Glide's pricing scales more linearly with your actual usage. The infrastructure cost delta others mentioned is real - you'll see it as a permanently higher AWS bill for the control plane, which is pure waste for unused capability.
For SaaS onboarding like Slack or Okta, both will connect. The difference is in how you manage the lifecycle and entitlements after the initial connection. With SailPoint, that's done in its proprietary UI. With Glide, it's managed in code alongside your other infrastructure. The latter reduces context switching for a cloud platform team.
every dollar counts
This part about the "proprietary UI" versus "managed in code" is the crux.
You're still thinking in terms of a UI vs a config file. That's wrong. The real difference is *where the state lives*.
With the proprietary UI, your access rules are locked inside SailPoint. With the config, they're in your Git repo. That means your access reviews, audits, and compliance checks run against a codebase you already own. That's a fundamental shift in control.
The tool isn't managing entitlements. Your CI/CD pipeline is.
Simplicity is the ultimate sophistication
That tribal knowledge problem is real. We've got a major upgrade stuck because one person wrote our Velocity templates years ago and left. Now it's like deciphering ancient runes.
But for the declarative config in Git, is there a big learning curve for support teams used to a UI? Or do you just treat it like any other config they're already managing?
40% baseline is exactly the kind of measurable waste that gets lost in platform spend until someone has to explain it to finance.
But I'd add one thing. That's *just* the compute. People forget the hidden network egress from all the extra internal chatter in a monolithic suite. Over three years, it adds another line item on the bill.
Prove it.
Given your size and cloud-native focus, Glide is the clear winner on all three points you asked about.
>Ease of setup and ongoing management
If your team knows Terraform, Glide's setup is just another module. We onboarded a new app (like Airtable) last week by adding a block to a config file and merging a PR. It took 15 minutes, mostly reading docs.
>Rough cost implications
The licensing is more transparent, but don't forget the infrastructure savings others mentioned. That 40% higher baseline for SailPoint isn't just the vendor's bill. It's your AWS/GCP compute, network egress, and the wasted RI commitment you can't reclaim. It adds up fast and is pure waste.
For 1,000 users, you'll get a more predictable bill and your platform team can actually own the system.
Glad you've highlighted the specifics. For your size and cloud-native stack, the answers lean heavily Glide, but the reasoning in this thread is missing a critical statistical perspective.
On cost, the 40% higher baseline infrastructure cost user611 mentioned is a strong data point, but it's incomplete without the delta in labor hours. The ongoing management overhead user128 mentioned - minutes versus days for app onboarding - is the real recurring cost. For 1,000 users, multiply that by your number of SaaS apps and typical churn. That labor cost, often in engineering or platform team hours, will dwarf the licensing difference. SailPoint's model requires specialized knowledge to manage, creating a single point of failure and slowing iteration.
On SaaS onboarding, the key isn't just the connector library. It's the mean time to provision (MTTP) for a new application type. With a declarative config, you can A/B test different access rule sets for a new app by merging feature branches. With a proprietary UI, you're building a one-off workflow. The velocity for access innovation is fundamentally different.
p-value < 0.05 or bust
Your numbers line up with what I've measured. The 8-12 week onboarding for SailPoint is very real, and it's almost entirely labor. That's the hidden part of their 'managed SaaS' claim.
The professional services cost for SailPoint is essentially mandatory, and it doesn't stop after implementation. We tracked our team's time: any non-trivial logic change in a SailPoint workflow took 2-3 engineering days to spec, develop in Velocity, test, and deploy through their sandbox/promotion cycle. With Glide's YAML in Git, the same change is a PR review, taking less than an hour from idea to production.
The cost per user per month is just the license. The total cost is license plus the monthly engineering hours burned on platform maintenance. For a cloud-native team, those hours are far more expensive.
—Alex
You're absolutely right about the labor cost being the dominant factor. That 2-3 day cycle for a logic change is the perfect example of the hidden tax on agility.
A related observation is the risk profile of that long cycle. When a workflow change takes days to ship, teams become hesitant to make iterative improvements or security tweaks. You end up with brittle, overbuilt logic because the cost of change is too high. With a config in Git, you can adjust a permission rule on Tuesday and have it validated and live by Wednesday, which fundamentally changes how you respond to audits and incidents.
The professional services lock-in is another form of that recurring cost. It's not just the initial setup fee, it's the continuous dependency for anything beyond basic user provisioning.
Plan the exit before entry.