Alright, let's cut through the usual vendor fog. You're a 200-user SaaS company. Your cloud bill is already a hydra I'm sure, and now you're looking at identity platforms. Glide vs. Identiq isn't about features on a sheet—it's about which one will quietly drain your engineering hours and budget, or actually save you both.
I've seen too many teams pick the "enterprise-grade" option and then spend months untangling custom SAML mappings just to save on user licensing elsewhere. For your size, the calculus is different. You need something that works *now*, scales without a dedicated IAM team, and doesn't make your devs want to set things on fire.
Here’s the blunt breakdown from a cost/ops perspective:
* **Glide** pitches itself as the developer-friendly, API-first platform. That translates to: easier integration if your app is already modern microservices. Their pricing model tends to be per-active-user, which for 200 users is predictable. Watch out for the "enterprise features" tax if you need advanced audit logs or custom roles later.
* **Identiq** often gets tagged as more "robust" for B2B scenarios. This means heavier federation options, which is great if your 200 users are actually employees needing SSO to a dozen other tools. But "robust" can mean more complex setup. Their sales team will likely push you towards an annual commit for a better rate.
The real question isn't which is "better," but which matches your *spend profile*. Are you:
- A. Primarily managing internal employee access to AWS/Azure, GitHub, CRM, etc.? (Leans Identiq for broader SSO)
- B. Providing identity as part of your *own* SaaS product to *your* customers? (Leans Glide for embedded auth)
- C. A messy mix of both? (Then you need to run a proof-of-concept for both, because the devil is in the conditional access policies.)
My sardonic two cents? Start with a brutally honest audit of your last month's cloud bill. If you're heavy on AWS, maybe Azure AD isn't even in the picture. If you're using a ton of spot instances and Lambda, you need an identity platform that plays nice with temporary, just-in-time credentials. A platform that can't handle short-lived access keys might be a non-starter.
Run a simple script to see what you're *actually* connecting to. Can't hurt.
```bash
# Quick & dirty count of distinct IAM principals in AWS logs last week (idea, not production-ready)
aws cloudtrail lookup-events --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)
--query 'Events[*].Resources[?ResourceType==`AWS::IAM::User`].ResourceName'
--output text | tr 't' 'n' | sort | uniq -c | sort -nr | head -20
```
This tells you if you have a sprawl of IAM users (an argument for better platform control) or if everything is already federated.
Bottom line: Don't buy the dream. Buy the thing that reduces your total cost of ownership, not just the per-user license fee. And for the love of all that is holy, get a trial where you test the break-glass procedure. If it takes you more than 5 minutes to get admin access when the system is broken, you've chosen wrong.
- elle
- elle