@josh, do you really think this approach is fair? What do you have to say about the discrepancies pointed out by @boston85719 regarding WU charges? These differences clearly indicate issues in the system, and simply stating that it’s not a bug doesn’t resolve the problem—let alone rebuild the community’s trust.
I understand and support the focus on AI, but transparency in WU billing must come first. If this were a bug that benefited users by charging fewer WUs, I’m sure you would be investigating it with much more urgency and attention. But when the issue consistently results in higher charges for users, it’s hard not to question Bubble’s priorities.
What we want is not the removal of WUs but more transparency and a fair, clear billing system. How can we be sure we are being charged correctly? How do we know there isn’t a bug that neither the support team nor users have identified yet? The ones who suffer from this are always us, the users. Postponing this issue makes it seem like Bubble isn’t truly concerned about its user base.
You know that the transition to WU-based billing cost Bubble thousands of users to the competition. I trust Bubble and want the platform to grow and strengthen its relationship with the community. But for that to happen, transparency must be a priority. If Bubble truly values its community, then listen and implement what we’re asking for: more clarity in WU charges.
Your explanations about WU billing are not documented, but they should be. If the team had put more effort into advanced tutorials and better WU billing analytics, we wouldn’t even be having this discussion. Why isn’t this transparency a priority yet?
I see one side of the WU argument to say why focus on the small differences with some WU calculations. For new users and testing small/early stage apps it barely makes a difference.
But on the flip side, as someone with an entrenched and growing application, I fully see the downside to this logic and applaud @boston85719 for pointing it out. For an app with scale, the 211% difference becomes quite large when speaking in absolute Workflow Units, so it comes with a real financial cost. Worst of all, it hinders a Bubble made app from fully taking advantage of typical SaaS scaling metrics the way traditional code does, where the tech stack costs stay relatively fixed for growing number of users (varies by app type of course). But that is a whole other WU discussion.
The focus of Bubble continually seems to be on the experience around creating new apps (new users & agencies seem to be there ICP). This is probably the right move for Bubble and their mission to democratize software development, but it unfortunately comes at the detriment for apps and developers in the scaling/growth stages as more and more it feels like an app will eventually ‘outgrow’ Bubble.
Not that I have a solution here, but as a founder with Bubble built SaaS these are constant thoughts/worries I have so I think it’s valuable for the Bubble team to see and possibly address if scaling apps are at all a priority for them.
I definitely lean on the first side for this, even on larger applications. Any discretions in WU have never been a blocker or even really noticed at all for any app development I’ve been on, and I can’t imagine how hard it would be to give an exact WU figure for every single action if the baseline varies. As @gaimed said other platforms just give an average which would also be fine imo.
The mobile builder and the AI builder are going to be pretty huge new features for bubble and I’m glad they’re focusing on those. If we’re not careful, catastrophizing about the impact of these honestly pretty small discretions in WU is surely going to damage the community far more than the actual WU issue itself… I see people commenting about WU ‘bugs’ on completely irrelevant threads sometimes, if I was just getting into bubble I’d think there was a major issue when there actually isn’t.
I suppose I should start a new thread, but here goes anyway…
I decided to devote part of my Friday “playtime” to trying to replicate @boston85719’s findings. I created a single workflow which creates three different things on button click…
This app is on a free plan and devoted exclusively to bug testing, so I don’t have access to real-time metrics. Real-time logs, however, are available, and here’s the output…
I explained it in an earlier post on this thread and explanation is a bit buried. I shared in the post the 30 minute video where I use my super snoop detective skills to unlock the mystery…and do note, the fact nobody from Bubble or on the forum have been able to explain, it was a mystery.
Each 0.62 you see in logs is not varied at all, and is what should be expected and has been. But it bewilderingly omits the additional 0.5 WUs that’s part of true cost. 0.02 is a rounding issue as individual data requests cost 0.015.
To run 3 actions, total cost 3.35-3.36 is 1.12 per action.
Run 5 actions, in charts first 4 are 0.62 each last in series is 1.12+(4x0.5)
Run 11 actions in series, first 10 are 0.62 and 11th is 1.12+(10x0.5)
Problem is Bubble in logs doesn’t show true cost of 1.12 in each action but show as part of total running the flow.
Bigger problem is on WU charts it shows all at 0.62 except last has all 0.5 charges omitted from each of the other actions attached to it.
Biggest problem, nobody at Bubble either knows that or could be bothered to explain that or improve UX to provide some helper text on WU charts to explain that.
Ah ok, so creating a thing encompasses the following three so-called “activity types”…
Activity
WU
Each thing written to or modified in the database
0.5
Running a server-side workflow action
0.6
Each thing returned from the database
0.015
Total
1.12 (rounded)
That actually makes perfect sense now. When you create a thing, you’re writing a thing to the DB, running a server-side action, and returning the thing that was just created to the workflow (so it can be referenced in subsequent actions as Result of step x).
Given that, I completely agree that a ton of confusion could be avoided with a clearer presentation of the data in the charts and logs.
Maybe it’s an oversight, or maybe there’s some technical reason that made the current implementation more “convenient” for the engineers - like maybe some data isn’t readily available until the WF has completed. Either way, I agree that the current UI makes it more difficult to pinpoint WU “hotspots”.
At least we have a better understanding of it now, so thanks for bringing this to everyone’s attention.
First of all @josh, want to thank you for taking the time to read and respond to our feedback. I thought you and Emmanuel had burnt out after the community response to WU but it’s clear you still care.
TBH, I’m over WU. This isn’t an existential threat to the product like AI tools are. Because of your “swamp”-like infrastructure it’s very hard to do it in a perfectly accurate fine-grained manner. It ultimately doesn’t matter because you can just adjust the pricing ratio as needed. Please don’t waste time on WU. You can make things a bit cheaper to appease the community and that will get you 95% of the way there with 10,000 hours of less work.
Let me tell you what the real issue is. You have three categories of products, frontend platforms (weweb, toddle, etc.), backend platforms (xano, supabase, etc.), and what I charitably refer to as “Slop Builders” (Bolt, Loveable, etc.). There is a secret fourth category which is actually just one product (replit). They may not be actively aware of it right now but all of them will eventually converge to the same point (Bubble). You guys had the early vision figured out a long time before anyone else, and you had a 10 year head start. But they are rapidly closing in due to AI. They are coming for your “Day 2.”
Right now when I write or edit an expression, I feel as if I’m being actively trolled, which is not a good feeling. If I need to change several regex expressions, for example, going into them one by one and manually changing each piece instead of being able to 1) find/replace or 2) write a prompt that changes everything feels like the platform is being hostile to me on purpose.
Let me remind you that you guys attempted to fix it with the “beta” expression composer. It didn’t blow up the platform, you guys just reverted it because it didn’t work. I understand the complexity involved with a highly abstracted language with a “middle layer” but I promise you this is not an intractable problem. They are writing software for landing rockets in other companies. Netflix serves hundreds of millions of customers impossible amounts of video content every night. Google and Facebook create their own languages (Go/React). You guys can do this. This is just my suspicion, but I think there is a talent issue. You guys are losing out on hiring the cracked engineers that are instead flocking to Tesla, Spacex, OpenAI, Google, etc. You need to basically offer extortion amounts of money like OpenAI do for their top engineers to get this talent. It just takes one 10x or 100x engineer. You guys raised a 100M round not too long ago, it should be possible to attract someone of this caliber.
If you guys can’t do it, then open up the middle layer of the language like @MattN has suggested and let us just use chatGPT or whatever the latest best model is to write straight into the JSON file. I know it goes against your philosophy but I don’t think there is another solution at this point.
This is the bare minimum to bring no-code in line with code. Right now they have the luxury of being able to generate and edit, and we’re stuck with primitive editing. There is even one guy on X using chatGPT’s Operator to automatically use Bubble, which is just reaching Inception layers of abstraction.
It just sucks that I’m able to generate an awesome design in OpenAI’s Canvas or Claude’s Artifacts, but then I have to do the “homework” of rebuilding it manually in Bubble. I hope you can understand my frustration. Thanks again for engaging with the community, we just want to see you guys succeed.
This is why they need to trust the community more…leave it up to the community, it is more than capable of adding on top of Bubble. Bubble just needs to keep what they have now reliable, add in some performance improvements.
Sorry to add to the confusion but would love to get to the bottom of this so I can explain workload properly to my students.
Today creating an empty thing (no fields set) costs me 1.62 WU.
There is an Individual Data Request activity logged at the same time as the create action. So I believe the ‘Each thing returned from the database’ (an mget request at the time of creation) isn’t part of what I’m seeing under the Workflow activity.
The result you got is exactly 0.5 WU (not 0.52) different from the calculation I depicted here, which is exactly the difference I noted in this post between logged in / out status. And as has been mentioned, privacy rules and other factors can impact WU as well.
More importantly, however, as Josh has stated, the metrics aren’t designed to enable one to precisely pinpoint what goes in to the aggregate WU value for a given WF, because the internal state of Bubble’s infrastructure factors into it.
