Tem varias formas de cobrar , agora limitar o db ai nao da
As many others said: pay per row is not an optionā¦
I would go further, pay per unique user is also not an option.
I have a restaurant menu application, which restaurants publish on their websites and their customers scan a QR code to see the menu. There are some restaurants which around 1000 customers a day. So every customer would be a user even if itās just for 30 seconds. Imagine 500 restaurants with 100 guests each restaurant per day makes 50.000 unique users.
With this pricing itās not possible to make this profitable.
Really hoping for a different approach.
1 Like
Bad decision, please revisit. Otherwise give sufficient time for us to move on to other platforms.
https://backendless.com/ is offering better experience for same price while you are limiting total 5000 rows? Who give you this math? This is a nightmare and 2 years of work is now getting wasted. This is too badā¦
upvote 
Really sorry to hear that!!
1 Like
Thank you for writing a response that, despite your frustration, provides feedback and understanding and ends on a positive note. I appreciate that.
I hope youāll keep this transparent plan for the users who want it. Iāve been conflicted about using bubble vs other more transparent hands-on development services, but with this new model that indecision would be gone.
What is the problem to pay for bandwith and workload on the server?
We pay for the hosting of our saas and that everything is online - that bubble has a great software we can build our tools is just the reason why we choose you as provider. (Same like when you build a website or when you choose a hosting provider).
Of course we use bubble cause we love the software - but this is just the start.
I would do a base flat for capacity and bandwith (so even if you use different data storage systems - users have a workaround for storage limit right now - i pay for what the user does with my app.)
Btw: you can also let us pay per usage of ram ā this could be possible about the calculation how much āTimeā the server needs for the work he does for us - so the cluster has no capacity limit - i just pay for how long it took to calculate stuffā¦ Online Rendering Clouds use this functionality.
So why should i need a āpredictableā system?
If i rent a server the server has a limit my user can need - if i do not want this i go to amazon with my app - cause i care more that my app is online - then i do about some extra dollars.
Just show some examples how the usage + workflows running = time you pay on server.
3 Likes
I would recommend a limit on workflow (+ background API workflows) steps run and records loaded from the database. Each application uses workflow steps and loads records from the database. So you could limit that. Also its something very measurable.
Free - 100 workflow (steps) and 100 records loaded a day
Hobby - $6 /month - 1k workflow (steps) and 1k records loaded a day
Personal - $29/month - 2k workflow (steps) and 2k records loaded a day
Premium - $60/month - 5k workflow (steps) and 5k records loaded a day
Professional - $129/month - 10k workflow (steps) and 10k records loaded a day
Production - $320/month - 25k workflow (steps) and 25k records loaded a day
2 Likes
Could you define records loaded? Seems like that could be low.
Donāt agree with measuring workflows for pricing option as we have had to use multiple workflows to avoid Bubble inefficiencies.
Moreover, then users will also consider Make or Integromat.
1 Like
This reply gives me hope.
Good: The best part of the whole change is being able to have overages which let your app keep running.
Bad: The record limit would kill my app due to launch this week (which I am now delaying).
ā¦
@emmanuel , bubble serves so many diverse applications that I think you have to find a way to focus on charging for what costs you guys more resources, and let the chips fall where they may.
How much do you charge for a 10-cent pen used in a classroom vs a 10-cent pen used to sign a peace treaty? Answer: 10-cents
bubble canāt realistically pick-and-choose whose going to have to pay more for the same resource for a simple reason - you are applicable to too many areas, too many situations. In order to stick to your principles youāre going to have to accept the following:
Someone who makes $20,000 making a simple app to solve a companyās problem - you arenāt going to be able to get to charge more than you would to someone who charged $200 to a school to do the same simple solution.
You are making one of the coolest "pencilsā of our age. Consultants can charge on value provided. I donāt think that you can and also stick to your vision.
Solution: Charge in such a way that it is fair to bubble. Make it as transparent as possible. (A tool to estimate the server capacity needed for an given database design sounds FANTASTIC!)
Price Structure Suggestion:
(If you can) Consider structuring like those ideas for a modular cell phone.
- Charge a basic, core price.
- Offer āmodulesā that extend your
- ācapacity,ā
- ādatabase storage,ā or
- your user traffic.
Then you (bubble) donāt have to guess who to make pay for the app.
Maybe: Make it optional to unlock overages - with clear grace periods and prices for overages exceeding a certain amount for a certain time - then auto-sign them up for an appropriate module that covers their new needs. Make all of this clear up-front and even only do it if people opt-in, and if they opt-out and their service gets interrupted because of a spike in success, they will know you did everything you could and youāll be there for them next time.
Together we can all expect more of each other. And bubble developers should be able to Step-Up and understand what your pricing needs are if you will make them well-justified and transparent - EVEN if we have to use several tools to estimate our needs.
Please do your utmost to link bubbleās costs to the resources used. And any problems arising from poor choices made by developers - maybe be transparent about it and hold us accountable to program more efficiently or pay moreā¦?
I love bubble and I want to keep loving it.
2 Likes
Lets make it really short and simple - why donāt you guys take the costs for the AWS and multiply it by 3 or 5 and let the user pay this. (Bubble is working with aws)
Pretty fair cause he pays for what he uses
You are on the save site cause user pays what he needs
Clean and Simple Pricing
Works for amazon - why not for you guys?
2 Likes
Yeah, maybe all the services Bubble uses to make our apps functional multipled by 2 or so?
1 Like
It looks like they honestly aimed wrong. But either they take back this change or I agree with you.
Well thereās something to that idea. At least it would be predictable.
But it also incentivizes users to minimize steps, which could get weirdā¦?
This image is the most concerning part of @emmanuelās post.
It means we pay $20/mo for every 5,000 things in a databse.
Iām surprised more people arenāt commenting on overage costs. Itās a good indicator of bubbleās plan to bill us.
Itās critical for bubble to provide feedback on this item.
3 Likes
@emmanuel Iām done griping, here is my proposed solution(s).
There is a responsibility of the Bubble user to monitor their app to ensure that their app remains active when traffic/usage spikes, and adjust their plan accordingly. The fact that some Bubble users fail to do this, is not a problem that you guys need to solve by changing the pricing model.
Making a change like this is actually just punishing users like myself, that monitor our apps diligently and properly forecast growth, to solve a problem for your users that fail to do so and are likely not your best users to begin with.
This problem should be approached in other ways. Here are my ideas:
-
Greater education on the importance and responsibility of Bubble users to monitor their apps to avoid downtime. If your userbase knows this is their responsibility, they are less likely to complain later if their app stops functioning due to not paying attention.
-
Algorithm that is able to predict based on past learning when an app is likely to exceed limits in the near future and trigger notifications accordingly.
-
More options (defaulting to enabled) that trigger warning notifications for when apps break 50%, 75%, 90% capacity, etc.
-
Add SMS notifications for when limits are reached or soon to be reached to ensure app owners know when this is happening. Strongly encourage users to add phone numbers and enable this.
-
Launch simple mobile app for monitoring usage of a Bubble app from a mobile device that can send push notifications for reaching certain limits and allow for upgrading plan if needed, without having to get to a desktop browser.
-
Auto-upgrade settings that automatically increase plan capacity level when a current planās capacity level is reached.
-
If it doesnāt already exist, some way to āholdā workflows when appās are over capacity, and rerun them later once upgraded (similar to how Zapier handles this). Donāt know how practical this is, but just another idea.
When it comes to pricing to ensure every user is paying their āfair shareā (including the backend services you mentioned), my thoughts are this:
Bubble is currently viewed as a development tool/platform, and increasingly an alternative to traditional software development. In other words, a commodity, which is not in any way a bad thing. The commoditized positioning make Bubble a real alternative to serious software developers who want to build without code and not have to worry about maintaining a stack.
Adopting a value-based pricing model that attempts to charge users based on the end userās use case and end-value, is going to make Bubble untenable for serious developers. From a financial standpoint, it just doesnāt make sense anymore when, at scale, the cost is 40x what it would be with a regular stack, instead of just being a stable 30%-40% more than a traditional stack like it generally works out to be right now.
If Bubble had had a more value-based pricing model (such as the one proposed) when I was evaluating development options, I would have never gone down the Bubble path, the pricing makes it completely unattractive no matter how easy it is to build on.
You will lose your community of serious builders if you attempt to transition to a value-based pricing model from a cost+ model
You are the AWS of no-code, lean into it and continue to price accordingly, and you will continue to attract serious builders and developers away from traditional development stacks.
If this proposed change is at all related to just needing to increase revenue, then just increase your prices in the current model.
I think I speak for most Bubble users when I say that Bubble is currently pretty affordable. A 10-20% price hike on the existing price model (while not making anyone happy) is way more manageable and palpable then a complete rework of the model that causes users like us to have to pay 3-4x what we were paying, while our actual cost to Bubble to host our app remains virtually identical.
4 Likes
It may be because they are re-considering all together.
I will change my comments. I am extremely disappointed to arrive at this point, with this new pricing that will make it difficult for me to continue the project.
2 Likes