I’d also love an answer to this specifically, because in no way is it possible to run my passion project under the new system. Complete bait and switch from when I started a few months ago.
1 Like
And “bait and switch” doesn’t even cover it when you started it six years ago as I did.
10 Likes
In addition to having to migrate my apps away from Bubble, I will also be shutting down my 3 plugins in the plugin marketplace. I don’t want to be responsible for making an app’s WU significantly increase because my plugin uses API calls.
6 Likes
It’s sad to see how badly is bubble team communicating. The strong foundations of this business was built because of the community that you guys @emmanuel & @josh created. You talked to your users and we expressed what your platform was lacking, etc… Most of the times you listened and delivered. But now this pricing pivot looks so harsh and instant, as if you were a pre-pre-seed startup with 10 users that decided to experiment a little bit over a weekend. Sad news - you aren’t.
While going over this thread and even a previous one, higher pricing doesn’t seem to be an issue. We as users that not only experiment with our ideas, but also help other people to make their ideas come true are happy to pay more, but that has to be reasonable. When you grow to this size that you are now, why don’t you involve us a little bit to help you brainstorm what’s reasonable and sustainable over a long run? At the end of the day, we are the people that placed our trust in your experiment and by staying on your side helped your product to survive and thrive.
1 Like
I think bubble needs a rotating community member on their board who can consult them about price changes and effects on community.
This is a massive reaction from the community and I haven’t seen any positive comments from long term users, plugin and theme developers.
I think there has to be some transparency who makes these calls and how much say @josh and @emmanuel have now days?
4 Likes
@gaurav created an amazing (and fair) pricing model that I believe would work for everyone. He even built a website in notion for it.
-
It follows a scalable pricing structure for work performed by apps
-
It has a subscription that covers the cost of using and maintaining the editor.
I highly recommend taking a read and pushing this to the Bubble team for consideration.
Bubble Pricing model and example website
17 Likes
As long as your capacity supports the plan you’re on. You won’t be allowed to change plans and stay off the new pricing.
Putting this in the bug category because this behaviour is (in my opinion) clearly not an intention of the new pricing plan.
I wanted to see how expensive an app relying on frequent webhooks (incoming API request) would be. Unfortunately, it would kill any and all bubble apps that rely on even a moderate amount of requests
Current usage:
Breakdown:
Roughly 55% of my WU units are being spent on incoming API requests. 350 000 (not including dev) would put this app on the Team Plan.
Here is my recent capacity usage:
Roughly … 0% 
It rarely peaks above 3% because this app is already really lightweight - 55% of what it does is run medium sized workflows everytime a request comes in. My app is currently on a Professional plan - with a lot of headroom. What kind of business with a “Team” working on it is only servicing 30 or 50 users?
With the new pricing changes we are going from having headroom to having over 60% of our Workflow Units Capacity being taken up!
These requests do nothing extraordinary, they just go through an auth flow and then update a number in a user. This is using a very common webhook from a financial api called Plaid (sure many of you are familiar with) which sends notifications whenever a user makes some transactions.
The alpha of this site currently has about 30 of these users.
Conclusion:
About 30 users receiving 1 - 4 api requests a day is consuming roughly 125 000 workflow units. No fintech mvp using bubble can sustain using ANY webhook services from an API like Plaid, Stripe or others. In my opinion, this is clearly an oversight of the new pricing model. This was obviously not as thoroughly tested as bubble has claimed. Please fix this issue before killing any attemps to leverage webhooks as a core functionality
19 Likes
There is no need for a rotating community member to be in their board…they spoke to hundreds of users before the new pricing announcement:
3 Likes
Where are these hundreds? If some of you are reading, please feel free to get in and explain to us how we ended up here.
1 Like
I have been watching the comments over the weekend and looking at our business to understand the impact on us and our customers (We are a Startup Lab - building apps for non-tech founders).
Its a bit too long to post in the forum so I stuck it in a blog post.
Simon
23 Likes
@magnus.kanholt as someone who has developed on Native and Low Code platforms before (like www.servoy.com) I have to disagree. Servoy have had a 10% of turnover arrangement for the best part of 10 years.
I just cant see Bubble as being attractive for startup or enterprise with this pricing scheme. Not when it looks like on successful Apps, or anything the writes to a database it starts to cost something like 5 cents per record. My current test was $1.50 for 20 simple 4 text field CRM fields plus a website logo.
The cost of ownership for Apps where customers will pay looks like it will be 50% plus of revenue, and the cost for Applications to run CRM/ERP will be massively more expensive than traditional tools.
I think Bubble just loses its market, if it goes ahead. Its WU cost is 10X what is reasonable even for an expensive platform, but at least if 10X lower you can factor in the cost of reduced time and dev, and have the ability to scale.
Its very disappointing. As an agency with Startups, Digital Transformation, and Enterprise clients, I cant see this being attractive to any of those. Maybe the Free plan or Personal plan for very early MVP testing with <10 users, but thats not sustainable for Bubble either.
3 Likes
Same issue here on one of my apps. Had plenty of resources left by taking care of efficiency. Now I feel like getting punished.
1 Like
In the end, companies need to find a pricing market fit and although usage based pricing would be probably the more efficient way to do it (seeing it from the company’s perspective), many companies have found that users generally reject those type of pricing, even though it is mathematically fair (Bubble’s new pricing is not, clearly excessive), just because its just too complicated and nowadays everyone is used to fixed subscriptions. Unless you are building business for a super technical niche, usage pricing systems are going to be a big block for existing and new users.
Netflix and millions of other companies could be charging users per their usage but how many people would just go to other streaming provider just to avoid reading the complex usage based pricing explanation or because they’d have to make complex calculations to estimate what they’d spend in a month. I’ve heard many stories of companies that tried this usage based pricing and it did not worked, they ended up finding a way (using data based calculations) to charge fixed monthly subscriptions because the market just rejected the usage based pricing systems.
In business you just have to do what works (what the market accepts) and if you want to democratize something with your business and have massive product adoption, you need to have a very simple pricing system.
Apart from making it simple, it needs to be reasonable (not like this new pricing system that is complex and in the case of my app, it would now be paying +$1000 month per user because it has lots of api integrations and recursive workflows).
4 Likes
Simplest pricing solution would be…
No tiers, free for everyone up to X WUs per month.
Pay for what is used after that.
WUs encorporates storage space taken & even support time used.
WUs a based on what it would cost in the wild, ie AWS costs etc, with a transparent markup, which they’d fully deserve.
That’s it. 
1 Like
Yeah, @jonah.deleseleuc, this is essentially the same thing that myself and others are noticing with external API calls, and similar to the issue with SSAs. The pricing for these extremely low-cost sorts of interactions is wildly inflated.
17 Likes
Simon, Thats a very useful blog.
The question I think that hangs out there is whether Bubble’s own optimisation will reduce the WU per se and by how much.
We have looked at some of our MVPs and startups, including my own App that I am about to launch. When it costs me 4,800 units to write 4 short text fields to a new CRM records, plus a couple of foreign keys in a related table, which in MVP land looks like $1.50 with no obvious way for “optimisation” by myself, as its two Create Thing statements in a single workflow, makes me think this is not viable unless Bubble themselves sort the WU optimisation out at their end.
But as you rightly point out, I have no way of knowing or “TRUSTING” to what level they will do that, so how on earth do I take on new clients now if I have to tell them, this MVP could cost you £125 pcm, but it could equally cost you £1250 pcm, and I have no way of knowing. What is worse is if they wish to scale in a months time, they have to pay the new fees to move between plans.
One additional thing, we are noticing that there appears to be some throttling going on, on lower plans with Apps slowing down.
4 Likes
Completely Agree.
Interesting thoughts. Thanks for sharing.
1 Like
I would be ok with a 100/200% price increment. Please Bubble don’t play with my future!
2 Likes