I have a workflow series, it has 3 actions, all 3 are to create a new thing, all 3 add no values to any fields, it is just create the new thing.
Consistently the first two in the series are getting charged 0.62 WUs, as expected, while the third is always 2.12 WUs, more than 3X what it should be…and this is consistent across all tests, everytime it is the same result.
What makes this maddening, is that Bubble doesn’t provide us the granular details of WUs except for current day and previous day, so it is impossible to showcase the true cost of Bubble overcharging.
There are SO MANY BUGS affecting WUs!
The problem too is that this Bug seems to be caused by Conditionals placed onto a workflow trigger or workflow action in an attempt to secure the workflow. Using the condition “Current User is Logged In” and place it onto the event trigger or place it onto the 3 individual Create New Things actions, and the results are the same, you get charged 0.62 for first two and the third is 2.12…CRAZINESS
I agree the WUs is smoke and mirrors and likely not correct and it’s impossible/frustrating to fact check it with the current reporting systems.
I’m doubtful that bubble will change it however since it’s now been well over a year into this new pricing method and very little has changed despite all the kickback and cancelled/annoyed users.
I figure we just have to accept bubble for it’s shortcomings.
Unfortunately, we now need to be more vigilant in reporting bugs as they affect our wallet.
From WU charts
It’s just a matter of testing what we build. I now, not only have to test something works on the logic I use, I have to test on the WU implications and try all 17 different ways to get the same end result to see which is optimal in regards to WU consumption. This obviously takes hours, but uncovers some really crazy Bugs in WUs.
I did 24 tests against 4 different conditionals with variations of where the conditional is placed, either on trigger event, or on workflow action…then each test had the different setups of either logged in/out and is of a certain type of user.
The results were such that only one condition had the expected results in regards to WUs but didn’t work in respect to expected behaviors, but as this post is about WUs, the results were shocking for WUs…I recorded my audio reactions to the results and a recurring theme was I often muttered ‘made up numbers, like a random number generator’.
this is a formatted list of some of my text based remarks…
Inconsistent Data Requests:
Variable number of individual data requests across similar tests (e.g., 3, 4, or 5 requests) despite identical conditions.
Unexpected increase in data requests when conditions are placed on actions versus event triggers.
Variable Work Unit (WU) Costs:
Creating a “Broker” consistently incurs higher WU costs (2.12 WU) compared to other “create new thing” actions (0.62 WU).
Discrepancies in WU charges for similar actions, such as “create a new blog post” costing 1.43 WU versus expected totals.
Unexpected Conditional Evaluation Charges:
Some tests show unexpected charges for condition evaluations (e.g., 0.32 WU) while identical conditions in other tests do not incur these charges.
Inconsistent application of conditional evaluation charges, leading to confusion over when and why they are applied.
Search Charge Anomalies:
Expected search charges (e.g., 0.3 WU) were missing in certain tests, especially when users were not logged in.
Conditions requiring searches do not consistently trigger the expected data fetch charges.
Workflow vs. Data Fetching Charges:
Charges are sometimes labeled as “workflow” instead of specific actions like data fetching or conditional evaluations, causing ambiguity.
Inconsistent labeling leads to difficulty in tracking and understanding charge sources.
Ghost Bar Scenarios:
Certain actions (e.g., at timestamps 1:54, 1:56, 4:52) show no associated charges, indicating that conditions or searches may not have been performed.
Differences Based on User Authentication:
Logged-out users trigger different charge patterns, such as workflow charges combined with individual data request charges, compared to logged-in users.
Authentication status affects how conditions and actions are evaluated and billed.
Charge Calculation Discrepancies:
Total WU charges for actions (e.g., 1.12 WU for create) do not align with expected sums based on individual component charges (e.g., 0.62 WU for create + 0.3 WU for search = 0.92 WU).
Inconsistent charge totals across similar actions make it difficult to predict billing accurately.
Inconsistent Labeling of Charges:
Charges related to conditional evaluations and data fetching are labeled inconsistently, sometimes under “workflow” instead of their specific action types.
This inconsistency complicates the identification and understanding of charge sources.
Conditions on Event Triggers:
Placing conditions on event triggers results in different and often unexpected behavior compared to placing conditions directly on actions.
Server-side evaluations on event triggers do not consistently align with expected charge patterns.
Workflow Charge Variations Across Runs:
Subsequent runs of similar workflows exhibit different charge applications, such as the first run having only a workflow charge and the second run adding data request charges.
Variability between workflow executions complicates charge predictability and consistency.
I created these tests as I put up a post on conditions and security and some other users were adamant there are no issues and everything works as expected. Unfortunately, testing yields pretty much exactly the opposite.
I ran similar tests about 2 months ago and found similar issues.
WUs are very inconsistent
The charts and reporting and very laggy, inconsistent and extremely hard to debug on a granular level.
I basically setup a new page for each test and then made sure to only load it once per test so I could see it accurately in the reports (can filter by page).
This was tedious - I setup over 60 pages for tests, but it was the only way I could isolate the tests reliably.
What I found was that tests would return varying results for the same requests. I made sure to also standardize the data by putting exactly 10k characters per record (since record weight also has a cost in some requests).
I raised many of the issues with bubble support to which nothing happened. So I just chalked it up to having to put up with WU overcharging and “smoke and mirrors” as the new pricing model.
It’s been well over a year now with little changed on WUs and their pricing despite all the complaints. I don’t expect anything to change going forward.
There are many issues with the bubble platform regarding conditions, security, WUs, editor bugs etc - just the price to pay to use bubble I guess.
I was holding off sharing the videos to give support some time to watch them, but the watch logs show they have not watched them since I sent them on Jan 15, so I guess it doesn’t matter for me to gauge whether or not support is attempting to have engineering look into and resolve these bugs. The reason I say that is because the original bug report I submitted was from December 1, 2024 and still no resolution or update on any attempts to fix or uncoverings of issues and these videos were provided as additional support to help make their jobs just a little bit easier.
No, I can do 1000 time better and share the videos and results of most of the tests. I failed to get all as I was unaware of Bubble practice of making granular hourly details available only for 48 hours.
BTW, this is from the related post Hard Fact - Securing your App with Server Side Conditionals Costs 0.02 WUs where others seemed adamant I was unaware of how things should work and that there are no issues. FYI, most of the manual descriptions of ensuring conditions are run server side are not really accurate OR WUs and related Bugs are causing them to not behave as they should.
Hopefully others will start to perform tests to ensure Bubble manages the platform properly. I’ve personally, and I know most other professional developers have as well, put far too much energy and time into building careers/businesses around Bubble for Bugs in WUs to be the issue that spelled its demise.
You can cross reference any data from the spreadsheet shared in earlier post of there is a particular set of workflow and each action and the relevant logs. BTW, all are the same setup though, only the conditions and placement changed.
In order to reproduce the test so that other developers can test, to ensure that these bugs are taken care of, just check out the spreadsheet, it is all pretty clearly laid out on how to structure. In my tests in my app I just did a simple 1. Create a New thing of Type A, 2. Create a New Thing of Type B, 3. Create a New Thing of Type C…all New Things were created with zero fields being populated.
With the slightest bit of effort, we as professional developers with large stakes in Bubble success, we can likely help Bubble to correct the ship and get it steered back in the right direction as it seems like Bubble itself is not interested and are comfortable with just drifting out at sea rudderless.
Although I understand your and @Jici standpoint around WU not being correct and the need to fix it, and although I agree in an a ideal world it should be, I would like to add the following.
Why would Bubble fix it? The bugs are in their favor so they make more money. It has been like this for years so it is clear that other things like AI, mobile apps etc get the focus. And when those are done it will be something else.
Many valuable Bubble experts are complaining about it with good reason but I think the value you all bring to the table can be much higher in other areas.
And let’s be honest, bubble is in many ways 1000x more expensive than competitors in some area’s because of the WU’s. So what difference does 10-20 or even 30% more expensive because of bugs make?
The Bubble community has already lost rockstars because of the Bubble strategy, so let’s help existing bubblers to help them. Be it to improve their app or migrate elsewhere.
Why in the world would I help people migrate elsewhere to further the speed at which Bubble will lose customers and market share? I’m a professional Bubble Developer, so trying to make the platform less viable is not a thing I’m
interested in, and in fact it is just the opposite. My post here is to help Bubble fix the issues so as to make sure there is not a need to migrate elsewhere. The help for others I am providing with this post is to help Bubble understand the importance of fixing these types of issues.
Because I’d be homeless if I took a 30% decrease in my income…30% of 10 is 3, and 3 is a small number, but 30% of 1,000,000 is 300,000, not a small number, so 30% as a percentage is a large percentage, not small.
Okay, so I guess math helps explain that…1000x 10 is 10,000 and 1000x20 is 20,000 so the difference is that bubble is not just 1000x more expensive it is 10,000 or 20,000 x more expensive…that would be the type of difference 10-20 makes.
Because…loss of early adopters is a terrible. And as I’m a bit frustrated with the response being basically “Forget about it and move on”, I’ll let ChatGPT explain it for me.
If a company with a well-known community strength loses its early adopters and community champions, several key impacts could occur:
Loss of Advocacy and Trust: Early adopters and community champions often serve as brand advocates. Their departure could lead to a decrease in trust and credibility among the wider community and potential customers, as these individuals are often seen as authentic voices that new customers look to when assessing a brand.
Diminished Brand Loyalty: These core members typically foster loyalty and enthusiasm around the brand. Their absence could lead to a weakening of community ties and a reduction in brand loyalty, which can be critical for long-term success, especially in competitive markets.
Reduced Engagement: Community champions and early adopters are usually highly engaged, contributing to discussions, generating content, and participating in events. Losing these active members might result in lower overall engagement within the community, affecting the vibrancy and liveliness that attract new members.
Influence on Product Development: Often, early adopters play a crucial role in product feedback and development. They provide insights that are vital for iterative improvements. Without their input, the company might struggle to innovate effectively or meet the community’s evolving needs.
Impact on New User Acquisition: New users often join a community based on its reputation and the activity level of its members. If the community appears less active or less welcoming due to the departure of key members, it may deter potential new users.
Challenge in Sustaining Culture: Early adopters and champions are typically integral to the development and maintenance of a company’s culture, especially in community-centric businesses. Their loss can lead to a shift in community culture, potentially alienating remaining members.
Strategic Response: To mitigate these risks, companies should focus on:
Building and nurturing relationships with remaining members to ensure they feel valued and engaged.
Recruiting new champions from within the community who can take up the mantle.
Maintaining open lines of communication to understand the reasons behind the departure of key members and address any underlying issues.
Encouraging a culture of inclusion to help new members become active participants and potential future champions.
In conclusion, the departure of early adopters and community champions can significantly impact a company, particularly one that relies heavily on its community. Proactive management and fostering new community leaders are essential to sustaining the health and success of the community.
@boston85719 Simply search your name on the forum and you will find lots of posts full of value.
About helping, I believe what comes around goes around. Why make it harder for people wanting to move. Worst thing you can do is keep not happy people locked in. Those people will tell it to every single person on the planet if they could. But I also get your reasoning. Just pick what works for you.
About the math I think you are missing the point. But never mind. We can agree to disagree. I believe that a 20% additional WU cost because of the bugs would not matter much. If it would, the customer would leave anyway. Bubble is not the platform in that case.
I have spoken a lot about why I think the pricing structure is really bad. Did that years ago in detail. And there is no explanation needed as to why having bugs especially around pricing hurts the brand and platform. But again, this is discussed for years now without any changes. Not even active participation from Bubble itself.
So my advice, just take the platform and the company as it is.
I agree - I just chalk it up to “the cost of doing business with bubble”
But I will add that as soon as an honest and on par competitor comes into the market I will be changing and a lot of other bubble devs will be too - many already have found other solutions and continue to move off of bubble.
Bubble is a great platform in many ways but unless they course correct they will be thrown to the dogs by their users as soon as competitors inevitably solve the problems bubble seems not to care about.
It’s been downhill for a few years now so I expect there will be a few competitors taking notice and working hard to capture bubbles userbase. I haven’t seen any on par with bubble yet… but it’s only a matter of time.
And it is quotes like these that incentivize Bubble to not fix anything.
Some of which are me complaining about certain things in Bubble, whether lack of features, lack of communication or how things are done that have resulted in getting things changed. Two of them around support and how the communication is done, one from around 5 years ago and one this past 12 months.
Who in the world said anything about making it harder for people wanting to move to move? My point I thought was clear, it is about making Bubble something people will not want to move on from.
The case in which a business owner would like to not get overcharged? I suppose I have a different perspective on money than others, as for me, I don’t want to have to give away any more of my money to any profit seeking enterprise for use of their services than I have to based on their pricing plans. Bugs are not part of the pricing plan.
When Bubble first announced WUs there was an uproar, and that was the first time that pricing was being discussed in a negative way. The main reason for the uproar, was that pricing was astronomically higher than it should be. Bubble heard, listened, and adjusted the pricing on some metrics by 10 fold. Now, since WU metrics have been forced onto all as the 18 month grace period has lapsed, there is much more discussion around it because many more people are having to contend with it.
Change is a slow process. I’m not looking for any overnight fix here.
This is why I, as somebody who came into Bubble at a time that I consider myself an early adopter, am trying to help Bubble course correct by highlighting these issues.
I wouldn’t characterize it as downhill…its been some very rough seas with some big storms that have come and gone. Bubble still no doubt is a leader in it’s industry and personally, I don’t see any other company taking that away from them. With all the large projects they are attempting simultaneously, I think they are just having a hard time staying on course.
