Forum Academy Marketplace Showcase Pricing Features

WU tracking per user

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:

  1. Identify any potential bottlenecks or imbalances in workload distribution.
  2. Track individual user contributions and productivity levels more effectively.
  3. Make informed decisions about resource allocation and task assignments.
  4. Allocate different pricing models per user

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

1 Like

@nickc any thoughts on this suggestion?

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 ) :grin:

SOme times we now the element, but, we cannot know what really do to reduce workload effectively. :hot_face:

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.

1 Like

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.

1 Like

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.