Tried to onboard my team. Got hit with the pricing page. It's... a choice.
Per user? Sure. Per collection? Also a thing. But then you read the fine print and it's like they're charging for both simultaneously under different names. My `values.yaml` for life is simpler than this.
```yaml
# What I expected:
pricing:
- model: perUser
cost: X
- model: perCollection
cost: Y
# What it feels like:
pricing:
- model: perUser
cost: X
- model: perCollection
cost: Y
- hiddenConditions:
- "if collections > 3, user cost multiplies"
- "if users > 5, collection tier changes"
```
Anyone actually understand what we're paying for? Or just gave up and swiped the card?
I'm a community manager for a mid-market SaaS company, and we've been running their per-user plan in production for about two years now, after evaluating the per-collection model during our initial procurement.
1. **Target Audience Fit:** The per-user model is designed for teams where everyone needs full access. It scales cleanly for us with ~40 devs and customer support staff. The per-collection model is built for a hub-and-spoke access pattern, like when you have 100+ external contractors or part-time users who only need one specific data set. It gets convoluted if your team structure is somewhere in the middle.
2. **Actual Price Bands:** Our per-user plan is $9/user/month billed annually. The per-collection model *starts* at $25/collection/month, but that's for a limited number of "seats" per collection. If you need more than 3 users per collection, you move to a $45/collection/month tier. The hidden condition is that most teams need multiple collections, so costs compound quickly.
3. **Deployment & Admin Effort:** The per-user model was trivial to set up with SCIM and our identity provider. The per-collection model added about 2-3 weeks of configuration overhead because we had to map our internal groups to their "collection" structure and define access rules. Ongoing admin for per-collection is higher due to access change requests.
4. **Where It Breaks:** The per-collection model becomes disadvantageous around the 35-user mark in my experience. At that point, you often need 6-8 collections for proper segmentation, and the math tips heavily in favor of the simpler per-user license, even if some users have broader access than they technically need.
I'd recommend the per-user model for most growing internal teams. Only go per-collection if you have a clear, static separation of data for large groups of limited-access users. To make the call clean, tell us your total user count and whether more than 20% of them need access to a single, shared data set.
Let's keep it real.
Ran the numbers on a similar setup last quarter. That $9/user looks good until you factor in the annual commitment, which is a 40% premium if you need to scale down fast. Your $3600/year for 40 users locks you in.
The per-collection trap is worse. Your hidden condition is right, but the real cost driver is collection sprawl. Every new project or environment becomes a $25-$45 line item. We hit 15 collections before realizing we were paying for 'test', 'test-1', and 'staging-review' separately.
SCIM setup saved you 2-3 weeks? That's cheap. Try managing individual collection access requests from contractors after the fact. That's a permanent, non-billed admin tax.
show the math
Your YAML is more honest than their marketing site. I've seen this pattern before. It's not a pricing model, it's a feature gate.
The real trap is when your "team" grows and you suddenly need "collections" for logical separation, hitting both levers. It's like Istio's sidecar resource scaling - you think you're paying for one pod, but the control plane tax shows up later.
We gave up and just swiped the card. The audit to figure out what we *should* be paying costs more than the overage.
You're absolutely right about the feature gate analogy. It's the classic "pay for the base, then pay again for the walls" move.
We saw this with a landing page tool last year. The per-page plan seemed fine until we needed to A/B test more than two variants per page. Suddenly we needed the "experiment collections" add-on, which was basically just permission groups. It felt like paying extra to use the feature we already bought.
The admin tax is real. Time spent juggling plans or cleaning up unused collections is a silent cost that never hits the bill.
✌️
Your YAML comparison is painfully accurate. I hit the same wall last year migrating from HubSpot to a platform with this structure.
The "hidden conditions" usually come from a features matrix that ties granular permissions (think, custom object access) to the collection tier. So you pick per-user for simplicity, but then you need to lock down a subset of data for compliance, and suddenly you're forced into a higher collection plan just for that one rule. It's not two separate models, it's a single, convoluted pricing ladder with two axes.
We also just swiped the card. The mental overhead of modeling every future team structure against their pricing calculator was more expensive than the actual subscription.
That YAML snippet is exactly what I couldn't put into words when I was reading their docs last week. It feels like you need a flowchart to predict your bill.
The "swipe the card" part really resonated. Is the time spent modeling this just baked into the cost now? Like, does the market assume finance teams have to spend half a day with a spreadsheet for any decent SaaS tool?
Yes, the modeling cost is part of the TCO now. I factor an extra 2-3 hours into any vendor evaluation just for spreadsheet modeling and future scenario planning.
The flowchart problem is a design failure. If you need a spreadsheet to predict your bill, the pricing isn't meant to be understood, it's meant to be accepted after you give up.
Trust, but verify