Ideas for Bubble's new pricing model

[johnny]

In response to:

@emmanuel

Hey everyone,

(Posting this here as a new thread as my response may be hard to find given it’s a pretty long there.)

We’ve been watching the thread, and appreciate the feedback re DB things.

I know that for applications that have been running on Bubble for a long time, and built their apps without thinking about the number of database things, this leads to extreme situations, which makes these limits feel low. That’s why we’re not applying any of these changes to existing applications till 2023 at the earliest, to give us plenty of time to figure out how to make it work for you. The kinds of things we have in mind to help users who would have a very hard time adapting to this, which we would apply on a case-by-case basis:

• Giving special discounts
• Extending the time period on the old pricing
• Coaching to redesign the application
• …etc

The last thing we want to do is to make Bubble unaffordable for people who’ve trusted us as their platform.

We are aware our tooling to clean up DB things currently isn’t great, and we are working on improving it: we plan to make sure it’s good enough to efficiently clean up massive databases well in advance of the new pricing coming online for existing apps.

For new apps, it’s difficult to predict in advance what the right limits are, because all of our current apps were designed with the assumption that database things are basically free. We don’t want to discourage or disincentive people using the database, but we also feel like it’s the fairest way to charge for applications that aren’t directly exposed to external visitors. We plan to take the community feedback into account, watch how new users interact with Bubble, and make adjustments if we feel like the numbers aren’t working out.

We’re a community-driven company, which is why we discuss these things openly on the forum. We very much appreciate the feedback, and we’re committed to landing in a place that drives long-term sustainable growth for Bubble and long-term sustainable success for all of our users.

Emmanuel

Some proposed solutions:

Changes to how we charge for applications going forward

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)?

Changes to how we charge for applications going forward

[Screenshot - 2022-03-16T221053.763] A more reasonable approach. @emmanuel

Changes to how we charge for applications going forward

What is the problem to pay for bandwith and workload on the server? We pay for the hosting of our saas and that everything is online - that bubble has a great software we can build our tools is just the reason why we choose you as provider. (Same like when you build a website or when you choose a hosting provider). Of course we use bubble cause we love the software - but this is just the start. I would do a base flat for capacity and bandwith (so even if you use different data storage systems…

Changes to how we charge for applications going forward

I would recommend a limit on workflow (+ background API workflows) steps run and records loaded from the database. Each application uses workflow steps and loads records from the database. So you could limit that. Also its something very measurable. Free - 100 workflow (steps) and 100 records loaded a day Hobby - $6 /month - 1k workflow (steps) and 1k records loaded a day Personal - $29/month - 2k workflow (steps) and 2k records loaded a day Premium - $60/month - 5k workflow (steps) and 5k r…

Changes to how we charge for applications going forward

This reply gives me hope. Good: The best part of the whole change is being able to have overages which let your app keep running. Bad: The record limit would kill my app due to launch this week (which I am now delaying). … @emmanuel , bubble serves so many diverse applications that I think you have to find a way to focus on charging for what costs you guys more resources, and let the chips fall where they may. How much do you charge for a 10-cent pen used in a classroom vs a 10-cent pen use…

Changes to how we charge for applications going forward

@emmanuel I’m done griping, here is my proposed solution(s). There is a responsibility of the Bubble user to monitor their app to ensure that their app remains active when traffic/usage spikes, and adjust their plan accordingly. The fact that some Bubble users fail to do this, is not a problem that you guys need to solve by changing the pricing model. Making a change like this is actually just punishing users like myself, that monitor our apps diligently and properly forecast growth, to solve …

Pricing change is on pause for now

@emmanuel Great to see a misstep acknowledged, rather than a political non-answer. For a pricing model to stand on its own, it has to encourage organic growth. Which in bubble’s case would primarily be users like me looking to release a SAAS MVP and then bring it to scale. The database rows limit is an absolute non-starter for this - given the data needs of any modern business. From previous posts you have also elaborated on the difficulties Bubble faces in balancing the associated costs int…

[buero]

Changes to how we charge for applications going forward

[Bildschirmfoto 2022-03-16 um 22.56.53] Lets make it really short and simple - why don’t you guys take the costs for the AWS and multiply it by 3 or 5 and let the user pay this. (Bubble is working with aws) Pretty fair cause he pays for what he uses You are on the save site cause user pays what he needs Clean and Simple Pricing Works for amazon - why not for you guys?

[johnny]

I actually really like @andrewgassen’s idea

Pricing: the path forward from here

I’ve stayed out of this for a while, but since everybody else is sharing ideas, I figured I’d share some, too. Charge me a monthly fee to use the editor. If I’m a business, charge me per seat to use the editor in my organization. I can add or subtract editors easily, like Slack. When I’m ready to deploy an app, I pay per “capacity unit.” I can keep buying as many units as I need to and I pay for each one of them. I can set “overdeploy” ranges for my app to autoscale up to a certain monthly cos…