hi all just my two cents whatever its worth as a product manager for 10+ years.
Let’s all hope the workflow units gets brought down to earth. That said, I fundamentally don’t disagree with the objective of the new pricing, they have a tricky situation to align incentives and avoid perverse ones. I think they do have the right to succeed if we succeed, but beyond that they should be incentivized to help us make our apps more complex over time not less so.
The workflow bar over next several years should be set low enough that costs are for all practical purposes fixed or feel fixed for 90% of customers. But beyond that, customers should be encouraged to add workflows and increase usage over time that add value to the app. This also aligns best with what bubble’s goal should be which is to promote its platform as a solution for an app’s entire lifecycle from MVP to enterprise scale.
Users in DB do not always mean sales for a company.
I’m against the idea where owners having to pay for just people signing up. Otherwise owners should require a credit card in the signup (every time I see it a credit card required to sign up I immediately close that site). This would be the same as having an X visits limit/month.
I’m not necessarily against the WU idea, it’s just wrong numbers. With the current pricing, 100M would cost ~9K, which right now cost $500-700
Plans should have at least WU’s x 10
As said multiple times already, a serious company won’t increase their pricing by +50% from day to night, or the way Bubble did. The only reason I could see doing this is to prepare the company to sell it.
Like someone said if +85% of the apps should only see +$50 increase in their pricing (where I really don’t trust these numbers), why don’t just increase the pricing for everyone by 20% 30% 40%?
Why don’t just charge computing costs + 20%, 30%, 40% + fixed fee for using Bubble?
I’d like to see something for individuals, hobbyists, and small organizations with less than X amount of revenue or funds raised in the last 12 months for the free plan then another structure if you make more than that for plus (with extra features for $399, and even more features for pro $2,040 as an example these number are fake but a income structured approach to pay for what you get and everyone wins.
I noticed the free plan doesn’t have the ability to see these metrics so it makes me wonder how those bubble users would know what to expect based on workflow usage prior to upgrading?
It would be impossible for them to design specific things. If they would want to carry with WU as they are, they should make it so advantageous that we wouldn’t have to worry about it. If the free plan started with a 1m WU, maybe, we would’ve said, okay, it’s not much, but still, it’s a good start. They should either think about some other way to monetize better, or increase by order of magnitude the WUs.
I posted about Cloudflare earlier, and by curiosity I checked their pricing (ex. below), when I read it, it’s generous enough that I don’t feel anxious at all.
I agree, but if you I think about it, if you have 10k users and have 0 business you better close shop. Means the business or product not attractive. Unless you are trying to replicate facebook or open free community, that would be a different story😅
I dont think bubble will change how the plans structure (Wu) as they said, i hope bubble 10x the Wu, but we are just brainstorming here.
I would spread users for the plans like this:
Plan 1: 5k user
Plan 2: 15k user
Plan 3: 50k
Plan 4: +100k
I think that would be acceptable. I suggested these metrics because bubble needs at least two metrics for plans. One for infrastructure usage (workflows) and one for scalability(users).
This new pricing plan is extremely unfair, as it offers a meager amount of WU, which is far too small. It’s disheartening to see my trust in this service being called into question yet again, reminiscent of the issue I had with Bubble. Unless there is a change in this policy, I will have no choice but to explore other options, even if it means migrating through code, during the 18 months.
I’m creating a ftp game via bubble. If I end up with 50k users, instead of being proud of myself for creating something great and growing it while maybe getting a few subscribers and transitioning that into $, I’d have to close up shop because I wouldn’t be able to afford it. I wouldn’t be able to afford 100 users at these prices.
I was so exciting to post a showcase of my bubble app because I think it’s truly unique on the site (there really isn’t much for actual, full games on here that I’ve seen) but now I feel like a moron for trying to do something out of the ordinary. There is no feasible way for me to keep my game going with this system.
That is terrible. So sorry you experienced that behaviour. This forum is overwhelming positive so I am sure you know your views are respected and efforts appreciated.
There is a tiny element of bad behaviour on this forum, even from brilliant people who seem to have behavioural issues, and we should call it out when that happens.
Like you, although devo at this fiasco, I truly hope a positive step back will come from Bubble HQ.
In case team at Bubble is still listening, I would chime in with my few cents.
I feel Bubble must have two components of the fee. One should be platform fee which is for the features they are building etc. Other one should be for the usage.
And with so many limitations in Bubble with respect to performance, Bubble should not be adding a lot of margin on “usage and performance” because we are forced to work around Bubble’s limitations. So Bubble ought to fix a good majority of those issues before premium on “performance and usage charges” are brought in
When performance and usage based charges are introduced, have a very clear way for us to estimate and track usages of various actions
And for the usage, it should be a fair premium on the charges borne by Bubble. Say 20% margin?
In case they need to know, here is a list of my thoughts on performance limitations in Bubble.
No good and easy way to work on lists and iterate through lists
No way to have temporary variables in workflows
No way to have return value of workflows
No way to have duplicate elements in lists (so can’t store shopping cart maps in local custom variable, but have to create a data entry for this)
Recursive workflows require long lists to be passed to workflows. Will long lists cause higher workload? No way to prevent this.
No way to take bulk actions on items without running recursive workflows.
Not even possible to bulk import or delete records easily and without consuming workload units
Repeating group data refresh has issues and we have to come up with workarounds of multiple calls to counter it to some extent.
Workflows require lot of searches to be done again and again due to small variations as there is no good way to store and reuse the results or point to a mother search and reuse it partly etc.
No good way to search with OR or such composite conditions
No way to search with a constraint where a list field has an intersection with a given list
No good way to search on second/third level fields (“This data’s field1’s field > 10” kind of thing)
No way to search where a field of data type can be compared to another field of data type or its some computed value
No way to store data-mappings in DB as a field. It is required so often. Because of this new tables need to be created/managed
We need to keep our tables flat instead of normalised as the searches become very extensive/expensive and often impossible. But this means that individual tables become fat. Now since they become fat, even small operations over there simply cause a lot of workload.
There is no way to get only certain fields from search and thereby reduce the workload.
Since there is no way to do a simple forking of if-else logics, we need to keep repeating same condition in multiple actions resulting in more workload being used. And all of those steps consume workloads even if they would actually not get executed at all if it was normal if-else fork.
Since there is no assurance of workflow steps to run in sequence, we have to do a lot of extra processing of “if result of this step was not empty or if it was empty then if that was true…” to make things run in sequence. All this increasing workload.
No easy way to get just the count of a certain search or a particular data type
There is no option to do a “create new or update existing”
There is no way to “Update only changed fields” in case there is an edit form and I want to update the thing changed by user where user has changed only few fields. I still need to write full “make changes to thing…” with all the values in the form
There is no way of doing a “function call”. So if we want to keep our app modular, we need to do a various “call this api which will call another api” etc and that increases the load. We can use custom event if it is all within backend, but from front-end there is no way to call a custom event within backend. So I need to create an API call excessively for sure.
No clean way of assuring atomicity of operations.
By the way, I am on professional plan and consumed 66M workflows last month
This is a pretty good summary @mghatiya of everything I’ve been harping at Bubble about for years and fixing where I can. (But AGAIN, basically Bubble has mispriced all of this shtuff [WUs] in the new model.) Thanks for reminding me about what I think is Clown Town () about Bubble!
One other thing which remains unclear in all this catastrophe of an announcement. How does it work with annual billing. If I do annual billing for the legacy and then 12 months on, my plan renews, do I get dumped off the legacy pricing after 12 months or does my renewal happen again for 12 months or does that renewal after 12 months magically become 6 months. That is all a bit unclear. Just a lack of details all around with this botched announcement and silence.
Oh yeah… also… BWAHAHAHAHAAAA. No fu**ing way Bubble’s coming back with that.
But yeah, surely Bubble knows what my app costs to run in AWS and that would in fact be a completely reasonable uplift (anywhere between 20 and 50 percent over raw AWS cost on dynamic) but since the Mayors of Clown Town came back first with a computation of a 4.7 million percent uplift on SSA executions and an approximately infinite uplift on outbound API calls when all I was excitedly waiting for was a reasonably marked up pricing model that allowed dynamic cap, I’m not holding my breath.
(@mghatiya if you’re not familiar with me, I’m not laughing at you I’m laughing at the Mayors of Clown Town.)
The point is: It’s entirely obvious now that (1) real apps on Bubble are already wildly profitable on a cost-to-execute basis, (2) the free apps tier might be a loss-leader nightmare [but that’s not my problem], and (3) my app never goes over old cap so wtf would a new pricing model impact me at all and (4) if the new model didn’t try to rock the boat I wouldn’t have to do any math and I wouldn’t be rocking the boat either and (5) what a bunch of morons.
) about Bubble!