That is true, but as you build it, you will come to know what it costs to perform the operations you make available to your users. So, over the course of development and initial release, you should be able to isolate the cost of each operation, and then through following the trend over the release you can get some guesstimate of what it costs per user on average per month.
Pretty much did address every part of the question that I focused on, which was the aspects of would his SaaS be able to get away with the variable pricing as Bubble is. My answer was NO, because of how people are familiar with SaaS pricing.
I did not attempt to get into whether or not 175,000 WFUs is a lot because, yeah, kind of very arbitrary as I have no understanding from the question what his app does and how his users are likely to use it.
I think you may have to think about flipping things on it’s head and likely do what Bubble did in a sense, which is to start out with thinking, how much is the market willing to pay for an app that does X…then set out to build an app that does X and see if you can get an idea of what the average user of the app would utilize it for, and how that may affect the costs of operating on Bubble.
Had you from the beginning thought about using Bubble to run your app indefinitely and scale with Bubble all the way through? Most Bubble users do not, and they build initially, gain some traction and then make decisions about whether or not they can scale on Bubble, and if not, they migrate off platform. I’ve had several clients who went this route, and after only 6 months after launch they reached their MRR targets that validated the platform, then set out to rebuild off Bubble.
What Bubble’s pricing change has done is make it so that maybe more people will be thinking this way from the get go.
One strategy is to start off with the expectation that you will move off platform if after building you see the costs as prohibitive for your app, and begin the project with a separate backend. Since the cost of API calls and Bubble database calls are the same as well as the costs of data return per character, you can build all data functionalities elsewhere without necessarily having a higher variable cost than if you just used Bubble’s backend…the difference though, is that you will have a fixed cost that is higher (the cost of the external database), however, you could save on server side workflows since those would be done in the external database…a lot of people are talking about Xano and Firebase for something like this.
With that strategy, you can then expect if you need to leave Bubble because you run too many workflows on the page, or page loads are killing you, or the amount of data being sent between your external backend and Bubble is so much that Bubble API call costs are killing your app, you just need to migrate the front end, and you would do that while pausing efforts to grow your app user base and launch it with a heavy push to promote new user acquisition.
But in the end, nobody even knows if their app is ever going to have any kind of issues with Bubble pricing strategy killing their applications prospects at success.
I think people just need to determine if Bubble is the tool they want to use for their project and create a strategy around how they will use it, with short term and long term goals understood.
I personally have a 6 month, 12 month and 18 month strategy written down for my personal app that I made only after the new pricing announcement and alterations to the costs. Parts of those plans are to learn a new tool for certain parts of my app, and to isolate heavy abusers of WFUs and figure out how I as the developer can set ways to reduce their overconsumption of my precious WFUs, and as a business owner, ways to extract some value from their heavy consumption of my WFUs.
So, this is an example of the strategy I am taking. Others will have their own strategies. Hope this helps.
That’s not a bad thing since people can test ideas out cheaply, but definitely seems like a big missed opportunity if true.