It would be great to have access to the feature that enables the viewing of Workload Units per user in Bubble.
By having access to Workload Units per user, we will be able to:
Yes. This should be added in by the Bubble team @nickc @josh as this would definitely allow us to attempt to price our SaaS products in the same way Bubble is pricing their SaaS product.
The details of these metrics should also not only be accessible via the editor but through workflow actions or âlookupsâ so that we could in an automated fashion send monthly billing to our SaaS users based on their usage of the SaaS. Something like users current months WUs metrics
+1 for this. I also logged the same request on a different thread.
Hello @nocodeventure
If we pay attention, in fact, Bubble is very badly making these indicators (Work loads) and their real triggers. Even worse when we have to analyze it in the Backend, then itâs a Pandoraâs box. Bubble, simply created something imposing that we know more than it offers us access to knowledge. Bubble wants you know how to optimize your App, based on almost zero information.
Bubble tells you what to do, but doesnât teach you how. But Bubble says that we have to know how to âlearn to doââŚ
Have you ever noticed that when you modify a workflow, the Charts (On App Metricis) basically donât change? So, how to optimize something that was made for you to have the highest workload rates (so that Bubble can profit)?
My company is already in the process of migrating, we will leave Bubble. Until reach this momento, we have to âaccept no opportunity to complain and be heardâ about some questionable actions from Emmanuel/ Bubble.
This is sad! This is frustrating and this is unfair.
It does update its just very delayed
yeah, I understand you. Thanks.
However⌠this delay, in programming, is not acceptable. Completely outside the agile programming best pratice (Evem No Coding). ALL information should be there, at the time the event is executed. Without this, how can we really be sure of the impact of our actions?
These charts related to our changes are generalist, they say everything and ânothingâ at the same time⌠( omg ) 
SOme times we now the element, but, we cannot know what really do to reduce workload effectively. 
I really wonder whether the users of your SaaS Bubble app will accept that kind of pricing scheme. Unless youâre offering something super unique, Iâd imagine staying competitive and holding onto your users would be an uphill battle.
Ideally our users would never know/care what the app theyâre using is built on, but here we are discussing pushing our new problems downstream. Just another example of how this decision has eroded the value of building on Bubble.
âOh sorry customer, I know monthly subscriptions are standard for 99.9% of platforms you use, but for this one youâre gonna have to cough up a random amount of cash at the end of the month based on usage because I donât want to go underâ
Canât see how that is something thatâs acceptable.
Lots of services charge by usage these days. Most AI services charge by tokens. Internet cafes and arcades have charged by usage or place limits on use for decades. Itâs nothing new to the consumer.
Being able to track WU usage per user also means we can place a cap or limits on a per user basis. I have a SAAS and i find it useful.
Fair point, it follows common sense that AI services or any service that is generative be token based. My point is more that it doesnât follow common user sense for a non-generative app to be token based, so thatâs going to be the challenge of implementing and communicating a pricing strategy like this for non-generative apps. Iâm more than willing to be wrong, just my intuition.
Iâd be very curious to hear an example of how this could work for your non-generative app cases. Do we start creating our own artbitrary usage metrics? Like imagine a Trello competitor⌠âYouâve used up all your card drops this month, increase your limit to keep editing your boardâ.
Still doesnât sit right with me, but keen to hear more.
Kind of the point of my post
But, given the fact that anybody who wants to build a business using Bubble would need to figure out a way to price their SaaS in the traditional and market accepted form, it would at least be beneficial to see some sort of metrics per user so we could extrapolate a bit more detail on a user. This way we could do some of the things that is traditionally accepted like creating tiers, as well as some of the things Bubble is doing, like pricing on usage, and there are some other services like PDF creators that price based on usage like number of PDFs created in a month, as well as email providers that price based on usage like number of emails sent in a month.
So, if a SaaS built on Bubble offers users access to email communications, PDF for reports, AI for chatbots etcâŚthese things can be price based off of usage, and so it would be great for Bubble to give use those details of our users without our need to create workflows that eat up our WFUs to have those details.
Iâm all about working with what I have and not worrying about what I wish I had or dwelling on what I donât have. Got to push forward with what is available to you, and asking Bubble to make some more details like per user WFU metrics are things that if we had, would make more possibilities for how we decide to price our products.
Various combination possibilities when you think a bit more creatively on the topic.
Perhaps a tier in which you get 1,000 emails, 200 pdfs, 10,000 words from AI and features like trello boardâŚin which case, no you likely wonât be able to charge per trello board drop or put a cap on the number of drops available because likely users wouldnât want to use a system that causes them to have to consider every move they make (much like how Bubble is going to lose most of their user base for the same very reasons)âŚ
but hey, weâve got 17 more months to see what Bubble does / (more than likely doesnât do) for us to either stick with Bubble or start rebuilding our apps using different services. I think that most users will be rebuilding with other services soon. My approach is to start by migrating away from Bubble backend and then rebuild front end in another service in the next 5 months if Bubble doesnât do enough to make Bubble a viable option.
The sink is shipping, apparently there are people in the hull pumping out the water and attempting to find ways to patch the holes, but we can not see them working, and will only see if the holes are patched once the ship stops taking on water. Youâd be wise to put a life vest around your neck and at the very least now where are the closest life rafts.
