I don’t see how the typical no coder shall be able to design for efficiency to avoid high use of wtf This should be done out of the box.
Otherwise they need a tech founder or dev
5 Likes
Hey Bubble team: I’m an entrepreneur, done and exited several startups, and I really appreciate and empathize what you are going through.
That said, I think you underestimate your customers and the market. This is the most bizarre, a**-backward way of measuring workload done by modern systems.
Either you don’t have a real infra person on your team (then you should get one ASAP), or this is a strange strategic choice.
Either option is very troubling.
13 Likes
Providing a pricing simulation is a great initiative. The new pricing which offers advantages such as getting rid of speed limitations and I’m sure that many will happily do the change.
However, many of use have developed business models on Bubble that need high WU. The WU calculation update is a step in the right direction, but still kills 90% of successful Bubble apps.
Why force us to update to the new pricing and not give us the option to keep the legacy pricing? It is a common practice and it is the option that you have chosen so far. It’s the best way to convert early adopters into strong brand advocates!
I am pretty sure that this is the only way to regain the trust, growth and prosperity that Bubble deserves.
5 Likes
I am not qualified to comment on this one way or the other, but as it seems to challenge the foundations of the new pricing, it would be reassuring to read a direct response to this specific challenge @josh @emmanuel
That said, I just want to add that it’s great to see Bubble acting on community feedback to this extent.
4 Likes
I’m just spitballing here, but is there any way within Bubble that some type of real time estimator, like a meter might exist so that as you are building, you could click on said meter in the same way you would click preview? Heck, forget about clicking it; as you add a feature or workflow, some type of real time estimate update is provided? I mean, it kills me to think of this as viable (WU’s), but at least for the non-technical folks who aren’t interested in getting a real time MBA on WU’s, some type of visual indicator would be nice, not some technical table with technicalities that would make OJ’s lawyers blush.
Still though, said it before, I want Bubble.io to thrive. But, if the VC’s are getting a little antsy, have them pipe down and keep with your vision.
1 Like
I nearly threw up my matcha latte when I read they will charge based on “statistical regression”.
5 Likes
Thanks for the update! Looking forward to the improvements.
Next to that, i am still missing a very important point: DATA BACKUP & RETENTION. The support desk told me this will be updated to 2, 14 or 20 days according to the plan.
Not being able to have back-ups for at least 1 month is something i do not dare to sell to professional businesses…
2 Likes
If I’m reading this correctly… Bubble could have spent 7 more days optimizing weights to give a 30-90% decrease in cost? Why wasn’t this done first?? By optimizing these things upfront, many of your users would not have experienced the same sticker shock. Now knowing that it only took 7 days of work for such significant improvements, I really start to question the motives for Bubble, because it seems by optimizing your platform, you work against the financial stakeholders.
I appreciate the transparency given on WU and 100% agree on the concept of usage-based pricing, but Bubble’s reputation could have been spared. Still feeling heartbroken…
11 Likes
Hello @Bubble. I’ve always said: give more.
-
If possible, don’t count WUs below the 5% capacity threshold. What a headache to have to count all our workloads when the application hardly moves. I think the minimum payment per month should be sufficient.
-
Establish an easy refund from WU in case of errors (loop) or attacks, at least 3 times a month without the need for customer service (duration 1 hour). Many profitability scenarios are currently broken with this new pricing scheme.
-
As mentioned above in the forum, do not force to change category (Legacy to new WU pricing) for at least 3 years. Especially give us a period of one week to return to the Legacy plan, if it does not go well.
-
Give the chance to those who consume high rates of WU, to be able to put together, in order to have a dedicated server at a price advantage.
-
Another downward revision of the WU percentage (imo).
28 Likes
Not going to lie, this wasn’t quite the response I was hoping for, maybe my expectations were too high for saving grace, probably need to sleep on it to be fair. But as many others have mentioned, only time will tell how these WU adjustments affect apps in certain scenarios. It’s still all confusing to make heads and tails of what could cost what and where the most streamlined wins are to optimize WU expenditure but guess it will be another learning requirement/workaround. The table here certainly does not make that job much easier, but appreciate its visibility.
I am concerned about the full transparency regarding the activity costing for WU. Apologies if this has been covered, but is there anything stopping Bubble from slowly increasing these figures over time unknowingly to users? I have no issue of course for it to be tweaked and the cost per WU decreases, but I mean ideally having it published somewhere in real-time as a source of truth would be the very least and even having a changelog if things do pivot lower. But if things go on the up, this should be public knowledge and clearly announced as to what increases are, why and when they take effect. Even a small increase nudge could have a profound affect on some customers.
I still believe that there are still a handful of features and tools missing from the announcement of charging for WU, that will make life harder until the day they are eventually rolled out, but maybe once the dust settles, new plans come in, Bubble can roll out features are a much snapper pace and make some headway on this front, as its more pressing than ever.
It’s nice to see are a quick roadmap for this, even as brief as it is and to address issues that should not be there in the first place e.g. 404 WU consumption and WU usage on unpublished versions.
I don’t see why is it fair for customers to have to wait for Bubble to optimize its own code while prices for WU’s remain high - not sure on the logic for this one.
24 Likes
Server side plugin actions have always reported memory size and time execution in the logs.
Use one and see the logs, you can do the math directly.
And server side plugin actions are yes-code, there is nothing to do with the editor, you need to adapt the logic to bubble’s system, there is no local development and it takes actually more time to code than in a normal yes-code project because of the slower feedback loop and the system quirks.
The only value added here is to run them on the same infra of the rest of your app, which is not a good enough reason now.
2 Likes
The pricing update is an improvement. But we need to wait a few days for other to provide the actual numbers.
In any case, because the pricing is based on WU and not standard metric, the cost is unpredictable. Most nocode tools do not have this problem at this time. Certain apps will be more suitable with Bubble than others. The apps with fixed users and normal usages in general are better, e.g. internal tools. The apps that charge by usages with very low or no free plan are also OK, e.g. saas. Community is bad. Apps with any usage without revenue or budget is bad.
Optimization is something I never really need to worry about with php/laravel/react apps for the last 15 years until the some tables in DB get too large (on a $130/month dedicated hosting plan). I have only needed to optimized 1 front end process design and a few DB queries. It amazes me that I need to learn more about optimization in Bubble than traditional coding to control cost and still worry about site usage and traffic…
Now that I’ve had some time to fully digest this, I’m going to clear my head.
Having to write a novel just to explain pricing and a chart displaying how Workflow Units are consumed depending on what action is taking place only highlights the inherent flaws it presents as the basis for a pricing model. We’re talking about pricing here, not sending a rocket to Mars.
The very notion that you have to create an entirely different unit of measurement from industry standards by well established companies that provide ancillary services similar to Bubble makes next to no sense. Even if this method more accurately scopes the amount of computational requirements vs. cost, it’s fundamentally flawed in its approach to establishing trust between Bubble and its users (among other flaws, such as having to reach out if a mistake causing a massive spike in WUs was made…like an infinite loop).
To emphasize this with an analogy, you’re asking us to trust you at the wheel while our foot is on the gas, navigating into oncoming traffic on a busy highway. Unless we’re constantly paying attention and making the necessary adjustments, it’s likely not going to end well.
From Bubble’s perspective, imagine a non-technical founder coming to Bubble for the first time wanting to build an app without code. They go to the pricing page and they see this thing called Workflow Units. “What’s that?” they ask, perplexed as to why Bubble’s pricing model is different from competitors they’ve researched. So they check out the relevant source material to determine costs and how it applies to building an app, whose code, lest we forget, is controlled by Bubble’s engineers, only to come to the conclusion that it would potentially be a pain to keep track of and constantly worry about. How off-putting is that? Nobody should have to look at a spreadsheet to figure out if their app idea is even financially feasible.
Now, I don’t personally believe charging for features is befitting of a platform like this. Charging for usage does make more sense. Using a new metric that deviates from industry norms, does not. I’d rather have my app’s performance throttled than concern myself with “Workflow Units,” something that is going to have to constantly be monitored. I shudder to think what would happen if one of our apps experienced a massive jump in user count/activity.
With all that being said, if converting non-paying customers is an issue, there are certainly better ways to go about this. Education, longer trial incentives, even raising prices in conjunction with familiar usage metrics. Either way, we need predictability, as many have already said. WUs are too unpredictable, especially since what goes on behind the scenes is out of our hands.
I understand this change will probably just be implemented anyway. Regardless, I had to empty my thoughts out in the open. This platform has done a lot for me. To see it turned on its head is something I had hoped to never see. We’ll see what happens with the WU cost changes, but I think I know how this story ends based on my personal experience in multiple software industries.
23 Likes
Which option would you prefer:
a) latest revised pricing
b) 2 * price 1 week ago
- A
- B
0 voters
@josh please add ability to searches to only return a set of fields designated. I’d like to be able to say please don’t return Modified Date or Created Date or any custom field I may have on the data type to be retrieved.
This will help optimize our apps, save our costs and save Bubble resources.
Please add functionality for slugs to be recognized in the get data from Url extraction expression. This will help migrate searches into single item returns more easily than the :first item operator, which I’m unsure of if that operator in effect results in a single item return or a full search.
Please put a feature that allows us to aggregate our users consumption of WFUs so that we have an ability to create pricing structures for our apps that match the pricing structure of Bubbles service.
Please extend the time before an api call times out up from the current 30 seconds.
Please add features to recursive backend workflows that could enable conditionals to shut down infinite loops or other WFU consuming developer mistakes. Someway to count the recursive runs and stop after X number.
Please extend functionalities for list manipulation and storage through custom states.
…I’m sure the community will be adding a lot more requests over coming months. I’ll probably have lots after getting to play around.
26 Likes
Even 3 times and no free tier. Not a problem
Just as when trying to find product market fit, don’t fall in love with the product you have in mind.
Don’t fall in love with your pricing system, fall in love with what the market accepts. The market is clearly rejecting this.
Finding pricing market fit is not easy. Capacity seemed like something the market accepted, maybe it just needs some improvements for auto scaling, performance and charging more in reasonable terms.
Maybe sticking to capacity plans and just charging for the minutes where the app went above 100% capacity, instead of killing workflows at that point.
My best tip to find your pricing market fit for you, since your audience is mainly non technical, would be SIMPLIFY. It doesn’t matter how hard is to find a simple solution that would still be financially viable for Bubble, its what the market requieres and you will be able to find it more easily when you start using simple pricing systems as benchmark, instead of complex ones.
16 Likes
and the funny rhing is that the gb/s usage metric is already reported by server logs, we all can calculate the price markup. And it’s 100% yes-code, no value added by bubble.
One more reason to not update them for the upcoming async api breaking change.
1 Like
Where Do We Go From Here?
- In the short-term, as in immediately, the weights on the “Workflow Units” should be revised to be calculated from the geometric mean of the resource utilization per operation instead of the arithmetic mean. The arithmetic mean grossly overestimates the impact of a single operation, by underestimating the frequency of operations with higher resource utilization, and thus penalizes any developer who’s application runs anything more than sparsely at all.
- In the long-term Bubble needs to move to a containerized architecture, where each application runs in its own container image (Docker, K8, etc…). Bubble has the chance to become the leading visual development environment of containers if they know what they are doing. This would have many advantages, including being able to precisely monitor resource consumption by individual applications. When @josh said they could not identify individual database transactions with individual applications that confirmed my worst suspicions about their underlying architecture: Namely that they are using the “Great big swamp” model. The outages last fall due to failures in the database sharding hinted at this. The logic behind this poorly executed price model merely confirms my fears.
46 Likes
Hire this guy with our WU fees
22 Likes