An Update to Workload, Plus More Transparent Calculations

My understanding is, what you do with it is take it to another visual platform in case your current platform raises your pricing by 40x unexpectedly.

What are known

@melarisover here for that question. :slight_smile:


There are zero visual development platforms that are able to ingest the code from another visual development platform at this time.

1 Like

Front-end variables like the example you gave can be messed up very easly in the client, enabling the attack, and a simple F5 or page refresh will reset that state back to “no”, so in theory i can just script a Page refresh and a button click very easily.
I don’t think that is a viable way to protect agains malicious attacks

On the bright side I have managed to put together some novel mathematical statistics because of this debacle. I’m going to submit an article titled “Poisson Motif and Gamma Syndrome Models” to Biometrika. In the paper I’ll introduce some new methods for statistically fitting correlated count data.


My WU’s for yesterday (the 13th, first day we can see the updated WU calculation) are about 15x less than they have been (High of close to 2 million per day, down to 100k yesterday)

That puts the price for bubble for me at about what I expect to pay for an app like this.


That’s promising.

Can you guys make a better way to call API data to the backend with a loop system this is what is eating up all my WF units. Xano has a pretty fantastic system for doing this. I thought about going that route months ago when I started looking at rebuilding my database but wanted to stay all in Bubble.

1 Like

@josh @emmanuel would you consider regional based pricing to make bubble more affordable for us bubblers in developing countries with bad exchange rates such as South Africa?


Hi @emmanuel & @josh,

I have stayed quiet until now because the initial calculations were off by … a lot.

Even after the new weight reductions an extremely simple freemium consumer app is not going to be viable any longer (as @TipLister showed & @gaurav mentioned the rumors this pricing might only be intended for enterprises).

Under reasonable assumptions for a simple B2C app, Bubble consumes around 100% of total revenue (if the average revenue is $3 per user/month).

If you want to ignore B2C then I believe you want to change the below:

For high usage &/or high complexity apps that are yet to be built this is simply a misleading sales strategy.


I didn’t get what is the timezone that the pie chart refers to.

Is that UTC or my time (UTC+2)?

It is quite weird to get stats from 2:00 (am?) to 2:00 (am?)
It would be useful to get data for an entire day in order ease analisys.

This is helpful @josh . Thank you for answering the Technical section.

Could you / @Emmanuel respond on the below.

This has become crucial since we are forced to decide in the next 15 days itself about which plan (legacy / new) and billing cycle should we lock our apps onto for the next 1+ year. Especially since we don’t have an option to change this after May 1 (from one legacy plan to another legacy).



@josh @emmanuel Thanks for caring for free plan apps,
As I have a bubbler since 2018 i have more than 20 apps, most of them are paid ones but some are in free plan (legacy)
A great move to increase the capacity but if bubble will enable deployment in free plan it would be a plus.

1 Like

Interesting… I run, a youth-led nonprofit and I reduced our WUs from 3M/mo to ~31k/mo, but to be fair a lot of usage came from New Relic pinging uptime

I know I’ve been insistent with this but is with much respect and appreciation, in a constructive way.

Its good that you have designed this pricing system thinking on them, who have teams of people who are technical. But I believe you have not taken enough consideration for your non technical customers who have not even given much feedback here, probably cause they don’t understand the technicalities that are being discussed.

I think you’ve been speaking to too many “top Bubblers”. Not that it is bad, their feedback is very valuable and can help you make this complex pricing more fair, but it would still be too complex and not entirely transparent, and since explaining the WU calculations to make it transparent makes the explanation even more complex, you would be always trading transparency for complexity. Its a loose-loose.

Remember who you are targeting on your ads and media (non technical people), those people are not even in this thread, nor in the previous ones…

Is it because they accepted this pricing model that even multiple top bubblers are suggesting to be changed? Where are they?

I respectfully suggest you to hire and include in your conversations more non techy people that can help you get more real world sensitivity for this kind of decisions.

If your objective is to help us auto scale and at the same time auto scale your own business as your most successful customers grow, you can still do it with a more simple system, like this one or other:

Anyways, thank you for listening and for trying to make this better.

@josh @emmanuel


Rofl :rofl: this surely is the winning post of this thread

I was scratching my head about the odds that you captured the ‘typing…’ when I was doing that for like 100 seconds. Club that with other two and I was amazed…

… until I hovered over the text.

@mac2 I hereby honour you with this :trophy: Surely worth the 15 minute reply wait!


:wave:As a long-time user of Bubble, I was initially excited to see the announcement about their new update to workload and transparent calculations. :abacus:However, after reading through the changes, I am not so happy with the direction Bubble is taking.🥲

:disappointed: Lack of Transparency: -Bubble’s new pricing structure is still confusing :confused:. It’s hard to figure out the actual cost of running an app with all the tiers, weights, and calculations involved :tired_face:.

:money_with_wings: Unaffordable Workload Units (WUs): Even though Bubble claims to have reduced WU consumption, many builders still find it too expensive :moneybag: This makes it difficult for some use cases and raises cost concerns :persevere:

:free: Reduction in Free Plan Benefits: The limitations on the free plan and decreased free development WUs are disappointing :cry:. It feels like a step back in supportinging the development community and may hinder new users from learning and experimenting :sweat:

:moneybag: Pressure to Switch to Annual Pricing: constant push towards annual pricing and timeline for legacy plan changes feels forced, limiting payment options and flexibility :money_with_wings: It prioritizes revenue over user experience :unamused: Agree ?

:alarm_clock: Legacy Plan Changes: The uncertainty and potential changes in the future raise concerns about long-term affordability and stability on Bubble’s platform :thinking: It’s disappointing for users who prefer stability and predictability :warning:.

:chart_with_downwards_trend: Insufficient Drop in Total WU Consumption: The promised reduction in WU consumption may not be enough to significantly lower overall costs :weary: It slao may still be expensive for certain types of apps, discouraging budget-conscious builders :money_with_wings:.

:wrench: User Feedback and Improvement: There is disappointment in Bubble’s responsiveness to user feedback and their ability to make further improvements to the pricing structure :pensive: raising doubts about the company’s commitment to user satisfaction and willingness to address concerns :question:

The promised changes to workload and tooling are not enough to address the affordability and accessibility concerns. I hope Bubble takes user feedback seriously and makes further improvements to ensure a fair and transparent pricing structure for all builders🥲

Based on my analysis the new pricing structure will result in an average increase of 30% in costs for my app compared to the previous plan​:heavy_dollar_sign::chart_with_upwards_trend:

1 Like

RE: Features/Updates, in addition to “Add WU per action and workflow run in the Server Logs tab” @josh can you also either/both:

  1. Add WU count to the runtime debug and page inspect modes as well, so we can see how much it costs to load a page and render specific elements and evaluate conditions within it?
  2. (I hesitate to suggest this for fear of making the logs “truly impossible” to read vs. the current state of being “very difficult” to read) Add any action that impacts WU usage to the logs. Page loads. Searches. Data retrieval. Whatever else you’re charging for.

Otherwise we will still only have a partial picture of WU consumption until “after 5/1” and even then might be reliant on the time-grouped pie chart method, which involves too much trial-and-error, back-and-forth, hunt-and-peck, etc.-and-etc.

Or, an easier solution … don’t charge for those things not currently in the server logs! (at least not on a per-hit basis; perhaps a compromise there to enable you to eek out some more $ from certain types of businesses without being overly punitive on unmonetizable high-side long-tail traffic; it would in a way bring some concept of “capacity” back into play, but it could work, and resolve perhaps all of the remaining complaints here wrt consumer/freemium, non-profit/hobby apps, and DDOS fears)


If I’m understanding it correctly (which I might not be), I no longer have to be concerned with capacity due to the new pricing plan? If that’s the case, the revision to the new pricing plan, along with some optimizations I’ve identified, will result in a significant drop in our costs. We’re currently paying over $500 a month, but with this new change, we’ll be paying just under $100 a month. This is quite a welcome and drastic turn of events compared to last weekend. My fear is that this is too good to be true.


I definitely agree that this requires a comment from @josh or @emmanuel.

Is it accepted on a strategic level that some apps are forced out because they don’t fit into new pricing model?