Thank you for the update. You certainly wobbled my trust, but I have decided to keep trusting you… i do think you are decent people and you guys know you f**ed up bad. Trust requires some faith, and I will continue to have faith in you. Time will tell however if this is foolish or not, and people will be watching carefully.
My concern at the moment is that my app is finished, but ABOUT to be marketed. So whilst I can test it with a few test users, I have no idea how popular it will be or how many WUs it will use once we place the ads. Could get 100 visitors but could get 1 million visitors! Therefore I am unable to know what pricing plan to commit to. (i will write to your support about this)
So this leads me to a suggestion… could you some how create a WU “simulation” mode? I am not sure how it would work exactly, but basically it gives you a prediction of your WUs before actually spending any. It could also tell you how many it would use up for X users. Just an idea.
Finally, if you can get the search & modifying database WUs optimised further too that would really help, as those are pretty much the most basic and essential features of any app, and still seem a bit expensive…
Other than that I am still rooting for you and will not give up on my dream of being a bubble success story quite yet!
I was just thinking about something similar. The “build and find out” method is just asking for trouble. There’s really no way for a non-technical founder, who is new to Bubble, to understand how much their app will be affected by this and distracts from the building process. Testing alone is worrisome. Imagine trying to optimize an app so you test multiple ways of doing things, only to see that your WUs are consumed for the month. Just for testing. Sheesh.
Yup, this is the stumbling block. If you have an idea for an app and are looking at a platform, you’ll typically do a back of the envelope calculation about revenue per user vs cost to run the app.
With Bubble, you could get stuck burning a ton of time building the app, only to find out the costs exceed the revenue model.
The only way usage based pricing works is if it can be predicted with absolute certainty ahead of time, or it’s so inexpensive that it doesn’t matter that much. With Bubble, it’s neither.
I’ve built on a couple of other no/low-code platforms and their models were to price on features and have some upper capacity ceiling to deal with an app that was an outlier. This makes sense since computing power and storage is dirt cheap, so the platform isn’t basing its pricing off that.
“ChatGPT: Explain like you’re a 3rd grade teacher…”
Alright, kids! Today, I’m going to explain something a little more advanced. Don’t worry, I’ll make it simple and fun to understand. Imagine we’re trying to figure out how much it costs to use a computer game. This can help us decide how much to charge our friends to play it.
Now, some people might use a method called “regression” to predict the cost. But, I want to tell you that this method might not work very well for this problem. To understand why, let’s learn about a couple of new words.
“Power law” or “fat-tail” or “black-swan” distributions: These are fancy words to describe a situation where some computer games use a lot more resources (like time or memory) than others, and this happens more often than we might think.
“Stochastic processes”: This just means things that are a bit random and unpredictable.
“Log-normal” and “Gaussian” distributions: These are different ways to describe how things are spread out. Log-normal is like a stretched-out shape, while Gaussian is like a bell shape.
Now, the main idea here is that how much it costs to use a computer game isn’t just about adding up the costs. It’s more like multiplying them. Because of this, we can’t rely on the simple methods like regression to predict the cost accurately.
In simpler words, if we use regression, we might think that most computer games will cost about the same, with just a few being a bit more expensive. But, in reality, there might be a lot more expensive games than we expect. And we don’t want our friends to be surprised by a high bill when they play our game, right? That’s why we need to be careful with the methods we use to predict the cost.
I agree there should be a way to use your own resources, such as your computer or browser, to test WU usage. Perhaps, they could create a development version that you can download onto your desktop. You can simulate a virtual server and test the number of WUs you use during development. This will also prevent being affected by DDoS attacks and loss of server time. This will also have the added benefit of saving Bubble a lot of money.
I like many like to test 10 different ways of doing one thing. The new pricing model would scare me away from that.
This is what I’ve been explaining to my wife. I could raise my prices to hopefully continue to make a profit and not just break even (or loose money), but then I would be more expensive than other software companies that do the same thing, so I would loose clients.
And that’s with the current number of clients. Forget expanding or signing anyone else. My app is so large with so many different types of workflows that one client could bankrupt me.
I don’t see it being profitable to continue on bubble, and have already closed my other projects as I was working on.
I have been complaining and crying, I don’t feel better even after this BUT
I do appreciate that Josh and Emmanuel has taken time to try respond to the communicate.
Highly appriciated
@josh great update. a few follow up questions if anyone at Bubble is reading this:
are there any preventative measures against DDOS attacks spiking prices? could someone spam a bunch of GET requests to an app’s page? not really sure what the solution is, but just curious if this was thought about. perhaps some kind of auto cap per User or something.
do Data API requests count as DB searches and/or DB creates/edits? if not, is it in theory cheaper to use the Data API than native create/edit/get DB items?
I think here is the root of where you are mistaken and if you don’t get awareness of this, you’ll keep doing pricing mistakes forever. Here it goes…
In order to set an assertive pricing system, you can’t just consider which is the fairest metric, that is important, but the most important factor is who is your target audience and which pricing systems they are used to accept.
Your target audience is the opposite to AWS and Heroku’s target audience since they target highly technical individuals and Bubble’s target audience are mainly individuals who are not technical and probably hate technical things.
The fairest metric to charge users for Netflix and millions of other companies would also be resource consumption, but Netflix users won’t accept that kind of pricing, hell, probably they won’t even make an effort to understand it.
The correct pricing design process has to combine the key metrics + the type of pricing that your target audience is used to accept (you can’t ignore this).
Don’t compare Bubble to AWS because your audiences are opposites!
Anyways, I appreciate that you’ve been listening to us but my bill increased from $29 month to +$1100 month, without even being live, only 1 test user.
Even if this new changes reduced my new pricing bill 90% (to ≈ $110) it would still be a lot for an app with only 1 user, scaling would be just crazy costly and unsustainable.
Per the last thread, I think this would fall under “Accidental usage,” but I agree. I’m curious what’s going to be done by Bubble to prevent these malicious attacks on our end vs. waiting for support.
Is there going to be a way we can mitigate an attack from the editor?
Part of the WU metrics are the record size being returned, even though you’re doing a count. Now I don’t know if their magic WUifyzer is calculating the full byte size of the record before doing a count, but I wouldn’t be surprised. The size of your document record is likely having an effect here.
In your case, and I’m embarrassed to suggest this as it shouldn’t have to be done, you may want to consider a ‘skinny’ thing that uses only the fields you require to do your count and keep a duplicate table updated 1:1 to your original documents table for quick, nimble and skinny math.
Since overall DB size doesn’t seem to factor in as much as the processing of data in the new pricing scheme, it’s time to get fat with the skinnies. Multiple tables that are purpose built for low WU processing.
Did not understand a word but I trust your argument of authority « I have a degree in mathematical statistics »
Let’s obtain a fair pricing for bubble AND users. Let’s listen to mathematicians. Not only your data scientists and financial directors driven by « profit only ».
The problem is not the pay as you go model. The problem is the totally obscure unit of measurement subject to unpredictable changes. Imagine a car rental company that rents cars according to their CO2 emissions. You have to ask yourself, how much is it going to cost me to turn on the headlights…
Building an MVP to start with would make no sense. An MVP that can’t handle any users? Might as well go through a proper design process in Figma rather and build elsewhere.
I used Bubble basically as a design and dev tool in one. But design can be better handled elsewhere and dev can too. Just not as handy as Bubble was. But at new pricing might actually make sense to do separately.
yeah, it feels like we now need to implement safety measures in our development to prevent users from spamming the DB now. say you have a messaging feature. how do you prevent users from spamming a bunch of messages over and over, racking up costs? or even a simple to do list. how do you prevent users from creating 1000000 to-do items, bankrupting you. I know it’s unlikely that someone would do this, but it’s something we will now need to think about. unless you are right and those will count as “accidental usage” that Bubble will cancel the costs for on a case-by-case basis
@josh I appreciate the update and taking time to reflect on this matter.
Looking forward to see community reports after Friday.
Some clients are happy for sure when their app won’t be affected.
Some new clients will be confused because there are no industry standard to measure wu’s. It’s going to be really closed ecosystem and harder to sell bubble as a choice of platform if it needs to be build and tested before you know how much it will cost is really a challenge.
I just wonder what kind of transparency this wu system has because we have no way to compare this to anything we just know it’s expensive. When you improve the platform does it reduce the consumption of wu’s?
Mostly this pricing change hard to explain to some existing clients who have invested tens of thousands on the bubble and development. I really hope you write in on the paper so we don’t have to.
I am just thinking of upcoming conversations… “hey do you remember that app we made last year. We need to optimize it and make some changes… or we have to shut it down because it’s not financially sustainable after 18 months.“
All these price changes can be pretty dramatic for some app owners… when you start thinking that someone invested their life savings on the bubble ecosystem and then there are massive changes like this.
