Hacker News Reader

Comment by mjw1007 | Hacker News Reader

I like airtable, but the per-base row limits (50,000 before you reach "contact us for pricing") are too small for many of the things I'd like to use it for.

And there's something a bit odd in their pricing model, isn't there?

The plus tier is $10 per user per month with a limit of 5,000 records per base; the pro tier is $20 per user per month, with a limit of 50,000 records per base.

Suppose I want to use it to replace a spreadsheet where our staff record some kind of work they have done.

If I have a staff of 2 I can pay airtable $20 per month on the plus tier and each person can do work generating 2,500 records in a shared space before I have to upgrade.

But if I have a staff of 50 and I pay airtable $500 per month on the plus tier, each person can only generate 100 records before I have to upgrade. Even if I pay them $1000 per month on the pro tier I'm still worse off on this metric at 1000 records per person.

View on HN

Wearing my SaaS product manager hat I’d say shoot them an email describing your expectations and suggesting your price point. I’ve rejigged product packaging myself in response to high quality/specific presales feedback and reached additional market segments as a result.

And conversely, I have an unmarketed plan with <well known IaaS provider> despite being a tiny customer with no leverage - the point being that the packages marketed aren’t always the complete range available. But you have to ask.

This is especially true for SaaS where the margins are huge and business models are designed to simplify and obfuscate the true costs of running a business.

I think they realize that most orgs that are creating a lot of records will share credentials to reduce cost, so they need multiple tier limits to upsell. I’m okay with this because we share an Airtable login. :)

Are you supposed to share login? Does Airtable's policy permit that?

I don’t know. They have some features that use authorship, but if enough people use a custom select column to handle assignments, etc, I could see them making login share more difficult. In a large enough organization, login share is impossible to maintain because of the need for access control.

I was wondering about this too but I _assumed_ the users compounded the limit versus divide it. Does anyone know for sure how the limits work with multiple users?

Bases are essentially full databases. You can have as many bases as you want. You can share your base (e.g. view only, not edit) to anybody [nonpaying users, nonlogged on users, etc]

If your base has 5,001 records, only users with a $20/month plan can edit that base.

Everyone in your company to my understanding has to have the same plan though. So, you can't have one staff member at a $10/month plan, and another at $20/month plan.

Do you know if you need a separate login, say for the situation where you want to use the product at work and as a separate, single user?

The whole charged-per-user SaaS culture is stupid.

SaaS had to be priced somehow, then someday someone came up with the idea of charging per-user and everybody followed that up, but it is not smart. Most SMB end up sharing accounts, which makes your product look worse than it actually is and at the same time makes your users miserable.

I think for many companies at least it's just the easiest way to somehow approximate value created for the customer. When the business matures one could argue that services should gain a stronger measurement of value created for their customers and charge correlating to this.

With regards to the SMB scenario I agree - and probably it would make sense for many services to have a base bundle tier with 5 or so accounts. And then price it based on some minimum value created. But also hard to do this if your competition is offering 1 user for $2.99.

That's one of the reasons I love Basecamp's pricing model - a flat $99/month for as many users as you'd like.

We recently decided to follow that path, but for us additional users will not have any significant increase in cost.

SMBs work that way, but it's an interesting way into the enterprise through "dark procurement" (essentially teams going rogue, buying a service without IT's knowledge, IT finds out, a business case is made... and boom... 2000 paying users instead of 1, having managed to subvert the usual pitching processes).

I agree, it's not right for a lot of products (some of which are better charged at a flat fee, or a per "thing" basis), but it's not a stupid decision for a lot of businesses.

I agree with you that per-user pricing doesn't make for an ideal SMB experience. We specifically avoided it for our SaaS tool for the reasons you mention.

That said, the costs of SMBs getting away with one login do not outweigh the benefits of getting to charge enterprises per user. Most of these tools with free tiers and per-user pricing (Slack, Airtable) make most of their money from enterprise, not SMB.

Therefore I don't agree with you that it's "stupid" or "not smart".

if they are comparing Airtable with Spreadsheet, why there is a constraint on # of records unlike spreadsheet(although Excel sheets are limited to 1.048m or so records per sheet but that's plenty I think to work with)? They do have another constraint for free account allowing only 2GB storage but then that alone should be enough and they should just allow adding as many rows as one can until one gets maxed out with this 2 GB storage.

My guess is that it's mostly a technical limitation (and that the reason why services of this sort haven't taken over the world is that everyone else runs into a similar limitation).

And there's cost of its underline infrastructure, presumably it's on AWS or Azure, all cost real $$$. Users with free account, I will assume a bulk load of them, even though limited to 1200 records per base, the resources cost still eat into their bottom line.

It's also a provisioning problem. Let's assuming that the new pricing model is based on usage per user, like 50,000 records per user, and how are you suppose to track each individual record, even that is possible, it would not be very practical as the every CRUD operations would require a record count referenced to the user. Keep X records per Base makes the operation a lot easier and technically much more feasible.

I wouldn't suggest anything so complicated. Rather (if it isn't a technical limitation), I'd suggest they increase the per-base limit for customers who pay for more users, or else add a third paid tier above 'pro'.

They do have a 3rd tier. “Contact us” is probably the tier you want.

Yup I considered migrating from google sheets but limits seemed too low for what I wanted. Sheets isn’t great, I split to multiple spreadsheets when I hit the limit but it works for me

Actually you can do a lot of amazing stuff already with google sheets, like sheet2site.com and sheetsu.com. However, Google api caps the free daily request to 1000.

Reply on news.ycombinator.com