I see three main overlapping roles:
- System Developers
- Data Producers
- Data Consumers
In general there tends to be fewer developers than producers/consumers. In some business models, developers have to pay more than producers/consumers. (e.g. you pay to develop the system, but the system is free for your users). In other business models developers pay less (e.g. developer for free, pay only when you publish or pay per end user).
If the goal is to democratize software creation, it makes sense to have the same bill rate for developers as producers/consumers. It lowers the bar for someone to become a developer. Thus, while some may grumble that editors have to pay the same as creators for less functionality, I don’t see this as problem because I favor lowering the bar to becoming a developer.
When it comes to data producers, I see four really broad sub-categories:
- regular users who need consistent, full access
- limited users who need only partial and/or intermittent access
- form users who submit data, but do not read any data
- non-human data producers, such as api users
People accept that they must pay for regular users who need consistent, full access. However, people don’t like paying the same amount for limited users who need only partial or intermittent access. It is these limited users that Airtable’s pricing model does not currently address.
The intermittent access issue is sometimes addressed using “floating licenses” or “concurrent licenses”. One challenge with this method is how do you count one Airtable collaborator who is logged in and using multiple instances of Airtable at the same time.
The partial access issue has much tricker technological issues. Airtable’s original architecture was designed to make sharing information easy, and changing it to securely limit read access would probably be very complex. Preventing read access is actually much more difficult than just hiding a table in the user interface. I think Airtable decided that in order to securely “hide” selected data from users, a new interface was needed. (Think about it–all those third party portal systems that provided limited access to Airtable data all have their own user interfaces.) I think that Airtable’s “Interfaces” is a necessary step towards native support for limited read access.
The pricing model change to address these partial-access users also cannot be rolled out until after the method for providing partial access exists. I suspect that Airtable has already been investigating pricing model changes, but has not announced any because there would be no point when the underlying architecture is not ready.
The form users use-case is addressed with Airtable’s forms. These forms are not as robust as people would like, but AIrtable is not in the business of generating complex forms. Of course it would be nice if there were more options for customizing Airtable forms, but where does it end? There are many companies that do provide complex form services.
I also find it interesting that non-human data producers/consumers (REST API usage) do not incur additional fees from Airtable, but other businesses charges additional fees for API access.
Consumers. Airtable is actually really generous when it comes to people who are only consumers of data. Read-only collaborators are free across the board. Sharing filtered views is free. API access to publish using a 3rd party service is free.
Of course, people want even more sharing (e.g. sharing dashboards), but that involves read-only security. As before, I think that interfaces is a step towards read-only security–and there is even a “dashboard” layout.