Storage, seats, features etc are all known and the costs can calculated up front. This where I’m getting stuck. If you start new with bubble, nobody can tell you what its going to cost. I don’t know how to price my app as a result. It’s seems I can’t peg what I charge to what it costs me because I won’t know that until after the fact.
It’s very confusing and troubling. I don’t know how to move forward.
Yeah, where to @keith?!!
We’re building a pretty heavy duty enterprise app on Bubble and I’d be so keen to follow you along if there exists a better alternative!!
here my findings of some alternatives more on the low code side than no code (Noodls or Fluetterflow with Firebase or Flutterflow with Supabase)…if you want a new no code solution weweb+xano or backendless added recently the front end feature allowing you to create a full stack app with them …i did not use them yet i just saw couple of video but i think it worth to have a deeper look…also with bubble if you are able to afford the custom tier than you don’t need to worry about WU if i understood right…not 100% sure
@ecosistemanocode here is a big thread where bubblers discuss alternatives, so let’s not transform this thread in another one tools discussions
thanks i could not find it this morning
I’m curious too.
If you care to, can you elaborate? Where are you needing support? Are those things more of something the community can help you with or more of a Bubble engineering thing?
In any case, you should at least stay until l release my next plugin this coming Monday (I know I said I’d release it this last Monday but I’m really really going to this Monday). I need your scathing review
I think what Keith is saying, there’s not enough people around here to use his services (Or, clueful clowns, as he so lovingly put it) to be profitable, at least that’s how I read it.
The bigger issue is user base. There’s no significant user base here (needs to be 100-1000x to support an “ecosystem”). As a result, I’m leaving.
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.
Well said! Sadly, this really does position Bubble more of an MVP bulider than a solid long term solution - which of course would be ideal That’s not a bad thing since people can test ideas out cheaply, but definitely seems like a big missed opportunity if true.
Say it ain’t so, @keith! I’m a better Bubbler because of you, and I’m sure others share the same sentiment. ListShifter alone has enhanced so much of what can be built on here.
I’m really bummed that you are leaving @keith
Thanks for building List Shifter and List Popper – my app wouldn’t have been possible without them!
You’ve nailed it right here. I can understand why people are upset over the changes but i think a lot of users are severely under charging their own users for using their Bubble app. It’s good to offer value but it’s best not to undercut the market too much.
When considering what I can build in Bubble, I’ve always believed that Bubble was offering a steal with their legacy prices. The initial WU release was stupid but at least things look more inline with their original estimations now.
I never used the acronym MVP…but are you making that point based on a large experience working with clients and/or numerous community members expressing their plans with you or is it more likely just your own idea of what is or is not happening on Bubble anymore? Plus, who needs a lot of trust for an MVP?
Think about it like this…an MVP is a one night stand, maybe a weekend fling. Building and scaling an app is like a marriage. Who has ever thought they needed to trust the one night stand? And if you did trust your one night stand, you likely wake up with the consequences 9 months later or in some cases 2-3 weeks later with a burning sensation.
And you can be confident of that with traditional coding? What happens if the app is hugely successful and you need to add more servers? Of course cost per server might be known, but the number of servers is not, therefore your costs are unkown.
Why are they not best practices? Because they are a bit slower to filter the results? Plus, you can’t blame old information for being outdated due to new changes. Personally, in my apps, I don’t imagine I’ll have a need to optimize my searches. For me, I’ll mostly have to become more creative in data manipulation and getting data into the database.
Even in the Bubble webinar last night I spotted two areas in which a Bubble representative was giving some guidance on ways to optimize the app, that I could come up with more efficient ways, as alternatives. It is always important to remember that in Bubble there are a lot of different ways to come to the same end result, and as it was in the past and now, some people will be more effective at finding those ways. That is what sets some developers apart from others.
Yeah, I believe I mentioned that (not the telegram part) people leave Bubble, that is nothing new. People leave or stay for their own reasons. Like a lot of my clients have in the past, they built to validate an idea, start to grow the business, and then reach targets that enable building elsewhere.
I think people overall need to get off the complain train and understand that train has no destination. Bubble is not changing things. What they are doing is improving the new situation with new tools and features. I’ll personally still be here to voice my opinion on what features are needed to make Bubble more efficient in terms of WFUs, especially around data manipulation and in some respects data retrieval.
Nah, what you’ve described is not MVP
MVP in classic terms is an early stage of product development when you release your app with just enough features to get early customers. Then you accumulate feedback and continue development if you can see that there is a market fit. Or close your app cause there is no demand. It’s impossible to validate an idea/product in 1 day or 1 week.
Because it has been tested by hundreds of bubble developers and also some best practices are mentioned in official Bubble documentation.
If there would be no “complaint train” - we would hardly see any positive changes from Bubble in WU costs and other things within new pricing model, btw.
True, when you only playing around for a few weeks all my arguments are dead.
If you do are serious and want a bit more than slides, glides and spreadsheets you look for things like Bubble. And not for a few weeks. If so, Bubble has no business at all anymore.
Given the 10x 100x markup of hosting prices that the new WU pricing is delivering we suddenly talk about prices for a search in the db. Traditional coding does not have this issue because it is 10x 100x cheaper in the first place and there is no cheaper alternative.
But true. No point of complaining but just good to make sure we share information so everybody can make up their own minds
It was an analogy to express the difference in time of relationships…one night stand versus marriage. Marriage is forever, need to use Bubble to scale indefinitely, one night stand is short term, need Bubble to validate a product.
And Again, Why is it a Best Practice? Because using filters is a bit slower? What other benefits are there to not using Filters…have you ever come across a situation in which using filters is faster, because I have.
You must be impatiently waiting for the outbound train then. It’s been a week, how fast do you expect them to move?
My comment was more about using lists than filters. Filters are usually not a big deal until you work with large amount of data or use advanced filtering .
Idk when and if Bubble will react to ideas and concerns shared by the community after WU re-weighting. But it’s important to continue providing feedback to prove that we care.