An Update to Workload, Plus More Transparent Calculations

[josh]

Hi all, another round of question answering:

@christo1

The trial should not charge us for WU’s, but be more customer focussed so we can experience the performance improvements ourselves in order to gain confidence regarding the new plan performance before committing entirely.

Just to set expectations so that no one is disappointed, performance on the workload-based plans will initially feel like performance on the capacity-based plans, but with more capacity. If adding a temporary capacity boost to your app improves performance, then the new plans will be faster. If you do not notice any difference from adding a temporary capacity boost, it is unlikely you will see immediate improvements on the new plans. That said, we will be working hard to continue making the platform faster and faster!

@mike7

I think having cron jobs / future scheduled workflows consume more WU makes total sense as you won’t be doing that for the majority of your app’s logic, but it would be nice to still be able to use the backend to organize.

Best practices here remain the same as always. There is some WU overhead for scheduling a backend workflow, just as there is some capacity overhead in the old system, but that overhead is not prohibitive, and I would prioritize security and clear organization over squeezing every last ounce of workload out of your app. One thing I want to emphasize is that for all the talk of optimization, for most apps we look at, there tends to be a couple of hot spots (workload-intensive features) that are worth optimizing to make a major difference in WU consumption, but the rest of the app can generally be left as-is. The best practices for minimizing WU usage line up pretty well with best practices for making apps high performance, so don’t feel like you need to throw out everything you already know about building well on Bubble.

@kossiorek1

I wonder if, apart from the message about WU consumption, I will be able to set the maximum monthly WU level for my application, at which the application, for example, will call a 404 page. Such a solution would reduce the financial risk for the bubblers. e.g. if I have 175k Wu to use, I could set, for example, max 250, knowing that I do not want to pay more without my knowledge, after exceeding and checking, I could change it to, for example, 300k to restart the operation, etc. This will reduce the risk

This is a good feature suggestion and I will discuss with the team! We have an ongoing conversation about what the most important tools will be to help users manage workload. As a reminder, when we release the new plans there will be the ability to turn off overages, which is similar to what you are describing but a bit more limited (you would have to upgrade to a higher WU tier to re-enable your app).

@boston85719

What impact on WFUs are expected to be incurred when we trigger a custom workflow from a page or in the backend, as well as schedule a custom workflow, trigger a custom workflow when data changes or trigger a custom workflow from a reusable element. Do these types of actions have impact on the WFU consumption?

There’s nothing “special” in terms of WU from custom workflows – the general rule is that the more actions you run (excluding client-only actions), the more WU you will consume. Organizing into custom workflows is still recommended.

@boston85719

Additionally, could there be a feature addition of allowing a custom workflow trigger to trigger itself, much like we do with recursive backend workflows? I understand it is on the agenda to create a better way to process lists, which would eliminate/reduce the need for recursive backend workflows, so perhaps the request from me would be to ensure the actions/features that make recursive backend workflows unnecessary for those to be available within custom workflow triggers or some other area of the page workflow actions.

Yes, this is in line with how we are thinking about better list processing!

@justin.hume

When the url parameter on a single page app changes, all “on page load” workflows will run. If you have a workflow that say, updates the current user’s last active date field (like it does in canvas), that would run each time the page’s url changed. So if you have a single page app where you need to change the page’s thing often, that would run a lot and cost a lot of WU. I suggest allowing us to specify an on page load trigger in a similar fashion as the on condition workflow’s first time and every time. Perhaps something like a “full page load only” checkbox.

Yes, fair point. I think there are generally ways of working around this with our current set of features (you could use an element state to track if a workflow has been run yet or not, for instance), but I will pass along the feature suggestion.

@justin.hume

A massive vulnerability is the auto-clicker (or any variation of what I will describe). Let’s say that you have a plugin demo app on the starter plan. A jealous competitor would only need to use an auto clicker on a button that creates a new thing to essentially shut down the app for a month or cost you thousands and thousands of dollars – or at least a headache in trying to contact support. And there is nothing that we could do about it

Now that each of our users are directly tied to a cost to us, we need tools to a) limit bad actors (such as setting a daily WU limit for users) b) see the WU cost that each of our users has accumulated in any given timeframe and c) be notified of unusual activity, such as more than 10% of our WU used within one hour. Getting notified on May 2 that our app is 75% of the way through our allotted WU is not good enough. We need pricing certainty, and the simple 75% WU notification and allow WU overage toggle that you are offering are not sufficient to run an actual business.

Yes, this is definitely on our radar, and is a concern a lot of you are echoing. A couple updates and thoughts on this:

• As mentioned above, we are working on various behind-the-scenes DDoS and abuse mitigations. We don’t share the details of our security mitigations publicly, but definitely something we care about
• We are also having internal discussions about what user-facing features we would want to give you more direct control of your security posture
• It bears repeating: we have your back, and we we will be happy to waive charges if you do get burned by this
• This problem is not unique to Bubble; any SaaS that charges based on usage has this vulnerability. In practice, while attacks like this do happen in the wild, it is not that common, because in most jurisdictions, DDoS and other cyber attacks are felonies that carry prison time, so you have to be a motivated attacker and very confident you can cover your tracks to go after a competitor like this. Most cyberattacks are initiated by professional criminals with the goal of making a profit, not putting a company out of business, or are launched by people with specific ideological axes to grind.
• For extreme cases (there was mention further down thread of a politically-oriented app, which really might get sufficiently angry / motivated attackers), keep in mind that for some amount of workload overhead, you can build protections yourself using Bubble’s features. For instance, you could maintain a count on the user of how many times they’ve ran a particular workflow, and exit the workflow early / redirect them out of the app. Not bulletproof, but it’s an additional layer under any features we build and under our general platform protections. I would not recommend investing in this though unless you have specific reason to be afraid of these scenarios, as opposed to general best practices.

@gaimed

Could we get cacheable urls for data requests? So we do something like search (it generates a unique url with the hash of the payload), add :cache. It adds cache headers to the returned data and its cached by cloudflare cdn and browser.

Very interesting idea! We are actively working on page load performance, and we may end up building something that works like this, but out-of-the-box (no need to opt-in).

@darlington

Even this new pricing is misleading. I ran a simple workflow to change a yes/no field of a user, then toggle a button after. That consumed 1.10 WU even though modifying database should just cost 0.5 WU. Where’s the extra 0.6 WU coming from… This was this morning

Each action (excluding client-only actions) consumes 0.6 workload, which probably explains most of the discrepancy. I agree that reading this chart, and then trying to calculate how much WU something costs, is hard; the main reason we shared the chart is for transparency, not because we expect it to be that useful in practice. In practice, see our roadmap for tools for investigating and viewing WU, which is how we would recommend profiling apps’ workload usage.

@NigelG

This is an app that was being polled for database changes by Whalesync. Mostly there were no changes.

Polling is generally going to be expensive, yes. That’s one technique that admittedly the new pricing will make much less appealing. The Whalesync team mentioned to me that they would love us to invest in outbound webhooks that 3rd party providers like them could automatically customize, and utilize instead of polling. (You can build outbound webhooks in Bubble, but a 3rd party like Whalesync can’t automatically configure them). It’s on our list.

@asked111

Suggestion… A lot of people, myself included, seem to track a users LAST ACTIVE status/time, by writing on to the database on pageload.

Obviously we’d now want to minimise this kind of thing, so maybe bubble would be so kind as to make “last active” function as a built in bubble nicety?

Great suggestion, will share with the team. I think from a technical standpoint, we should be able to do this fairly cheaply by utilizing our login sessions and periodically persisting it in an efficient way.

@martin9

One detail I can’t find anywhere, for the Workload Tiers do unused WUs get rolled over to next month’s allowance? I’m sure they do as overages are charged at a very similar rate but couldn’t find confirmation anywhere.

They do not roll over. The concept is that buying a tier is pre-committing to a certain volume per month; that’s valuable to us, so we offer volume discounts, both on the price of the tier and subsequent overages.

@fredcascas

There is one thing that is still bothering me. What would this “Others” be on the graph, where I click and it doesn’t go anywhere. It’s consuming and I can’t identify what it would be.
@josh

We show the top 20 contributors to workload as individual slices in the pie chart, and then group the remaining ones under “Other”. This is for pie chart performance: if an app has, say, 2000 searches, and we tried to display 2000 slices in the pie chart, it would take forever to load and be very difficult to read. Based on this image, where Other looks like about a 1/3 of the workload, it means that the top 20 searches in your app take up about 2/3s of the workload, and the remaining searches take the other 1/3. That’s good – it means your searches are probably reasonably well-optimized, because there is no clear outlier eating all your WU.

All that said, you are not the only person to have been confused by the “Other” slice, and there is internal discussion on the team right now about the clearest way to handle this.

@mack2580

Can you guys make a better way to call API data to the backend with a loop system this is what is eating up all my WF units. Xano has a pretty fantastic system for doing this. I thought about going that route months ago when I started looking at rebuilding my database but wanted to stay all in Bubble.

Yes! Not sure what we will build will look exactly like Xano’s solution, but definitely on our agenda this year.

@edd

• Add WU count to the runtime debug and page inspect modes as well, so we can see how much it costs to load a page and render specific elements and evaluate conditions within it?
• (I hesitate to suggest this for fear of making the logs “truly impossible” to read vs. the current state of being “very difficult” to read) Add any action that impacts WU usage to the logs. Page loads. Searches. Data retrieval. Whatever else you’re charging for.

The debugger idea is definitely something we are discussing internally! I am less of a fan of the logs idea, for the reason you mention – risk of making it unusable. (We do have cleaning up the Logs tab and making it much more usable on our list, but it’s a bigger project and not likely to happen in the super near-term)

@MarkusBoostedApp

Is it accepted on a strategic level that some apps are forced out because they don’t fit into new pricing model?

There’s been some chat on this thread about “b2c” apps becoming cost-prohibitive. b2c is a vast category and covers a ton of business models: it is definitely not true that b2c apps will be driven off Bubble en-masse. In our investigations, the difficulty of making an app sustainable on our workload-based plans generally has less to do with the business model, and more to do with the specific features being used by the app (see my note on polling, above).

We are aware that there are some apps out there that would require extensive rebuilding to be viable on the new plans. There is no way to switch from feature-based to usage-based pricing in a sustainable way, regardless of the metric we choose, and have this not be the case. If you are one of the people in this position, I highly, highly suggest you reach out to us at support@bubble.io to discuss what we can do to help. Our team has been sharing stories on our internal Slack today about users who have emailed us convinced that workload-based pricing will put them out of business, and after talking to someone on the team, letting us know that they now see a path forward. There is a lot we can do on a 1:1 basis to help understand your app, your feature usage, and business model (or lack of a business model if you are doing this for non-profit purposes), and make suggestions.

@aj11

Does Bubble have any intention to allow code export for large or enterprise-level Bubble apps?

We don’t like that our users feel locked in to Bubble. We’ve always strived to make it an open platform, which is why the feedback that we got about API calls feeling too expensive really hit home for us, and prompted us to re-think their workload consumption.

There’s been some discussion on the forum about a community-built export tool that converts our bubble JSON files into code in a different programming framework. We are rooting for that effort to succeed, and if we feel that the end-result is high-quality, we would be happy to help promote it.

That said, from day 1, we have designed Bubble as a platform, not a code-generator tool. Every technical and product decision we have made has been with that in mind, and a lot of the power of Bubble comes from the fact that apps are fully-integrated with their runtime environment, debugging environment, and ecosystem. We don’t have app code sitting around in a format that you could hand off to a software developer and have them run with it: what we have is exactly what you see when you click the export button in the editor. So it would be a major project to build an export feature, and a major commitment to maintain it as we continue to modify the Bubble language and add new features.

We understand the tradeoffs of being on a platform that is not easy to migrate off of, and I’m sorry you lost an acquisition opportunity over it. I would love to build a world where acquirers and funders view being on Bubble as an asset, not a liability, and I have seen a lot of progress in that direction over the last couple of years as we continue to invest in Bubble’s platform and have more and more success stories of apps built on us that have raised millions of dollars in funding, been acquired, and created sustainable businesses.

For that reason, we do not currently have building an export tool on our roadmap, and are unlikely to add it in the next 1-2 years. When push comes to shove, we need to invest our limited engineering resources making Bubble great for the people who stay on us.

@tirlikas.m

How to sell the product when you don’t know the running costs after development of an internal tool?

I know a lot of freelancers and agencies have been wondering how to sell their customers on the new workload plans. We want you all to succeed, and are in conversations with agencies about what materials would be the most helpful to enable them to close deals. We will have more updates on this, but one thing I would suggest thinking about is “How did you sell the old capacity-based plans?” In some ways, the challenge is very similar: capacity is no easier to predict than workload, and if an app regularly hits capacity ceilings they need to upgrade and pay more money. Freelancers and agencies have successfully navigated this challenge, and with our help we expect to be able to navigate the new plans as well. With yesterday’s adjustments to WU consumption, for the majority of apps, you are likely to be able to find a reasonable plan price where the customer has enough bundled WU that they do not need to worry about overages on a day-to-day basis.

Thank you everyone for all the questions, and a big thank you to those helping others figure out how to best design their apps!