How NOT To Roll Out A Price Change

Today Bubble announced an upcoming change in their price model via a forum post.

To say it was received poorly is an understatement.

It was universally roasted far and wide and was quickly retracted.

So what went wrong?

As far as we could tell, it feels like they either never spoke to their customers or really didn’t understand how their customers used their platform.

The biggest change in the new price model was limitations in number of database entries and number of visitors. In the past there were no limits to this, just limits to computational power.

The number of database entries is most puzzling simply because it has no relationship to the amount of storage used.

You could have 100 database entries consuming 1 GIG of data and that would be priced far less than 100,000 database entries consuming 10MB of data.

The free plan would have been limited to 200 database entries under the new price model. This means that apps that allowed for messaging between two customers would quickly end up surpassing the limit. Or apps would have to stuff entire messages conversations into a single database entry (thereby incurring a performance penalty and prohibit efficient scaling later…)

A Better Idea

Instead of just poking fun at Bubble, we would rather offer some ideas on how to approach a new pricing model.

We understand that Bubble needs to have a different pricing model. The current model based on computational units is too opaque for most users.

Unfortunately, Bubble is based on AWS, one of the most expensive cloud providers out there. And, because of the features Bubble offers its customers, it’s clear that it utilizes some of the most expensive features that AWS offers.

This means that there is a clear floor on pricing for Bubble. And it’s not an inexpensive floor.

We do believe that Bubble can probably simplify pricing by using some combination of:

  • Storage
  • Bandwidth
  • External API Calls
  • Visitors

The External API Calls is needed because many apps do not have a lot of user-facing interaction but might make tons of calls to external services.

The bandwidth limits can be used IF they have a good way of identifying bot traffic and DDOS traffic.

The just proposed pricing based on database entries is one of the worst metrics to use.

We’re happy to see Bubble quickly rethinking it’s approach here. For us, we’ve grown comfortable with the computational pricing model. It’s still far better than the database entries pricing model!

Leave a Comment