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.