What’s your current WU usage? If you’re high capacity it’s likely you’ll be high WU usage.
DDOS is a huge concern for one my clients who works in the political space that is filled with bad actors.
What did your capacity look like during the idle period and spikes?
I managed to identify a process that was consuming a significant number of WU, and fortunately, in my case, removing it didn’t have a substantial impact on my app’s functionality. Before the optimization and under the original proposed pricing plan, my 30-day WU reached nearly 10 million. Based on my chart today, my daily WU has plummeted to just 20k. To elaborate, whenever someone on my team complained about speed, my go-to solution was to increase the capacity. However, there’s a possibility that the extra capacity wasn’t helping much, and to be honest, I rarely noticed a substantial difference after adding more capacity.
@Josh, thanks for this thorough and thoughtful response to some of the concerns and suggestions brought by other community members. This is reassuring and refreshing after feeling so abandoned by Bubble leadership over the past week.
Does Bubble have any intention to allow code export for large or enterprise-level Bubble apps?
My response on this topic is one of the most liked responses to your original post, so I was surprised you didn’t address it. I’m hoping that a lack of a “no” means this is something you guys are at least discussing.
Some additional thoughts/ideas/feedback on this topic:
We do not want to have to leave Bubble. We want to continue to operate and build in the Bubble ecosystem, so please don’t write me off (and others that feel the same way about code export) as “not being your customers.” We are your customers, who want to stay with Bubble for the long run as we scale our businesses, but we need the ability to export and backup our source code for Bubble to be viable long-term.
The ability to export our code translates to millions of dollars difference in our valuation as a company and dramatically affects our ability to exit. As I covered in my response in one of the earlier threads on this pricing, we just had a $10 million exit opportunity fall through because of Bubble and the lack of code export.
Lack of code export substantially impacts our ability to raise capital. Yes, I know about this article, and it has some great points, but the conversation with investors always comes back to the ownership of the code. This may not have been as much of an issue a few years ago, but now that investors have become educated about no-code and its pros/cons, this is a significant concern for any smart investor.
If Bubble wins when we win (especially with this new pricing structure), then does it not make sense to empower companies in your ecosystem to maximize valuation and fundraising ability? Hamstringing your users on valuation and fundraising potential because you’re worried they’ll take their code and go (which isn’t actually why we want the code) doesn’t help us or Bubble.
With so many Bubble alternatives now allowing code export, I expect this will become a significant factor in deciding which no-code platform to use for a project, especially for educated enterprise-level buyers. Does Bubble not wish to be competitive in this segment of the market?
Looking forward to some kind of communication on Bubble’s intention here.
Capacity does not increase speed, it just increases how many concurrent users / how much concurrent work your servers can handle.
The only scenario where your app gets quicker with more capacity is if you are being throttled. If you get throttled then page loads will be slower and workflows fail. If you have more capacity you might not get throttled.
If you are not being throttled then capacity does not increase speed.
@aj11 Would a similar question be, “How much will Bubble charge to allow users to export their code?” That ability is a major value-add. Do you imagine Bubble being able to make an additional margin off of it?
Not sure I understand your question properly?
I started a new thread dedicated to discussing the need/rational for code export from Bubble.
As well as wondering if WU’s will roll over or build up if unused?
I also wonder if there is a place for “non premium WUs” for batch processes during off-peak times that are charged at a lower rate… like electricity at night?
I’m also wondering if there are options for some kind of basic fall back performance / throttled app performance if WUs run out - vs elastic prices or switching apps off.
As asked a few times, code export reduces the risk of building on Bubble. So I’d love to understand intentions around this too? For example, my gist is these prices are better, but, WeWeb + Xano may still be much better value for more scalable applications and feature less lock-in.
Sorry, I meant if you could screenshot your capacity usage during the fake DDoS to compare how capacity is measured vs how WUs are measured.
Well, folks, during this time I’ve already rebuilt my entire system using FlutterFlow. It’s impossible with this new policy of bubble 's pricing. It’s a great tool, but being locked into a company that can change overnight without the possibility of taking your code and hosting it elsewhere is just not feasible.
How do you deal with data scrapers…octoparse, screaming frog, scrapebox to name a tiny few? As soon as you have data they come to take it… I know I use them.
Maybe logged in vs non logged in WU ?
A simple sports app which allows users to watch videos, read several articles and gain XP. Most of consumption is due to leaderboard (after watching video, user gains experience and can see how they progress among other users). App itself is free of charge for the users, customer pays 29$/month, but based on new pricing - they’ll be surprised…
@stuart4 No idea, my web dev IQ is negative
@tirlikas.m WUs were re-weighted starting yesterday morning so after that it will be lower like that last bar on the graph
Specifically in regards to the adjustments to WU usage, I’m seeing the usage for my app roughly cut in half today, maybe even down 2/3rds. We were using 110 million per month, but I expect that will come down closer to 35-40 million.
I have some API polling going on in my app’s backend that accounts for half of that usage, so with a few days work to migrate that to Xano, I can have my usage down to costing roughly 2x what I’m currently paying on the legacy pricing, which is palpable if still a bit excessive.
I still think API calls seem a bit overpriced, but overall I’m satisfied with the adjustments for as long as we remain with Bubble.
@toduffy I imagine that due to the variety of Bubble app user locations and use cases, usage stays fairly unpredictable. It would have to be some kind of auction system for this to work and dynamically adjust based on the overall load on Bubble servers, which is both technically challenging and more uncertain for users. Interesting idea though.
Oh, got you! Good idea. Will post as an edit when I’m back on my computer!
Everyone is amazed by the decrease in WU, but I still don’t get a point in their strategy. Right now, blessed are the ones who have developed several apps, know what they did, how they developed, have a real usage on their app and what are the numbers.
Still, such approach blocks NPD at least from the newcomers or those who have 1-2 apps in their portfolio or even those who haven’t developed/used particular features in their apps, because who the hells knows what the outcome will be? How to sell the product when you don’t know the running costs after development of an internal tool? Who will take on development and testing costs?
It sounds like Bubble needs an IKEA planner for their app where people could play with various options. Otherwise, only larger agencies and big portfolio freelancers will remain.
@josh Thanks for the additional details. I re-read my original comment and just wanted to give a bit more context to my concerns.
I’m building a public-facing web app that is free and to work properly, I will encourage users to actively open/edit & save recipes onto their accounts. Loading a single recipe right now (after the Bubble WU changes) is around 4WU. Editing/saving a recipe is around 21WU. My dream scenario is around 30K users/day . Assuming each user loads 1 recipe, and edits that 1 recipe, I’m still looking at close to 20mil WU, which is where the plans cap out and require a custom plan- I’d be looking at around $1500/month, which I don’t think is even close to possible via ad revenue at these numbers. This just seems very very high for what I’m trying to offer users - it would be supported by 1 or 2 ads, but doing some simple math, the ad revenue would never make up for what the WU would cost to run this properly.
Looking through the tutorials, I see all kinds of examples of building similar free B2C sites, like ‘How to use Bubble to make your own version of Twitter’, for example. Seeing now how WU is calculated, I don’t even see how those examples given could be viable considering they’re also traditionally free & ad supported. I would encourage the Bubble team to go through the tutorials, and see what sort of WU is even required to start to understand where myself and others are coming from.
I feel there are several different approaches here for Bubble devs - there is the enterprise-level apps for internal teams, from which a certain IT cost for a CRM would be acceptable. The WUs are also largely calculatablye as you generally know how many employees are accessing on a given day. Similarly a website that caters to high-end clients paying a high amount to interface with the site. But the approach I’m referring to is the ‘let me build a tool to help the public’. For example, a website with a simple calculator to show 401K returns. At a certain point, the web traffic of a successful app launch becomes unviable considering the high cost of WUs. This is why I’m still requesting a further audit of the current weight of WU counts, OR an increase in the WUs available on the various plans.
Addressing @gaurav ’s questions about legacy plans and features.
When we introduce new features, some may be on the new plans only, some may apply to all plans and free applications. There is not hard rule here and we make these decisions carefully on a case by case basis. What I’ll say is that usually, improvements to something that is already available tends to be rolled out to all apps, regardless of their plan. For instance, lower latency and faster page load are improvements that would likely be rolled out to all apps. New capabilities are more likely to be rolled out on new plans. But again, no hard rule here.
I don’t think the May 1 date is crucial for deciding whether to migrate. You can migrate to new plans any time after May 1, so if you want to get on a new plan to get a new feature you can do so whenever suits you. What you need to decide by May 1 is whether you want to get to a Personal, Professional or Production plan, and the features set is defined today and won’t change (relatively to each other). In other words, if we were to only add a feature on certain plans, it would be on new plans only, so the difference between professional and production won’t change.
The other thing you can decide before May 1 is the idea of going to a yearly billing cycle to keep the current price, and not the one with a 10% increase next month. Whether you do this or not doesn’t change the ability to migrate to new plans after May 1, you’ll just stay on the same billing cycle and your plans will be prorated, like it’s done today.
Hope this helps clarifying things, I know the concepts of new plans, new metric, legacy, etc. can be confusing.