An Update to Workload, Plus More Transparent Calculations

[aaronsheldon]

As has been noted Bubble used classical regression to develop their new pricing model. This methodology is invalid when applied to multiplicative processes, like computation resource consumption, as computation statistics violate core assumptions about centrality, normality, and homoscedasticity. But what is a multiplicative process in the context of computing? To illustrate this I’ll describe a simple coin flipping game that represents the increase or decrease in compute resources:

Imagine you are running a server and you are counting operations per second being computed. Each process can randomly lead to more processes occurring. The system follows these rules:

1. At the start your server computes one operation per second.
2. For the next step you flip a coin.
3. Heads you double the operations per seconds.
4. Tails you halve the operations per seconds.
5. You iterate this over an hour, 3600 seconds.
6. Then you add up the total amount of operations you ran by summing the operations per second over all the seconds.

Now it turns out this process leads to an obscure piece of mathematics that I happen to have studied deeply in graduate school called Integrated Geometric Brownian Motion. This is very important because the key feature of IGBM is that the average total resource consumption always increases exponentially in time; regardless of the weights of the coin and how much you multiplicative increase or decrease the rate of computation. As long as there is a chance, no matter how small, that the rate of operations per second can increase, the whole thing will on average get out of hand exponentially.

What is worse is that the distribution is fat-tailed meaning there will be processes that will get very, very, very large even if most of the processes stay within some reasonable limits. This also means that regression models, which are intrinsically linear or additive will badly underestimate the probability of these large events occurring. Basically the model they used assumes, in the use of the normal distribution, that large events do not happen that often. So, under the assumption of normality it does fairly assign a high cost to those events. Unfortunately, reality begs to differ and those large events happen much more frequently than the means and standard deviation of the regression model would indicate.

There are other dead giveaways that there are some serious power laws at work. Not the least of which is the extraordinarily large number of zombie applications, or applications that are nearly empty, in comparison to applications that have a functioning subscriber base.

[keith]

@jonah.deleseleuc

Just wanted say RIP to server side plugin actions. With them costing 0.2 WU and another 0.0005 WU per millisecond

Well, @jonah.deleseleuc, if my math is right, the markup on lambda executions in the updated weighting should be reduced by more than 2 orders of magnitude from what it was before (the cost per millisecond part). So while that’s not a bargain, at least it’s not an outright non-starter. We weren’t aware before of the static instantiation cost (what’s now the 0.2 WU part).

Hard to say in practice whether this might “feel” too costly, whatever the total comes to, but in my original tests a trivial workflow executing a trivial SSA plugin was coming to more than 13 WU. I’m guessing in the new model we will see much closer to the 1 WU range… maybe? Anyway, it’s substantially better than in the original model.

There may or may not be advantages to using extremely simple SSAs (like the Flow State plugins in List Popper), but it could be that using them to hold the result of a search might be advantageous. It’s gonna really depend on a lot of things that we can’t test just yet.

Some of my SSAs (like List Math SSA) in Floppy, are designed to process lists of course, with the goal of avoiding recursive workflows to do simple computation. It seems like under the new model, there could be huge advantages there.

In general, given the instantiation cost, it would seem that for custom backend code that’s almost always going to be better to execute as a serverless function somewhere else rather than in Bubbles backend (trading 0.2WU + billable time for 0.1WU + data egress/ingress).

It’s good that WU cost for outbound API calls has been reduced, but not knowing what it really was before, it’s hard to say what the impact of the changes will be. (Is it a 10X reduction, or not as great as that? But I’ll be really interested to see the WU changes tomorrow.

[TipLister]

Jeff Bezos made a very important decision about Amazon’s vision early on.
being customer centric
and then to add this whole cycle:
lower cost structure, lower prices, better customer experience, more traffic, more growth etc.

i really hope this cycle is the way you think about WU units and hope to see downwards adjustments not upward adjustments as chips and AWS servers become cheaper over time.
[this imo also includes less WUs consumed per CRUD operation every quarter!]

thats imo the best way to beat competition with bubbles current scale advantage.

just a reminder, as unfortunately in the last 2 announcements of pricing you seemed to have forgotten.
your community is your greatest asset.
a new player even after 2 years will not have such a helpful forum, vast library of free video tutorials, free plugin devs, cheap paid plugin devs, freelancers or agencies, who all engage in free marketing.

please leverage this asset
eg by asking power users what mini improvements to the editor they would like [some things are inefficient since 3 years!]
by not only doing 100 pricing interviews with power users where you do 90% of the talking but actually showing them what 1 WU consumes. In fact this whole loss of trust, which undoubtedly will cause people to leave or learn a second tool to derisk themselves instead of going allin on bubble, could have been avoided.

your community dies, your competitive advantage dies.
you have started to hammer in the nails to the coffin. showing little learning from last year.
please dont do that. we all love your product and our confidence and livelihood does depend on it. how much is your choice. most skilled bubblers are good enough to switch over to other good tools as fast as SVB customers switched over to bank of america.

happy to get on calls with you if you people need help.

and i will be testing what 1 WU consumes in different scenarios tomorrow.

thank you for showing atleast some listening skills in this post.

[CapiBalid]

After almost a decade here, this community always impress me with these explanations, arguments, and reasons on their posts. This led me to conclude that this forum is extremely packed of brilliant and intelligent people, which could be an open source of knowledge to Bubble team. Then, why you guys at Bubble’s HQ don’t simply talk to them!? Spend a couple of hours outlining your honest intentions and get the best-ever feedback, rather than spending time collecting non-clear stats with questionaries to “surprise” us later with this kind of stuff. It is sad to watch how many dreams of people here have been crushed during last days.

[jonah.deleseleuc]

Charging per ms is the problem. It’s not ms / gigabyte or ms/ processing you use (however you want to call it). That means you can rack up a nasty bill with a simple setTimeout plugin… which costs almost a fraction of a fraction of a fraction of a fraction of a fraction of a fraction of a fraction….

of a cent to run in the real world

[Rachel_BubbleSupport]

Hi there! To address these concerns:

• Yes, if you get DDoS’d, that’s accidental usage and we have your back
• We are actively working on additional protections at the CloudFlare level in light of our most recent DDoS attack
• We are also brainstorming self-serve solutions at the app-by-app level

Hope this info helps! Feel free to reach out support@bubble.io with any additional questions or concerns. We’re here to help

[aj11]

While a step in the right direction for the new pricing, this all makes no difference to the ability of a serious SaaS business to continue to rely on Bubble. Here’s why.

Pandora’s Box Has Been Opened

The Bubble community spent the last 5 days researching Bubble alternatives, and what we found surprised us.

Not only are there comparable alternatives, but in some cases these alternatives are easier and/or more powerful to use. Most importantly, these platforms also allow you to EXPORT YOUR CODE. They have enough confidence in their product that they allow their users to walk away, at any time, with the React/Flutter/Vue source code for their application. No vendor lock-in.

The Cost of Not Owning Your Code

Regardless of any adjustments to the new pricing, Bubble has shown us the untenable business risk of building a product without owning the source code. If you don’t own the code, you don’t own your app. If you don’t own your app, you have substantially less value to sell when you want to exit and the entire cost structure of your business can be changed by as much as 10,000% overnight with no recourse other than to get on your knees and beg.

I think I speak for many Bubble users when I say that we will only consider putting our plans to rebuild outside of Bubble on hold if we have a permanent option to export our code from Bubble (without penalty) within the next 30 days.

A Bubble Without Vendor Lock-in

It may take some time (or not make sense at all) to actually build a UI for code export, but the option of requesting a manual export via Bubble support would be sufficient. You have promised to do this already if Bubble closes up shop, so if that’s actually true, manual exports on request shouldn’t be an issue.

I think it would also be understandable to require some kind of annual commitment to a higher tier plan in order to have the code export option. We’re not asking for handouts here, the key thing we need is the optionality. We are willing to pay a reasonable price for it.

Counter-intuitively to what I think you believe will happen, very few apps will take advantage of the code export. The ones that do take advantage, will mostly be doing so as a fail-safe, not because they are leaving. It becomes much easier to raise money or sell your business if you can tell your potential investor/acquirer “we use Bubble for speed of development, but we have a copy of our code sitting on GitHub as a backup.”

Thank You Bubble

I will sum this up by saying thank you to @emmanuel, @josh, and the whole Bubble team. Bubble has opened many doors for me and empowered me to launch a fast-growing SaaS business as a UI/UX web designer, without having to hire developers. I DO NOT want to have to leave Bubble (it will take 4-6 months to rebuild our product elsewhere), so I sincerely hope that, in addition to these welcome adjustments to the new pricing, you add the code export option to allow companies like mine to continue to build happily in your ecosystem.

All this being said, I (along with many others) will have no choice but to rebuild elsewhere if you refuse to allow us ownership of our own code.

[nsilent27]

It’s hard to say anything yet, until they update the numbers and I can’t estimate price adjustments. But given the graphs I’ve seen these days from users, I suspect that there will remain a 2-5 times price increase (for someone much more).
The proposed way out looks to me more like a bone thrown to the public. Most of the problems remain unresolved:

• The average cost will still be much higher than the competitors (fortunately, I’ve studied a lot of them in the last few days).
• The average price will be poorly predictable in the planning stage of the project, this calculator gives nothing away. Competitors don’t have this pricing, the closest system is the number of page downloads per rate, but this is a 10 times more convenient and predictable metric.
• At any moment, the calculation formulas can be changed, making certain applications unprofitable (hardly anyone will believe that you won’t change the rules of the game after the last two fiascos).
• Reducing WU consumption by 50-90% (i.e. 2-10x) for many activities is unlikely to be enough and fair, because it has been calculated many times these days that there is an overestimation of cost compared to AWS/Goggle, etc. by tens, hundreds, even thousands of times.

So for now, I’m extremely critical and stick with the plan to look for an alternative. Tying the future of my projects to Bubble seems like a hell of a long shot.

[guidomazzanti]

Same here, paginating a repeating group, consumes a lot of WUs because of the :count calculation. Therefore, I have no clue whether or not to not paginate RGs… I cannot tell what is more WU consuming , to paginate or not. Hence I will have to do some tests in order to disclose this WU mistery.
In addition, I use :count also to manage some nice featuras enabling/disabling some buttons, that I had to get rid off.
It is rocket science to disclose WU magic

[keith]

@jonah.deleseleuc, but that’s how your SSA is charged in AWS, by the duration of execution. So, it’s not a good idea to run a plugin like that.

The goal of a serverless function is to get in and get out quick, not to idle which is what your plugin does. While that idling doesn’t consume compute, the way a lambda is charged by Amazon is some tiny amount of $ (about $0.0000000021 in the case of Bubble SSAs) per ms (the “billed duration”). Bubble then marks that up (by 128X-ish I think in the new case).

So this specific example is one of those “don’t do that” things.

[jeffbuze]

I appreciate the response, transparency, and adjustments to WU calculations.

I humbly disagree with WU being the right metric for all tiers.

• Reason 1: As Josh seems to confirm, it’s directly related (through weights) to the cost Bubble incurs for compute, not based on predictable or controllable usage from an app developer. In the end, we are paying for Bubble’s inefficiencies (in addition to our own). (yes, the changes correct for some of it, but still that is the essence of WU calculations).
• Reason 2: Hard to predict or understand usage into the future. As a developer, I’d want to answer questions like what will the cost based on things I can also predict or control. What will happen when I get to 500 users? 1,000 users? 1M users? Bubble is a no-code platform, use things no-coders will understand.
• Reason 3: Complex pricing will impact self serve user conversion. Talk to folks that do pricing for PLG products. Number one rule is pricing needs to be simple to understand. You basically made the “Enterprise? Call us for pricing” the first tier (through the price calculator and convoluting each tier with WUs).

Something just seems off between the business strategy, the understanding of your core users, and how it all aligns with this new pricing approach.

I totally get that you need to protect and grow revenue for successful and resource intensive apps built on Bubble. I just think you are making it too confusing and complicated for people starting out.

The initial tiers (Starter, Growth) should just use metrics that people already understand and are easily predictable to cap usage. Keep it simple and it’s ok if it doesn’t match up 1:1 with your costs. That’s all businesses. Per user cost is an average. Then add consumption for the more mature tiers.

[xpioker]

#FreeOurCode

[dipaivabrito]

The way it’s calculated, you can’t even scale it, so my system only has 5 active users, it’s 2k WU, calculating it.

I also don’t trust it anymore, it’s not a serious company and it doesn’t show stability and security for customers…

I’m already studying Wappler and redoing my project. I went!

[pachocastillosr]

Agree, this is great feedback that Bubble get through the forum.

I think they should use forum polls to validate their hypothesis and build with us instead of doing just individual interviews that have proven to be much less assertive.

Poll example:

Do you think building with the community by asking questions through the forum before doing the changes is a good idea for Bubble?

• Yes
• No

[Kent]

Thanks for your input @bryan3 and in theory your suggestion makes sense given the current state of Bubble. In practice though, it is completely absurd and out of principle I refuse to implement a separate table just so I can get a count of the database records in another table. That just makes more work every time a new document is created/edited/deleted and introduces data inconsistency risk.

Maybe if my app had 1,000s of users and millions of documents that would make sense, but we are talking about an app with just a handful of users and several hundred files (at least at this point). There are some serious bottlenecks in Bubble’s current system design, none of which mattered too much under their old pricing model but have now come under the microscope. I’m hopeful they are going to make changes under the hood that will dramatically improve the efficiency of their systems and allow users to better optimize their apps as a by-product. Unfortunately, as others have rightly pointed out, Bubble’s interests aren’t aligned with that goal since they will now actually make more money when our apps are LESS efficient.

[tja]

We went from an easy to use tool to something where users need to have an “engineering” mindset and analytic skills to break down and forecast the costs. This might stop people from using Bubble.

To control costs in a complex cloud environment like AWS and Azuring using budget alerts, rate limits and monitoring suddenly seemed a lot easier than doing this in Bubble.

I appreciate the adjustments done by the Bubble team, but a requirement for our business is predictable pricing a must. Especially since we are ‘locked in’ with no option to export and self-host.

[finsenseiteam]

I was building an affordable (~$10/month) DIY financial planning (more automated planning “wingman”) through an agency (thinking better to outsource), but now back to square one, learning it myself. I know the agency had sought several API structures through backendless, along with text notifcations, reminders, etc to the user. Given the complexity of the idea, I was told building it completely within Bubble would not work; outside solutions would need to step in and do some heavier lifting.

But, I liked the idea that I could, once I had even a basic idea built out, have a certain monthly cost that I could pay to test it out. Even if it were $40 “more” than I would otherwise pay on the per unit structure, it’s predictable for me. I don’t pay for the number of emails I send, API hits to Google or Microsoft, or my CRM, etc. I’m not a power user, but if I build or pay to build, will my app set me back $50/month or $1500 (exaggeration, I’m hoping) after I’ve built it out.

If my build were to cost me $12/month in “unit costs”, again I won’t know until I build.

[CharlesD]

@josh , @emmanuel
Still too early to have an opinion on this announcement.
Even though I’m not a key user (I mean…not yet.), I’m just sharing general comments below to help in your brainstorming :

1. We understand the necessity to improve the pricing for Bubble’s sustainability, and that’s OK, but … Take your time. It’s better to come up with something robust once for all. If needed, you can postpone the deadline of May 1st by a few weeks. avoid any burnout due to the high pressure

2. Brainstorm more with your community than with your engineers : focus groups, individual interviews, etc. => from top agencies and Big companies which have already scaled-up so far on Bubble, to freelancers, Trainers, solo-entrepreneurs, even rookies (they have big ambition! understand how to raise their loyalty as they scale), etc. The typical Bubbler is a caring person (see on the forum how they are always willing to help!). They are smart, brilliant enough to give you the best for the value you offer. And I insist on the word “value”. Not cost!

3. Previous WU calculation is more like cost accounting than a value oriented pricing. it’s supposed to be an internal tool of yours, in order to identify inefficiencies and improve the algorithm. Instead, Pricing should be focused on the value you provide, and we all know it’s great value. It’s all about finding the right metrics of value. I’m saying that but I know it’s difficult to find one single metric of value versus the diveristy of Apps we can build on Bubble, and this can make that approach feel philosophic. Maybe you did try it and it was too difficult ?

Now :
Example 1 : Database search : why should searching for 100 items cost more than searching for 1? the engine has to search through all items anyway and what makes it fast is your indexation algorithm. From customer value point of view, both searches are the same. The number of items you’re searching though may impact, but not the number of items you retrieve.

Example 2 : page load at 0.15WU? competitors will launch high load on the pages to shut it down, and there’s no customer benefit out of that.

Example 3 : Today, the developer has to perform several actions sometimes to do simple things he would have done 1 shot in code. Let’s say that is worth 100WU. Then you invest and improve. In 1 year he’ll be able to perform the same thing with less actions. let’s say it’s 70WU (30% improvement). In WU system, it means that Bubble will earn less (unless WU calculation is hacked to compensate that), while the experience of the developer will have improved. The same issue you were facing with capacity will remain. The experience of the final customer stays the same, so the value hasn’t changed => you earn the same. But because you ease the life of the developer he (or she) is loyal, able to build faster to offer more to the final customer without switching to code while scaling-up, thus bringing more value and earning to Bubble.

Anyway, let’s wait and see, trusting you’ll find the right compromise for everyone.

[jmfcristo]

The sales tactic that involves initially presenting the most expensive product and then presenting the least expensive is known as “price anchoring”. This technique takes advantage of the fact that consumers tend to base their purchasing decisions on the first information they receive. By first presenting the most expensive product, an “anchor” is established in the consumer’s mind that is then used to compare the rest of the products. This makes the least expensive products seem even more attractive and accessible. However, it is important to keep in mind that this technique can be perceived as manipulative by some consumers, so it is important to use it with transparency and ethics.

[StandUp]

Hi @josh and @emmanuel, I think one reason why your new model is so scary is because, psychologically, it is similar to a parking fine*.

(*in the UK, parking fines often happen because the signs are designed to be difficult to understand, so the local council can raise more revenue.)

If we make a mistake, or if our users spike our usage, we get hit by a large bill.

No one likes parking fines, not because they don’t like paying for parking, but because it’s an unpredictable kick in the gut.

Personally, I’d rather pay for parking predictably.