No doubt.
Youâre absolutely right! As a developer one need to understand how to optimize processes, reduce workload, and ensure better resource efficiency. Itâs always satisfying to see how thoughtful implementations can have such a tangible impact on clientsâ operations. Great work!
I agree with everyoneâs point regarding unpredictability when it comes to WU.
I just wanted to chime in that there was a conversation/article/post (it was a while back) by Bubble that the ideal journey of a Bubble dev is to become a dedicated plan subscriber.
Whether or not we agree with it, that is something that IMO is one of the many goals that guides the Bubble team.
Before everyone puts on their tin foil hat, Iâm not saying that there is some conspiracy of âmaking WU incomprehensibleâ because of it. Opposite in fact. The hires and updates by the team, while arguably slow or insufficient, show that they are trying to find a good balance (of features and fixes) for both new and experienced users as we make our way through that journey.
From all the posts Iâve read by the team and users alike (sharing stories of Bubble Support woes), itâs obvious that lots of issues today stem from the tech debt created from the teamâs bootstrapping days.
The WU model is fine but they need to just reduce the overall costs by around 30-50% and possibly 200-500% for server-side actions which have a 15,000% markup.
Yeah, exactlyâŚ
And then it wouldnât be necessary to spend so much time worrying about the cost of every single little actionâŚ
As Iâve said before, if the actual costing wasnât so high, then micro-analysing WU would be largely irrelevant (and completely unnecessary).
100%
Neurotic microanalyzing is the worst part. Iâm ok with optimizing on a more meta or macro level and not running billions of searches or doing really crazy stuff but the having to choose between discrete actions in a workflow is just crazy.
Thanks @axons
Just so you know, if you work with someone who pays for an agency plan, itâs free to add them as a collaborator no matter what plan you are on. So it just depends on who you work with.
Yes, do that
I do think the pricing model goes against âserving non-technical foundersâ
- people choose no-code because they are not technical. Corollary to that is: they are the least suitable bunch to do performance / cost optimization.
- while it is a good idea to charge by usage, bubble has made things so prohibitively expensive. We can compare directly with other BaaS solutions such as dynamoDb or firebase. Bubble is about 10x dynamoDb and 5x firebase. Neither are known as particularly cost friendly for large applications.
Combining 1 and 2, we get high marginal cost imposed on a user base who is least equipped to optimize that cost away, meaning bubble effectively put a very high threshold on the required return of each unit of compute. So high that things data intensive but have low ARPU becomes financially non-viable.
UPDATE: When it turned out that the cost of doing calculations backend in bubble would cost a more than of twice what I can charge for my business app I had no option but to hire a developer and move the calculations off bubble. Once that is done then Iâve got to ask myself why not move the whole thing off because Iâve lost the concept of a single supplier simple stack. Itâs means building an app requiring lots of calculations and recursive workflows in Bubble is ok for a proof of concept but not for a commerically viable app. Theyâve got the backend charging very wrong I think.
I think the AI slop builders will force Bubble to lower pricing to remain competitive. They simply wonât be able to get away with it anymore.
Bubble has significant limitations due to two main concerns:
- Pricing model â itâs very expensive;
- Annoying slow database performance.
Thatâs the reality so far, so deal with itâŚ
Combine it with Supabase (which feels almost like coding), and you can scale.