Hello Olgatrykush,
I understood that. My question was: Will there be any consideration like this one about application user ?
You have two kind of application users:
- Application users that donât have account. These users arenât counted but they canât authenticate.
- Active application users that have an account and authenticated at least once during the month.
For now, we have no consideration about the role of these application users and if they can update data or not so youâll be billed the same as soon as they have an account and they authenticate.
Ok, got it, thank you jrmi.
FYI, Softr, which is the competitor of the apps side of Baserow include a number of âfreeâ users in the fixed base monthly price. Then you pay for additional users.
They are a bit farer in terms of functionalities with the interface than you are (graphics, timelineâŚ).
But from my stand point, your bigger advantage is in the fact your apps builder is part of the DB and we have no API type of interface to build and the data remain in your servers while provided at the presentation layer. So we have less potential security breach with you.
Yeah weâll also have active users included with the monthly fee depending on the licence you are on.
Another difference is that we count ACTIVE users and not user accounts. You can have 1000 user accounts but only 10 active users this month in which case you pay only for these 10 users. Depending on your activity it can make a difference.
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
I appreciate that the paid plans include a set number of application users. That said, will there be a way to disable consumption-based billing? Specifically, once the user quota is reached, can we prevent any new accounts from being created?
I ask because Iâm just an individual building a project for fun on a minimum wage paycheckânot a company with a corporate safety net. The last thing I want is to wake up one morning and find myself financially haunted with debt I could never recover from because 1,000 bots/trolls decided to register overnight.
This pricing model would be a definite no-go for us to continue with Baserow, and we would need to evaluate alternatives.
We are already using Baserow in production. In our business model, we serve customers who in turn serve their own customers. These end customers need to log in once or twice per month (for example, to upload documents). One of our customers has 120 end users who log in monthly for this purpose. Under the proposed pricing structure at $4/active user/month, this would cost nearly $500 per month for this single customer alone. We donât even charge them that amount for our entire service.
I understand that paid plans will include a certain quota of active users, but could you clarify how many free active users will be included in each tier? I have a feeling this wonât make much difference for our use case, but Iâd like to understand the full picture.
Given that weâre already invested in Baserow, discovering this pricing change means we now need to re-evaluate our entire setup and potentially start the migration process to another tool. Can you confirm this is the definitive direction for pricing? If so, we need to pause any further development in Baserow and begin exploring alternatives immediately.
Hello @Thijs,
I think the free plan will include ~5 active users. @jrmi please correct me here if Iâm wrong.
Can you confirm this is the definitive direction for pricing?
I think so â that was the last model discussed for the Application Builder. There might still be some changes, but thatâs the current direction.
Weâre also not sure yet when the pricing will be implemented, and weâre not going to start charging active users immediately. Once the pricing is in place, weâll give users a few months to adjust and decide how theyâd like to proceed.
I confirm the direction is still the same.
We donât have the exact figures yet but I can confirm it wonât have a real impact for your use case.
We are concsious this pricing doesnât fit all business models and if your user value is less than 4$ per month then yes it doesnât work.
If the users only upload documents from time to time, have you considered to not create accounts for these users? Baserow as an action to send an email, may be you can generate temporary url to let them upload their files after submiting the address or something like that?
Hi Jrmi and Olga, thanks for the explanation.
How would this exactly work? We need to make sure that these people are identified (within the context of their company AND beloning to our clients). How do we make sure the uploaded file is linked to this specific person/company without them logging in? And also in a safe way?
One way to achieve that could be to keep a list of allowed emails in a table and when a user wants to post something he enters his email (only) on a page, then click a button that triggers an action.
This action could be done with an external automation tool or if you wait for Baserow 2.0 youâll be able to use the internal automation tool.
The action first generates an UUID and adds it to the row of the corresponding email. Then it sends an email to the user only if the address is found in the table. The content of the email is a link to a page with the UUID as path param. When the page opens the user can upload his files and with the UUID you know which user has actually uploaded the file.
The UUID could have a TTL of 10 min to avoid reusing the same UUID later and secure it. It could also be one time use if you delete the UUID as soon as itâs used.
Does it makes sense?