An Update to Workload, Plus More Transparent Calculations

@emmanuel thank you for your answer, again:

CRUD costs are too high making consumer apps not viable.

Is this on your radar?

3 Likes

@josh @emmanuel thanks fo responding. Good work :+1:

@emmanuel @josh can’t you guys push the new pricing to June 1st instead, giving us a bit room to see how our apps react, how we can optimise, and whether we’ll switch to new plan, or keep the legacy plan for now?

5 Likes

I know I have come out swinging a few times over methodology. I want to take a moment to highlight and acknowledge the very tough situation that Bubble is in, with respect to fair pricing, and maintaining a sustainable funding for base infrastructure:

  1. In both the practical sense and the theoretical sense using the instrumentation they have, logged event counts, it is impossible to create a pricing model that is both fair, and easy to understand. At a bare minimum to even implement an approximately fair regression model would require doing a Principal Component Analysis on the event rates per resource consumption to identify motifs of correlated events. Turning that into a price plan would require gaining user acceptance around not just one weight for each type of event, but rather a whole set of linear equations. Given the push back that we have witnessed this would be a daunting social undertaking.
  2. The base load on Bubble, that is the resource consumption simply to keep the lights on, setting aside what it takes to actually run an application, scales log-linearly O(N x log(N)) with the number of applications N. This is because the number of requests coming into Bubble scales linearly with the number of applications, while the effort to route a request scales with the logarithm of the number of applications. Some of that can be mitigated with divide and conquer services like Cloudfare, but that itself comes with an economic cost. The paradox Bubble faces is that, instead of being able to leverage economies of scale, growing substantially in the number of applications they host results in diminishing returns and escalating infrastructure costs.
4 Likes

I think this is only fair - given the incredibly confusing way this has all happened.
This gives people time to at least answer some of these questions vs rushing all decisions.
+1 for June 1st vs May 1st.

2 Likes

Hi all, another round of question answering:

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!

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.

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).

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.

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

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.

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.

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).

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.

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.

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.

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.

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.

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

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)

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.

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.

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!

27 Likes

IMO, this is still the wrong direction and wrong mechanism design.

Why?

  • Too complex. The most complex pricing system I’ve ever seen. It is completely overwhelming - i.e. overloads working memory - to just try to imagine the WU costs of calling an API, parsing the response, then allowing a user to edit that for a basic AI app.
  • Wrong incentive structures:
    – Bubble can increase profits by increasing granular charges over time for locked-in users. — If Bubble refactors underlying code, there is no incentive to pass savings onto users as this reduces revenue. All app users will want their bottleneck to be cheaper.
    – Giving users features to operate more efficient apps literally takes % points off Bubble’s revenues
    – Users are disincentivised from apps that get a high level of utilisation. Literally features may be culled if they cost to many WUs. This is all the wrong emotional basis for finding product market fit.
    Put together, if Bubble seeks to maximise profit growth for valuation, then over time, there is a need to increase revenue captured per app (currently locked-in) which is balanced against people switching because apps are too expensive. Bubble’s ideal user becomes a naïve wealthy nocoder who builds apps with high WUs and doesn’t mind paying.
    This is literally like a prisoners dilemma. Stakeholders are at odds. It is overwhelming complex. Motivations create a situation where Bubble has the wrong dynamics for nocoders to build the best software with excellent price basis relative to the market. I’ve already seen such a chorus of voices switching away, looking for alternatives, planning different nocode stacks. This feels like a Kodak moment.
  • This arbitrary pricing policy means Bubble is incentivised to create lock-in. Otherwise, predictable MRR decreases. But this will make it so many people will avoid Bubble because of the lock-in which isn’t equivalent to competitors.
    – Users can’t know and have no say in pricing in the future but they are locked-in.
    – The natural consequence is customer acquisition will get harder because this is an issue and everyone is advising each other and basically the word on the streets is very seriously think about non-bubble nocode platforms.
    – This also means, users can’t predict this will be competitive relative to other offerings. Bubble has a monopoly on hosting Bubble apps - so you can be sloppy in how you run things and still get revenue until the rift makes Bubble non-competitive.
    – It surely can’t be compute efficient to measure everything that happens at a micro-granular level. Surely this adds a 30% “instrumentation tax” to just provide services

By comparison:

  • WeWeb’s pricing is just measured in sessions. Their updated pricing is 50k sessions/app visits (no cap on page views or interactions) for $39/month plus whatever the backend costs. And they have code export on all yearly plans. This means, it is in WeWeb’s interests to architect efficient code. They profit from the delta between execution and sessions. 50k App sessions is easy to understand and think-in. I get this doesn’t include a full backend… but the incentive structure is aligned for stakeholders winning in the long term (WeWeb and Users). If WeWeb charges too much, users can just export code and circumvent them. Because they’re not touching the backend, scale of use is less of an issue… but a marketplace of backend service providers mean a functioning market - i.e. competitive vendors in a price elastic space. If Xano is 15% cheaper than a competitor backend, they’ll mop up all the business.

This means, WeWeb’s mechanism design is aligned with their users writing the best software, focusing on the task of winning, vs wasting 20% of efforts constantly optimising apps and weighing up everything based on WU costs. Over time, “Dynamics beat semantics” (Mark Burgess quote). You can’t win if you have the wrong dynamics.

I did all the analysis / tokenomics for a complex ecosystem pricing policy a few years ago - so my clarity here comes from doing the math on that. They are beating the market.

I’ll call what I see right now as nocode devs will be disadvantaged by the dynamics of this policy with Bubble… which means nocode devs that choose other platforms (with less technical debt) will en-aggregate have a competitive advantage. This is a kodak moment.

9 Likes

@josh please also just add a map expression to the existing :filter dialog. In addition to This item, This index and This list should also be exposed. This would solve for the vast majority of cases where people desire to loop over workflows and would be vastly more performant when possible.

12 Likes

That would be something! :map, :reduce, and :for each list operators that accept simplified javascript.

4 Likes

The worst thing about all of this - and that’s a high bar - is the very high frequency of the following response (phrased essentially in 1 of 2 ways): 1) ‘interesting point, we’ll look into it’, or 2) ‘yes, that would be a good feature, we’ll see if we can build it’.

Why is this bad? Because so many items receiving this response are not optional - they’re essential to make this work.

Yet Bubble:

  1. has a tried and true track record of promising things that take literally years to implement (decent responsive design), are implemented badly and have to be rolled back (versioning) or that never come (mobile, editor oveehaul). Will these new, promised things actually ever come?

  2. more to the point, Bubble will apparently be consumed for the next year and a half with building features… to make your billing work. How are you possibly going to build anything that matters for Bubble with this level of schmozzle around workunits, and with the level of action required on your end to actually make workunit transparency work?

Honestly, this may be the most ridiculous thing I think I’ve ever seen. It may well be that you work all of this out, but at what cost? I’ve rarely seen such needless angst, effort or waste.

9 Likes

I’ve shared my thoughts re pricing dynamics.

One of the things I absolutely commend you for is the sheer openess of the dialogue you’re allowing between people here.

This is in the right spirit. I’d like to see this kind of spirit of things win.

Thanks for the thoughtful response. I appreciate your willingness to address it.

2 Likes

Hello @emmanuel @josh ,

Thanks for replying. I’ll explain you why I think the May 1 date is so crucial for many of us.

We won’t be able to upgrade our legacy plan beyond May 1, that means that if we get more users after that date, our app dies or we’ll have to get into the new pricing which might end up killing it as well.

We are not sure yet that the new pricing will work for us and I think you shouldn’t be either, since you introduced changes of 90% magnitude on it just yesterday. You are assuming that it is ok, just as you assumed it wrongfully 1 week ago, when it was ≈ 10x overpriced in many aspects (comparing it to the new changes introduced yesterday).

If you give us a couple months more without restricting the possibility to upgrade legacy plans, we all can test more thoroughly this new pricing system (without risking the cost structure of businesses), and in your case, the market’s reaction towards it.

We would like you to have more time to find were else you might be wrong. Being mistaken is not bad, but you could reduce the potential negative consequences of being mistaken by just testing this new pricing for more time, before risking our cost structures.

This is are some key things that you don’t know yet:

How will this new pricing model will affect Bubble’s:

  • Conversion % and cost of acquiring new users.
  • Churn rate.

If you keep the May 1 deadline and our apps scale, we would be forced to scale into an almost untested pricing model (scale into uncertainty). I think it would be just reasonable enough for you to get all that data to support the new pricing model internally (no need to share those things to us). Just test how new users react to it, but don’t put in risk existing businesses before you know that. If the market rejects it you’ll know there is something wrong and no one would’ve been sacrificed for it.

If after a couple months without restricting upgrading legacy plans you keep this new pricing direction, we’ll know that the market has accepted it, it is fair against the industry standards and no one is getting heavily affected in negative terms.

Respectfully.

13 Likes

I already offer that in Floppy for folks who are that fancy (you write real JavaScript there, but the concept is exactly the same, and I don’t think I support reduce as it’s unlikely to get used much). These would just be normal Expression Builder expressions. Just like in :filter, @aaronsheldon.

3 Likes

In summary, test whatever changes you want with new users but please don’t risk the cost structures of our businesses before collecting the complete data to support that those changes are accepted by the market.

In this case, you are risking our cost structures because after May 1, we won’t be able to scale into anything that is not this new, partially tested model.

Thanks.

2 Likes

My question to you josh is this… Why deploy this kind of pricing structure when bubble mentions working on the capacity for users to host heir app in other aws centers without a dedicated plan?

Wouldn’t it just be SO MUCH easier for you guys to offer us to pay a monthly/hourly fee via aws, azure, etc to create our own instance of bubble? You keep the profit and stop wasting time on hosting and weird metrics… Orrrr, the other option would have been to release a new pricing scheme with a new hosting offer a little like xano where you get your own instance, replicated via kubernetes…

I don’t know… You mention (and I appreciate it) that you do not like seeing users feeling trapped in bubble… Well… I’m sorry but I dont feel like you’re doing anything to counter that… We like the product, but for some like me… The next 18 months are just a getaway plan if there’s no commitment or reassurance that this fiasco thing is not going to be repeated every year…

Thanks

5 Likes

Welp, with my first full day of re-weighted WUs under the belt:

It looks like this app could be run in Starter for $30-$40 per month or Growth on the base plan. Where’s the button?

Also, the WU reduction over previous system looks more on the order of 10X than previous estimate of 5X.

9 Likes

Thank you @josh for your attention and response. Now I understand the graph better.

Ya know, not everyone has stuck around. Here’s someone who got freaked the fuck out by the pricing changes (note they went from about 20 mill WUs per day to….who knows due to the scale… a few thousand today — just like me… the last part not the first part.):

Good job, Bubble!

@mikeloc, having had the last word you can lock and close the thread.

9 Likes

Thanks so much for all these details.

Would it be easy to add a counter to the user on how many WUs they used (in the last 24 hour, 7 days and 30 days)?

I could use that to bill end users or accounts. Or limit users to perform action if they reach a treshhold…

2 Likes