Changes to how we charge for applications going forward

In the end due to the high load of requests Bubble has, they are able to negotiate better prices for themselves and then charge us as AWS would each of us and make a small margin out of this.

Suggestion of a user that had alot of troubles with server capacity
1-) Make available a stress test tool that user can measure their capacity needs (we bought 2 times the dedicated plan and had trouble 2 times because of it)
2-) Allow each plan to buy as much capacity as they want(today production just allow to buy +30 units)
3-) Keep the prcing the way it is

As someone who has done worked with firms in crisis in the past, I think Bubble will start to realize it has created a crisis here.

Bubble has done great things up to this point and I’m rooting for it to navigate through this successfully, both for its benefit and for the benefit of users. However the way this has been rolled out and is being handled indicates they need some professional help and outside perspective really fast.

Quick update on the poll results @emmanuel

The quantitative data overwhelmingly supports the comments on here.

Actually @david17 had some awesome ideas for possible premium features, sorry I missed this in my last reply!

Great point. Pre-built plans with multiple usage metrics in each plan is dangerous.

To be honest, pricing per capacity has a lot of problems right now.

It seems clear that the Bubble Team understands our frustration with this new pricing change and from the sounds of it, it sounds like they’re willing to hear other suggestions of how they can modify their pricing model?

In my opinion, they shouldn’t bill based off the number of entries or things in the database, but rather usage maybe? The bandwidth? CPU usage? Memory usage? Storage usage (This already happens)?

@emmanuel or @moderators, can you put a ā€œStaff Colorā€ on the staff responses? That’d help identify what response we’ve seen from Bubble thus far.

and…we are back.

I think this highlights the problem bubble has by being an all-in-one solution (Both Front & Back-end) and unfortunately trying to create a singular price model that caters for all use cases is quite difficult. I empathise with them, but this is the reality of all-in-one solutions.

We love bubble for it’s front-end capabilities, but am glad that we have switched to Xano as our backend.

I just tried to connect with Xano on a demo app. Seems to work great with some issues outlined below.

Pros:

  • 1000+ rows shown without effort
  • Filtering seems to work instantly
  • Creating a new record works instantly and also updates the repeating group.

Cons:

  • Repeating group does not update real-time, need to force a page-refresh
  • Rate-limiting might apply

Seems like we’ll need to re-assess an approach on where some of the data will be hosted externally on Xano.

Demo: Bubble Application

If you’re going to charge off of database size at all, it should be actual size in GBs not number of things. The fact this is even a conversation that the Bubble team is having is a nightmare. I’m actually hoping I wake up and this was all a dream. Absolutely terrible decision.

Charging based on number of users is also ridiculous, the value of a user to a company using Bubble varies wildly. This model wouldn’t hurt us much since we are higher ticket, but companies with a low price point that are going for volume will have a rough time of it.

Yes, don’t agree with this.
Bubble (artificially) preventing a workflow from running because of a capacity limitation is a major issue for production Bubble apps… as is the broader issue of stability, but this part of it is at least fixable.

The model should incentivise Builders and Bubble to make apps run fast and be reliable all of the time. That part of today’s announcement is v positive.

Truly what @renatoasse says is true, you see this change as positive but you do not realize that you will lose credibility and a large mass of users and developers. The database does not have to be an impediment, it was the most precious pearl and it competed with other no-code or low-code development platforms. Now with this limitation I will not be able to tell my clients and it will also come out of my dictionary that bubble.io is the most powerful platform for the development of applications or web apps, because they are simply taking away the proposal of greater value, which is the database. without restrictions or prohibitions.
@emmanuel

THIS.

Well, I actually partially disagree with this. Capacity is too loose of a term, there should be a solid way to measure how much you can actually do with x amount of capacity…

There must be another metric that can be used to price though. I 100% agree with @emmanuel that the term capacity needs to go…

I’m in the same boat. I’ve got my app ready to launch and it’s a social media-style app.

But, do you think we’re jumping the gun a bit early? Would it work out okay to use an external database service?

I’m on the personal plan right now, and xeno’s lowest paid plan is $53, so I’m NOT thrilled at the thought, but I wonder if it might be worth hanging in…

external DB connections are probably going to become the norm among bubble apps very quickly.

but i doubt this was bubble’s intention? :stuck_out_tongue: