@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.