Is Your Bubble App Secretly Bleeding Money? (How We Cut Workflow Costs by 70%)

Is your Bubble app secretly draining your wallet while you sleep? I've literally audited hundreds of Bubble applications and I can tell you right now, most Bubble developers are hemorrhaging workflow units without even knowing it. But here's the thing, I'm going to show you the exact system we use at ratio.dev to cut workflow consumption by up to 70% and take back control of your Bubble bills. My name is Dennis H. Lewis from ratio.dev. I've been in the tech industry for almost 40 years and we've built countless Bubble applications that serve thousands of users every day. And today I'm pulling back the curtain on our workflow optimization process, the stuff that separates the pros from everyone else bleeding money. So here's the thing. Bubble gives you this incredibly powerful visual workflow builder, but they charge you every single time those workflows run. It's like having a Ferrari with a meter that charges you per revolution of the engine. And, you know, let's start from the beginning and work through this. What are Workflow Units. And the first thing you need to know is that Workflow represents the server resources needed to host, run, and scale apps built on Bubble. It aggregates how much server resources is needed for different processes. And the amount of Workflow an app consumes is measured in what is called Workflow Units. So let me start with a story that changed everything for me. A few years back, we had a client, a SaaS founder, came to us in a panic. His app was working beautifully. Users loved it, but his bubble bill had gone from $300 a month to $2,400 almost overnight. He didn't change anything major, just had more users. But here's what he didn't understand. Every action in your workflow, every database search, every API call, every make changes to a thing, that's a workflow unit being consumed. And think of them like electricity for your app. Every time something happens, a user clicks a button, a scheduled workflow fires. A database trigger activates your turning on lights. And if you leave too many lights on, suddenly your electric bill hits the roof. And if you're in Texas, then you know what, how dangerous that can be. Now Bubble measures this in something called capacity, which represents your app's workload. But here's what most people miss. Not all actions cost the same. So let's jump in here and actually look at the different types of— here are the two. This is straight from Bubbles documentation. Here are the activity types that are, you know, and how much they're costing you. So every time a page is loaded, that's 0.15 workflow units. Every call to a server-side plugin action is 0.2. Every millisecond spent executing a server-side plugin action, 0.0005. Not that big of a deal. And you can go through here. Database. Okay. So every time you perform a database search. Okay. And that is using a, do a search for, that's 0.3 workflow units. And then every character of data returned has a little cost. It's minimal, but it's there. Everything that every element, every row that's returned from the database also has a charge of 0.015. So a lookup for a specific item. So that is when you go by its unique ID or your, you know, current user's company. You know, you go down the change of the chain of, you know, in your database structure. Okay. Well, that is also going to cost you a little bit. Everything that every row that you bring back, every character has a cost to it. So these are all database costs. Every time you write or, you know, every update is half of a workflow unit. So, you know, and this isn't You know, these are, these are going to slowly add up. The backend and the API. So every backend database trigger event, that's 0.05. Okay. It's not much, but it does. Running a server-side workflow action. So, you know, schedule a backend workflow, 0.6. Adding a new item to the API workflow scheduler, 0.1. So these are sort of all of the things that, that are going to be Summing up to consume workflow units. So, you know, display of data, just, you know, putting some out there that barely does anything, but you know, hey, if you do a search for with no constraints that pulls in 10,000 database rows, it's like kind of like running your air conditioner with all the windows open. Okay. That's not a great thing. So with this, Let's, you know, first tip, unconstrained database searches. Okay. I don't, I can't tell you how often this, this comes up. You know, you pull up someone's Bubble app and you find that they're doing a search for users with no restraints. That's pulling in your entire user table every single time. And then, you know, that, that's just poor practice. So, you know, and that, that can be solved as simply as putting in the right privacy rules so that, you know, because privacy rules run before your search. So, you know, all of these things add up significantly. So, you know, I had, I saw this one in one audit I was doing, this page was loading 847 users when it only needed to show 10, and they were just burning through workflow units. But here's the fix that nobody talks about, you know, move all that data into the backend, create an API workflow that processes only what you need, and then just return those results. So we call database caching. So that is a pro tip and that it's, it's a little bit harder to implement. It's not as simple as just going in the Bubble Builder and saying doing a search for, but it gives you a lot more granular control. You can control how much data is being pulled back. You can, you know, how many rows are being pulled back. You can, you can, you can really hone in and tighten down. All right. Another vampire, recursive workflows. Okay. So, you know, I know that they're really powerful. We use them a lot, but you know, they are That is every time it recurses through that scheduling itself again, that's costing you. So, you know, if you're doing this, you know, over 50 users, that's fine. But if you do it over 5,000, you're going to, it's going to cost you a little bit. So the, you know, just use Schedule API workflow on a list. So that's just one, one call instead of, you know, having to do it over recursively. Now I know there are use cases where it's better to use recursion because you have more control over what you can log every, every action as it happens. And you can, you know, you can keep track and make sure that everything completes correctly. So, there are use cases, but the idea of this video is how can you, what are some of the low-hanging fruits that we can take to improve your use? Your, sometimes database triggers can just go wild and, you know, they're, they're very powerful, but they can be dangerous. You know, I see somebody setting up a trigger for their user table to update a related table, sounds good. But then that trigger fires on every field change when, you know, even when it's, you know, just somebody updated their profile picture or something. So, you know, just, you kind of be careful with how you do these so that they, they only fire when it actually makes sense. So add conditions to those triggers. So use the only when so that it really hones in. So the next thing I want to, I want to show you is, okay, but how do we, how do we know what's going on? So I'm going to just come into just an application here and I'm going to go in and what you're going to do is you're going to go to logs and you can see here and here you can— this is actually showing us for last month and this isn't a huge application, it's just mostly in testing right now. But you can come down here and drill in to where things are going. So here you can see I've got 38%, 39% is fetching data. 29% is data-trigger workflows. So that's maybe something I need to look at. Scheduled workflows here is about 21%. Just normal workflows, that's about 9%. So you can see here the breakdown. But then you can click on these, each one, and dig in here. So let me just make this a little bigger for you, and then you can dig in and see which ones are they. So fetching data, you know, this is a just general search. These are aggregate searches. So these are when you're doing group bys. So here, I just want to look at the search and I, now I can go in and look for each one of these and I can say, okay, well, look, I've got a big one here. Which is search for tasks. Maybe I need to optimize this search and I would go here and I can click and it will take me directly to that search and I can look and see, can I improve the constraints? Can I make it— maybe this is— in this case, I believe it's just because this application uses this search a lot, which, you know, hey, I'm not saying to make your application nonfunctional, but this allows you to really dig in. So I'm going to show you a different example on a different app. And you can see how the results are going to be very different. And here I have my number one thing are scheduled workflows. And so it's taking 28% and I can dig in here and look at these and I can see which schedule was score article, refresh, you know, the comments here. These are, you know, I can see, and these have already been, but the idea here is if you, you know, look at really dig into the big ones, but If you see them kind of pretty evenly spread out, you're probably doing okay. So go back to overall here and maybe I want to look at the API calls. And here we use API calls a lot because we are using database caching. And so you can see here, the number one is DB1 art single. This is pulling one single article from a blog post. Okay. Well, this is a blogging platform, so that makes sense. But if, you know, I have some extra time, I might go in and look at this and see, can I, how often is is it refreshing the cache? Maybe I can make it just extend that cache longer and bring that usage down. And you can see these over time by over dates as well. I can go back in and here I'm looking at my graph is pretty balanced, so it's probably not that bad. I mean, this application, we've put a lot of effort into it, but fetching data here. Okay, well, now look, this is a case where something It's all going into search. Let's dig into that. Boom. Okay, here we have search for tags, each item's tag. Well, this looks to me like a perfect case that something probably needs to be optimized because this one little search, and if I click here, I can, I can be taken to it, is consuming over half of all of the workflow unit consumption for searches. So by doing this, you can really dive deep into your application and figure out where your consumption is coming. Another thing I want to show you is the official Bubble checklist. So here you come in and they will, they will, you know, it comes in and it tells you what to look at. So you're on your page loads, you know, remove pages loaded events or replace them by another event that doesn't repeat as often. So good thing that repetition, use conditions to assure, to ensure that go to page only Runs once. Searches. Okay. Complexity. Avoid advanced filters. So this is, you know, these will consume a lot of workflow units. They will also generate a lot because it's going to move all of the search results to the browser. So that's moving a lot of data to the browser. That's a lot of consumption. Sometimes you need to use advanced filters, but be cautious with it. Volume. Be mindful of structured and unstructured data. So, You know, use your privacy rules to, you know, if you've got big fields that aren't really necessary in the browser, well, get rid of them from your privacy rules. And for most users, and that will lower your consumption of on-searches. Workflows and actions, both the number of actions, the complexity, the frequency that they're running. And then, you know, work— make changes to a list of things is sometimes necessary, but, uh, you know, it consumes more workflow than a single thing. So, you know, be careful. Backend workflows and API. Okay. Here's some, some suggestions straight from, you know, a Bubble recommends. So you can find this all in the, in the official Bubble documentation. And now, you know, I think with this, you can see that it's a process. It isn't just something that you do once and you check it off on your checklist and you're done. Workflow optimization is an ongoing process. You need to babysit your Bubble application and look at what's going on in your application as it evolves. Because sometimes you'll release a new feature and you won't realize that that feature is, you know, consuming a lot of workflow units. And so the way you find that out is by looking into those stats and it'll, it'll slowly come up and you'll see, and you'll say, oh, okay, I need to, I need to go in there and look. So it's not a one. You know, one-shot deal. It is something that you're going to need to be aware of. Another thing you'll notice is that Bubble will send you emails when your workflow units consumption goes up. And it's a double-edged sword because at the beginning you may have, you start off with almost no usage of your app. And so you get one or two users and suddenly it's double, or you'll get an email saying, oh, your usage has doubled. Well, it's probably not a big deal because it was double, you know, almost nothing. Well, 2 times almost nothing is, you know, basically almost nothing. But as your application gets more inertia and you get more users, then those warnings become more important. So that if you get them frequently, that's a good sign that you probably need to go in and check and see what's going on in your application. So I get it. Workflow unit management isn't the sexiest topic in the world, but here's the reality. If you don't control this, it will kill your business or it will definitely go straight to your bottom line. And I've seen this happen. Apps that were working beautiful, users love them, but the founder can't scale because the Bubble bills keep going up. And one thing is, you know, about this is that it requires experience to get this right. So if you need some help with your Bubble application, feel free to reach out to us at ratio.dev. We will be more than happy to audit your application, to roll up our sleeves and dig into what's going on, give you a report and just say, hey, these are probably the things that I would look at first. These are the workflows. These are the things, or we can go in and help you fix them. Them too. So, we're definitely available for you. Remember the 5 things most important: eliminate the redundant database searches, so use custom events and reference the results; move heavy lifting to the backend, that will consume less; cache as much data as you can when it's appropriate. I mean, if you need real-time data, then you can't be caching it; monitor your logs frequently and your stats; And then fix synchronicity issues. Make sure your workflows run in the order that you're expecting them to run in, because sometimes that can create loops and stuff that goes on there. So if you found this video helpful, I definitely recommend that you go to ratio.dev or use the link below in the description and sign up for our free no-code resource center. Just give us your name and your email. You get all sorts of access to vetted plugins, to templates, to podcast episodes, to how-to videos. And we update it weekly. So that's a great free resource we have for you. Feel free to reach out if you want us to audit your app. Thank you very much for watching this video. Give it a like and subscribe if you've enjoyed it. Subscriptions just mean the world to us. We really appreciate them. And I'll see you in the next video.