Changes to how we charge for applications going forward

Love the transparency and the willingness to pivot.

How do other no code tools price? Perhaps that’s a starting point?

I think its safe to say that every app relies on data and people are ok with paying to have increased capacity but it needs to be in proper scale.
Imposing a 5k row limit is just not feasible to any app, it doesn’t matter if its external, internal, 1 user or 1000. It’s just not reasonable.
And suggesting that people just need to scale back their apps is not realistic either. Reducing from 500k or 1M rows to 5000 is not even remotely an option if you want to keep the functionality that users are used to AND what they paid the developer for.
Imagine if a software vendor told you that your spreadsheet with 5000 rows can only now hold 50 rows so you need to “scale it back”. What do you do with the extra data - delete it? not a chance.

We all understand that price models may need to evolve over time but they need to take everyone into account and not alienate or force substantial numbers of users out of business.

I’d suggest a database size pricing structure or if you do # of things pricing, it needs to have substantially larger limits.

Thanks

Look at the difference… that’s free with the Blaze plan… Applications will never scale with your pricing model.

3 Likes

thanks for the clarification, you have no idea how long I have been trying to figure out how they correlate.

1 Like

Agreed. Upselling could be as, if not more, lucrative for bubble and they don’t seem to be doing a lot of it.

1 Like

I am (or I was) about to launch my application and go to a paid plan. For me at this moment 5k things would be enough but for a more affordable price. It is clear that for most developers this change is a game-changer. I’m afraid about the feature of bubble for Brazilians.

Not likely. Sounds like Zap pricing will be in our future. (What does Zapier charge per Zap?)

2 Likes

Hi @emmanuel, I would be more comfortable with this change if there was a tier for people that plan to use API calls and not store with Bubble that was affordable. We can move our data lakes out of bubble and store elsewhere, and just use bubble as a data warehouse essentially, as long as we knew API calls would not be restricted. That way our records would be <10% of current on bubbles side

Guys,

You are forgetting the big picture.
Bubble raised not long ago 100M from investors.
Now these investors need their money back … and more.
What do you think, where they are going to find that amount ???

Anyway we are going to hire a developer, he will cost us less than bubble.

And still trying to figure it out how 5000 line of text ($20) can cost more than 1GB ($0.1).
Please help me on that @emmanuel.

1 Like

Lots of great potential ideas @david17

Yes please! Currently that’s called “dedicated” and its $$$$$.

Absolutely, yes! Let me pay-per-use for unlimited (reasonable fees of course) for “severless”-like data manipulations.

The marketplace in general could see a lot more revenue and profit to Bubble, IMO (but yeah, that’s complicated).

1 Like

I just posted about this on Twitter, in my view the best way to achieve this is by pricing based on the overall app database size rather than individual records.

Eg Firebase charge $5/GB stored in their realtime database, this is clear and simple to understand, even for newbie users

If you can expose app DB size to us in the logs of our app it makes it easy, and we don’t need to worry about how many individual records we have.

Some DB records in my app are literally one word, some are entire blog posts. Under these proposals, they’re counted in the same way. Pricing based on overall DB sizes fixes this.

I actually like everything about the new pricing plans except the pricing based on individual DB records, and how low the threshold is.

Switch from charging based on individual records to GBs of DB storage solves it in my view, and still achieves the goals you’re aiming for without alienating your customers.

We all want Bubble to be financially sustainable so it can grow and thrive, but we also want to be treated fairly.

11 Likes

You should’ve set this post to April Fools @emmanuel :joy:

All apps – Facebook, Twitter, Airbnb, LinkedIn, ebay, etc. are at their core a database. An app can’t exist without one. The costs of storing and manipulating data has plummeted over the years, which has allowed apps to become much more powerful and useful. As they say, data is the new oil.

With this price change, Bubble is going in the opposite direction. It is discouraging the use of its product for applications relying on data. Which in turn means it’s not a good solution for most apps. Which leaves me struggling to think, what exactly is Bubble supposed to be for, then?

2 Likes

Good afternoon,
Well, this for me proves what I’ve been thinking and verifying for some time, that Bubble focuses on developing apps for MVPs only, that is, just the initial prototype for Startups.
It should not be used for corporate applications.
The limitations of lines (records) speak for themselves.
The simplest plan that I could use is Professional, because in Personal with a limit of 5,000 lines it is impossible.
Understand, I’m in Brazil, only the list of cities in the country has 5570 lines, that is, they alone already exceed the limit.

Anyway, each tool has a purpose and, Bubble, only for MVPs, but because we will (in my view) waste time getting to know, study and apply ourselves in a tool that has these limitations, where others allow us to actually make not only MVPs but also the corporate application.

I’m going to finish what I’m doing and abandon the tool.

Also because they are not in the habit of telling us about new implementations, changes to the tool and everything else.
And I didn’t see the new prices and limits of the Agencia plan here, which many of us use in our companies.

It was a pleasure, I’ll be here for a while. Until later.

1 Like

a generic 100 gb of DB storage, etc would be much easier for users I think to manage and maintain.

example:
Want 10 million rows of data with 2 simple columns? Sure doesn’t take up much storage space = cost are low, but want 100 columns on that 10 million rows of data?
Now you have to pay more since it won’t work in 100 GB of data. Something like this is what I would expect considering cloud storage costs just keep dropping.

3 Likes

This post should include the posibility of extracting our app’s code and let us go WITH our apps.

5 Likes

Other than the option you just presented and read about here, another option would be to make it a limit on new rows per month. This would allow for businesses that need to create historical data, but also scale as companies grow. The issue is that the number of rows does not accurately represent the size/profitability of an application and actually discourages proper database design. We would end up seeing people making bad decisions in regards to DB design, negating the additional capacity in these plans.

2 Likes

@emmanuel The limits are too low. Can we have more options on additional record quantity costs? Have you considered caping NEW records per month versus ALL records?

10,000 at X per month
100,000 at X per month
500,000 at X per month
1,000,000 at X per month

1 Like

Yeah but… there’s a problem with Bubble charging per database thing or even database GB.

For Bubble to place their entire model per thing or DB GB, that cost per thing or per GB would have to be quite high. So Bubble risks being perceived as absurdly expensive.

Because if we were to only pay (and only increase what we pay) based on data storage, we’re actually getting a lot more along with it. So looking at other solutions cost per data storage, Bubble can seem expensive.

There has to be something else it seems. Features only available on higher plans. Or additional paid features (like @david17 's post or Honeycommb Pricing [there’s a million more examples out in the wild]).

Some good news:

4 Likes