Billing for application users

HI there,
Just wanted to check the billing for user of an baserow application. As in, someone who will log in to use the application itself, rather than have access to the database itself.
Does anyone who has access to the application and is able to edit or create data count as a billable user?
Thanks for the clarification on this.

Hi @Matt, the AB pricing isn’t defined yet, but yes, we plan to charge per logged-in user per application. :point_down:

Thank you. DO you have any guidance on what those charges might be yet? Does that mean they are effectively free currently?

Hi @Matt! We’re planning to charge ~$4 per logged-in user per workspace monthly, with custom pricing available for larger user counts.

Yep, currently, the Application Builder is completely free. :slightly_smiling_face:

2 Likes

Wow! Good to know. Thanks again.

1 Like

Do you think its possible to consider a usage charge based on frequency of use as opposed to a simple per seat model… or maybe a pool of concurrent users? My anticipated use case could see a large number of users, but most only use the system a few times a year. A per seat model obviously would kill the idea sadly and require a different approach.

Update: Spent today reviewing how other services offer pricing. I noticed most that are seat based are quickly discarded in my review - Eg Airtable, etc. A usage based option, similar for example to using API calls with AI services, would be much more attractive personally. Maybe that is harder to implement but it might also provide a competitive advantage. :thinking: I’m surely not the only one trying to build something for a not-for-profit that simply won’t work with a per seat cost model.
I like Make.com for this reason. A service that scales costs to usage feels more reasonable when it come to the bill. :blush:
Curious on thoughts here as I’m not going to invest more effort to build something if the above is the likely model, but understand its early days in the strategy planning. :+1:

Thanks for sharing your feedback @DataGecko! I’ve shared it with the team to review. :raised_hands:

1 Like

does it means that application that we created today will be charged in future in order to uses it?

Much better indeed. Prefer usage billing over per seat cost model.

Thanks. I realised that the Advanced subscription for existing Baserow provides free read/comment users, which is good. The same idea for Applications could be good. Very keen to see the mechanism for determining a user type. Will there be a special field type in the db that maps to a paid (edit) user in the app I wonder? :thinking:

Hey @DataGecko, we plan to charge per application user per workspace. The app builder will be separate from the database license—you won’t need to purchase a database license to build apps. We want to offer the app builder free to builders, while only charging the end users (those who log in).

Thanks so much for providing some clarity around this, it is really helpful to understand.
So, do I understand it correctly that if you sign up for an App builder plan that will also include your database workspace, so as a developer there is just a single subscription that gives you a workspace with databases and applications you build. Then, if you want to share you applications with users, each user will need a license to log in to any apps in that workspace. So you could have multiple apps, but as long as they are in the same workspace, a user subscribed to that workspace can log into them. Have I got that right? :thinking:

Hey @DataGecko, let me clarify how it will work:

  1. We offer Premium, Advanced (SaaS-only), and Enterprise (self-hosted only) plans. There’s no separate “app builder” or “database” plan — you just subscribe to one plan for your entire workspace (SaaS) or instance (self-hosted).
  2. Each plan includes a specific number of “application users.” This means your workspace/instance comes with a quota of users who can log in to your applications for free.
  3. Important note: A single user who accesses multiple applications counts multiple times toward your application user quota.
  4. We monitor usage every hour and notify you when you exceed your allowed number of logged-in users.
  5. When the Application Builder exits beta, we plan to implement soft limits rather than hard ones initially—you’ll simply receive a notification if you exceed your quota. Later, when hard limits are in place, you’ll need to purchase additional seats for any users over the limit to log in.

Hope this helps clear things up!

That is very helpful yes. Thanks! :green_heart:

I do have more questions, and sorry if the details for the answers are not yet worked out, I can appreciate that might be the case. Referring to your points…

  1. Excellent
  2. I guess its too early to know what the quote of users will be, but I like this approach!
  3. Fair enough.
  4. Sounds good.
  5. Curious how this will work. Will it be integrated into the workspace roles? Will your app users need to join Baserow to get the appropriate role? At the moment you can use any table to contain a user list for an app and designate that for your authorization to an app. Will that remain, but have some kind of back-end role/license lookup on login to the app? Wondering how this will work in the future?
    image

The Advanced plan becomes much more tempting if it has a bigger quota of included users, and the ability to have read-only app users (commenter and viewer equivalents but in the app?). That is super important to have I think as you can have a larger set of consumers of the information in the app (viewers), and then a smaller set of editors of the information which would be licensed users. Is that likely how it will work?

Sorry for all the questions, but I think many people will be interested to get a feel for the direction this will go so they can plan accordingly. :pray:
Excited to see how the progresses.

I’m not a fan of the per user per workspace pricing. I work in education and we would have students using multiple applications from different departments. Each department would have its own workspace. This could drive up the cost significantly. I know you are following Airtable’s pricing model, but honestly their pricing model is one of the main reasons people look elsewhere.

I would like to see pricing based on monthly active users. For our applications we have some months that have high usage and then the rest of the time the app sits pretty dormant. It doesn’t make financial sense to pay for 12 months of a user that is only using it 2 months out of the year.

Hey @DataGecko :wave:

In Application Builder, we have user sources, which control how authorization works for your apps: User sources.

@jrmi are there any plans for adding different authorization options for the Application Builder?

Hey everyone,

Users in the application builder are completely separate from Baserow users. The roles defined in Baserow do not apply to application users.

In applications, roles are defined at the user source level and control visibility of elements as well as read/write access to data. All application users with an account are charged equally, regardless of their roles.

Regarding read-only users (equivalent to commenters and viewers in Baserow), users do not need an account to access public pages, and these users are not charged. These are the “read only users” of application builder. We intent to limit page views (on SaaS) in this case.

To answer some other topics:

We plan to introduce the ability to deactivate unused user accounts, ensuring they are not charged when inactive. Would this at least partially address your concern?

Not really. This would require a lot of maintenance. I work for a graduate school and just there we would need to manage approximately 2500 people. I couldn’t imagine what a larger organization would have to do to manage all those records across multiple applications.

Also the usage isn’t really 2000 for 2 months and then 0 for 10 months. It would be:

  • Jan 1200 Users
  • Feb 900 Users
  • Mar 20 Users
  • April 25 Users
  • May 22 Users
    etc.

So the application needs to be available to them, but it just won’t be used as often. This is where Monthly Active Users (MAU) really comes in handy.

Also charging per workspace is difficult. According to the pricing mentioned above, if they log into applications in 5 workspaces then I might as well purchase a full license. If I don’t keep an eye on that then if they log into applications in 6 workspaces now I’m paying more than if I would have just bought a regular license. Right now in Airtable we have 44 workspaces. So you can see how this could easily get out of hand.

There are 2 things that are important to us as far as pricing. Value for what we pay and consistency. We don’t use a credit card to pay so it’s difficult to be charged $600 one month and $3127.45 the next month. So I suggest a tiered MAU. Ex.

  • 50 MAU Free
  • $10/mo per additional 10 MAU above 50
  • Once you hit 250 MAUs $9/mo per additional 10 MAUs
  • Once you hit 500 MAUs $8/mo per additional 10 MAUs
  • etc.

You can adjust the numbers to meet your needs, but that’s the idea. I know this probably would amount to less than what you would make in your current plan, but to be honest with your current plan I wouldn’t be recommending Baserow for our school.

Sorry, I have another question as I’m still a little confused. I understand that the App uses a table in the db for the user source.

That table we create ourselves. In this case the table, called members, has 3 rows. Does that mean once I connect a table to the app as the User source, the number of rows in that table will be the number of user licenses for the app?
So, similar to the Password field, will you add a ‘deactivated’ field type to use to flag for billable v’s inactive members? You’d need something specific like that.

If I understand it correctly, the Role field for apps is just used by the app for finer access control, and doesn’t relate to user billing aspect.
So, basically the number of rows in your user table is the number of licenses consumed by your app (unless there is the special flag field to deactivate a user).
Have I got that right?

You can have multiple user sources it seems, but I have not tried that and not sure what impact that has. :slight_smile: