Yes, that is making a lot more sense now. Thanks heaps for the clarification. 
I agree with many others here. you should charge based on active users, not just users. Thatās the trend anyway with any type of service like this. We may have 1,000 users of an app, but only a tiny percentage actually use it on a monthly basis because people donāt order every single month. So to pay for non-active users in a month when they donāt log in, would be a non-starter for us and I think most businesses.
Before doing $4 a month per active user, appreciate the active part here, I still think itās quite a lot.
Using something like Softr, itād be $49 up to 20 users, $139 for 100 users and $269 for 2500 users. Thatās $2.45, $1.39 or $0.11 per user.
Yes then Iād be back at proprietary software which canāt be self hosted, but the price difference is substantial.
1 Like
Hi @olgatrykush, do you have any news regartding to this topic (application user licensing). Iām interesting in your timing to release new license counting. Thanks a lot for info.
BR, Frodo 
Hey @frodoslav, weāre not sure yet to be honest. As soon as I have more details on this, Iāll share them here 
Hi @olgatrykush, OK, Iāll wait for the information.
BR, Frodo
1 Like
Hi everyone! I wanted to chime in on this topic as well.
Iāve been researching low/no-code databases (as an alternative to shared Excel sheets full of macros in conjunction with Doodle style survey tools for data input) for a bit now and came across Baserow, which seemed like it does everything we need it to do. I got really excited about the possibilities ā¦ well, until I stumbled across this thread.
We are also dealing with the need for an online database with an end user facing interface (here: application) that offers limited interaction/editing capabilities for around 250 users. However, these application users will probably only interact with the database 2-3 times a year for updating their availabilities and checking a schedule. For the rest of the year, these user entries remain dormant in the database.
For context: Our use case is a yearly event with lots of volunteers or minimum wage/part time jobs where everyone needs to update their own availability and can check whether they have been put on the roster or not. Calling these people "application usersā therefore feels like a bit of a stretch if you know what I mean (all they will usually do is: log in ā tick some boxes ā close browser). Since we also have very specific needs as to what is stored in the database, we couldnāt find an out-of-the-box management tool that works for us so the only solution seems to be to create something ourselves.
While I understand why the seat-per-month billing method has been widely adopted (itās just simple to communicate), it does not really fit our use case and financial constraints and I would love to see someone come forward with a billing method that reflects this usage type. And by reading this thread, it feels like Iām not alone with this.
There seems to be a big price gap in the market from our current method (I like to call it: puzzle-and-duct tape) to using an actual database. Once you evolve from the spreadsheet type tools, the costs outright seem to explode with no vendor trying to offer something in between. I used to do a lot of programming in FileMaker back in the days but the pricing is just insane these days.
I would really love to see someone offering either a dynamic and affordable active-users-per-month billing option or, possibly even better, something like a concurrent active users license, essentially limiting the amount of user who can log in at the same time (until they either log out or their session times out).
Maybe this feedback also helps in evaluating the market potential for affordable pricing options when databases contain a lot of dormant users and where deactivating or deleting them really is not an option.
Best
Michael
1 Like
Thank you for your feedback, @MIB. Weāre currently discussing the Application Builder pricing model, and community input like yours is very useful in helping us align it with our usersā needs. Weāve shared your use case with our Sales team for their review. 
Wow, Iām getting the hang of BaseRow. Itās still lacking a lot in the app builder (variables, conditionals, UXā¦), but Iāve seen some announcements about improvements and it sounds promising. And then I suddenly come across this thread. Well, in the end, the free market prevailsātime will tell.
I just found this thread, and hadnāt previously seen any documentation or notifications that user group license fees would be added later to the app builder. Will fees for users also be added to the open-source version? I have several clients whoāve started learning the builder, just in the early stages. Fees for users in the self-hosted version would keep them from using the builder, and perhaps Baserow altogether, since there would be no open-source option to provide fine-grained authenticated access to Baserow databases.
Hey @NickAntonaccio, the Application Builder pricing model hasnāt been confirmed yet, but what we currently have in mind is that Application Builder remains free to builders, while only charging the end users who need to log in to access the application. We are also going to monitor activity on a monthly basis so we donāt charge for inactive users. This is not a confirmed modelāplease keep this in mindābut once itās confirmed, I think the same logic will be implemented for all plans, including the self-hosted ones.
Hi Olga,
Thank you for the response, I appreciate how much of a challenge it is to generate revenue, and I only hope to see Baserow grow and become stronger as a business. All of my clients currently using Baserow love the interface, and I love extending it for them - it sets up a really nice working environment for everyone. I expect that most commercial clients will have no issues paying your existing fees - theyāre well thought out and the features are worth the cost.
My unrequested 2 cents of perspective is that any organization which has many users, and which hopes to use the open source version, will be kept from choosing Baserow as a platform, if there is no way to provide authenticated access to large user groups - for example, for a public web site/app which requires some user account configuration/personalization for many web site users, but for which there isnāt necessarily a recurring revenue stream established for each of those users.
For my clients who are exploring and beginning to commit to Baserow as a foundation for their internal operations, the existing commercial license fees are entirely reasonable. For a company with 50 employees, paying a few thousand dollars per year to get white labeled front ends, fine grained user access controls in the database UI, calendar/kanban/etc. views - that fits in well with expected technology fees.
What I understood your plan to be, previously, was that the builder would provide a way for the open source community to build authenticated access to the database, with some extra work that most of your database-only commercial users donāt want to have to deal with (instead, they just pay for fine grained user access to the database). That seems like a solution which is attractive to the open source community, without necessarily interfering with your commercial subscription database user base.
If that licensing path doesnāt work, has your team considered an approach which some other open-source no-code tools establish, which is to charge only for organizations which exceed a yearly threshold of revenue, investment, etc. One well known alternative product, for example, allows free open-source use for any organization with less than $5M fundingā¦
Iāve used several other products over the years, which have both SAAS and open source offerings, and SAAS enrollment stays strong in those communities, despite the availability of self-hosted options. From my point of view, open source users are just a different group from SAAS users, and the open source crowd will simply abandon the platform, if license fees are required for critical features such as authenticated access to the DB.
Iām glad to see how carefully Baserow is considering implementing fees, and I hope youāre able to find a solution which enables revenue to keep the company growing, and also satisfies a thriving open source community.
Thank you for your feedback, Nick. Iāve shared it with the team. Once we have confirmed pricing, weāll provide a detailed explanation of how it will work and when it will be implemented.
Hey @redndahead, @ddsgad and @MIB, good news! We decided to charge per active application user per month.
An active application user is a user with an account who authenticated at least once in the last 30 days.
However, just a note: in the first version, youāll have to buy what you think you need each month, but at some point weāll have consumption-based billing.
Itās difficult to change the pricing model for the SaaS, but if you self-host your own instance, the pricing is per instance. Can you consider self-hosting in your case?
@DataGecko, this is not true anymore as we count users that authenticated once during the last 30 days.
Unless I misread it, I think the price is per user account and not per active user there.
Yes, the fees also apply to the self-hosted version. But as now itās related to the number of application users that are actually using the application, it should better fit small entities.
In a nutshell:
- Weāll charge based on active application users per workspace (or per instance for self-hosters)
- An active application user has authenticated at least once to a specific application in the last 30 days
- Same user across multiple applications = counted once per application
- When limit is exceeded, new authentications are rejected (with prior notification)
- Free plan: 5 active users. Paid plans include specific quotas (to be defined). Buy extra seats for more.
- Extra seats: $4/active user/month
- Initially you need to buy what you need, later weāll add consumption-based billing
- Visitors without accounts are free
- Some features are available only if you subscribe to an Advanced/Enterprise plan
- User count in sources panel is incorrect and needs fixing
1 Like
Thanks jrmi. For the tutorial applications Iāve already created with the existing prototype open-source builder, will billing now begin for users whoāve created accounts in those demo tutorial applications? Also, is there a user interface or notification of any sort in the open source version which shows what will be charged for user accounts in that open source instance? From what I understand, going forward, there wonāt be any way to create tutorial applications which involve auth, without being charged for any users who try the application. Is that correct? I just want to ensure that the tutorials Iāve published so far donāt lead to an unexpected pile of charges - those tutorials are currently online and could potentially be accessed by any number of visitors.
The billing wonāt start immediately, as we changed the model we have to make some changes in the code too. Weāll make a announcement when we start billing.
Weāll show somewhere (TBD) the current count for sure.
As long as you donāt try to authenticate to that tutorial application with more than 5 application user in the same month, nothing is charged. The free plan include 5 free active application users and you donāt have to be on a specific plan to create an application using authentication. The authentication feature by itself is free, only the active application users are paid.
if you try to authenticate with more than 5 users they will just be refused until you buy more seats. No automatic billing or something.
If you share a pair of credential with your visitors they can all try the application with the same account and it will be part of the free plan.
1 Like
great, thank you!
Hello,
So, if I understood correctly the subject, there will be no notion as previously shown here :
In my usecase, user identification only determines which panel can be seen. They will make no updates in the database. How will I be billed?
Regards,
Thierry
Hello @Thierry, the screenshot you shared shows the role-based user control in the Database Builder. This feature will remain as is.