Yeah, it’s still absolutely wild that they charge WUs in dev mode.
Deactivating the issue reporter usually helps a lot , as it’s what takes most of the editor’s resources as the issue analysis is made browser-side.
Use the URL parameter &issues_off=true
What would be the benefit of making things consume less WU’s when that’s how you make your money?
The benefit would be that people do not leave 
& would start being positive about bubble again. I hope the devs have the foresight to realise this…
(And hey, if they ever want to pay themselves extra all they need to do is refresh all our webpages a few times, right joking, don’t get any ideas Josh)
Yes…there has been a few threads over past couple weeks related to this. The editor is full of issues. It is like wack-a-mole right now with them. Every day, it seems like every action I take there is a Bug in the editor. Impossible to spend the time to notify Bubble of every single one.
I appreciate the tip. I’ve used this trick before when I didn’t need the issue checker, but when making significant changes, we need to have it turned on, so it’s not a viable solution when making significant changes to your app, like changing how data is pulled in across multiple elements to optimize for usage.
I’m also having editor issues. Whenever I go to logs or workflows my elements pane stays up and makes the screen size all wonky. I have to drag over the elements pane to refix the screen. Very annoying.
I walked away from Bubble and this whole pricing fiasco MkII for one month hoping that when I return I would see reasonableness had prevailed and Bubble had reconsidered or reconfigured.
Looks like nothing has changed so I will be moving on a new platform and chalk this up to experience.
There are some people who helped me so much in the last year answering questions in this forum and I am incredibly grateful for their patience. Cheers to you guys.
Rather than just focusing on the high waist of time and expense with this Bubble experiment, @josh , I’m going to try and focus on the things that I learnt and the people who help me learn which will make my transition to a new platform easier and with confidence.
This entire fiasco I am certain has damaged the bubble brand, and irreversibly if it (almost certainly) goes ahead. And it was entirely avoidable. It’s a ham-fisted, tone-deaf approach that doesn’t give ANY respect to the customers using bubble, or the customers they have brought to the platform (e.g. agencies). Entrepreneurs do not have the cash to handle unpredictable costs, and bubble seems hell-bent on ensuring early failure of their customers’ businesses. MANY startups fail at some point, it seems as if bubble simply wants to capitalise on that fact by causing the failure at a time when a business is most vulnerable - while scaling up.
This factor, I suspect, is the biggest issue most of us have - the inability to CAP the price and have some form of predictability. Other platforms (e.g. backendless) offer a fixed base price, with certain limits that don’t break the app (in most cases) but might slow things down. Beyond these, you simply add function-specific packs to address the limit. This is predictable and similar to bubble’s original plans to some extent.
This whole fiasco has been instructive to me. Here’s my lessons learned:
- DIVERSIFY - don’t trust your success on a business that once promised it had your best interests at heart. They don’t. They are a corporation, and corporations exist for one reason - to make money, more often than not - to simply address shareholder expectations. Don’t put all your eggs in one basket in essence - bubble promised to be that basket, but they have proven to their customers that that basket is made of solid gold, and they now want it to be unobtanium-plated too.
- ADAPT - don’t build a business plan on an assumption of things remaining as they are forever. I’m sure many have made this mistake to some degree (myself included), but you need to have a backup plan. In this case, I have now created a plan B and C - neither of which have bubble as part of my future business. I don’t appreciate being stuffed around, so I’m out.
- TRUST - don’t trust what anyone in business promises, no matter how hard you want to believe. Bubble tried this pricing change before, they are trying it again, and it’s almost for certain it will go ahead. They promise things will improve, but at what cost? They are telling us to “trust them” - but with what? Hot air? What does that tell you?
- MITIGATE - mitigate your risks at all corners. Expanding on the elements of trust & diversification, have a strategy for diversification to manage the risk. I for one will be focusing on learning native code (or hiring devs, if I can somehow scrounge up cash from under a bed) and leveraging a backend provider to support the API and data layers. I went no-code to help manage costs, but that has backfired spectacularly thanks to corporate greed.
So what have I learned? If it sounds too good to be true, it is.
I have personally begun migrating the backend of my app to backendless, leveraging their capabilities in redis & hive, plus manually indexing key DB fields. The result? My most expensive query in bubble - which was taking average ~2s to process for each item on screen - now happens in backendless in 3ms… for the entire dataset. I should have done this long ago, but naievity and the simplicity of bubble was too enticing. No more. I will use bubble in the interim, offloading all data processing to ensure the most basic queries, and ensuring all API calls return nothing more than a unique ID and a sequence number, keeping API costs low. All workflows will be simplified to offload as much as possible to the API (and keeping volumes low), and doing as much on the client-side as possible. The bubble backend will be doing nothing more than an indexable static content store.
What would I like to personally see? Since bubble is hell-bent on making the platform more expensive, allow customers to set a limit on the cost - or better yet, throttle the workload and give the customer the option to purchase units either temporarily or permanently for the limits exceeded like other providers do. The silence by @josh and others is deafening, and the community is noticing. This issue isn’t going away just because bubble wants to stay silent - it just makes it louder, and the longer they remain silent and unresponsive, the worse it will get. PR 101.
Just wait for the exodus - it’s on the horizon. Last time I’ll comment for a while, unless I get banned for telling it like it is. I’m absolutely fed up with the whole fiasco.
@gnelson The Starter plan
amen.
Oh. LOL. I thought it was the name of another platform. 
Thanks!
So, despite my original comments on not intending to post again - it looks like backendless is also changing their pricing based on an email I received today. However, unlike bubble - they have done a fantastic job at communicating the change, explaining their reasons and scenarios, and even pointed out the flawed approach bubble is intending to use.
So what that means is that for anyone intending to make the switch to backendless for APIs and back-end storage, like I am, the new approach is based on peak API usage, per minute, over 24 hours. On top of the base $15/month, the pricing is tiered based on these requests. They do provide pointers on simple means to reduce the API volume, and clearly justify the options, timelines and the impact.
If you read between the lines you will see a few subtle attacks on this whole debacle bubble has created: “Rather than creating a nebulous new “unit of work” factor that you have to painstakingly calculate as you build, we chose to use peak requests as our measure of usage…”, and “Backendless has been growing for almost 11 years without taking in outside capital to sustain the business. As a result, we can innovate faster and bring you a product that we as developers would most want to use.”.
So just keep the above in mind for anyone intending to do the switch. More details here: backendless: Introducing the Scale Plan
Looking at backendless’s approach - there are some key differentiators that mean I actually have no concerns at all about the change:
- prices are NOT ridiculous, in the hundreds only for the largest deployments.
- pricing is predictable, based on a simple and readily available metric.
- features are inbuilt to help reduce the number of calls.
- functional packs are available to allow predictability in certain features that might be unique to your app.
- they clearly communicated exactly why they are changing, going so far as to describe the nature of the abuse of their existing pricing model by certain users
- they are adding additional core features that provide major benefit to users (e.g. SSL certs, custom domains, additional column-level security)
- the analytics are already in place, including a very simple and accurate pricing estimator.
@josh @emmanuel I hope bubble is taking note of how their competitors are handling price changes… there is a lot bubble needs to learn.
That 10% increase was based on previous pricing of $129/mth for the Pro plan. Looks like they didn’t grandfather in legacy pricing with the increase. That sucks.
Exactly the reply I got few min ago from Bubble. Again, communication issue here.
How does one know the cutoff date for your month’s workload units? It’s not clear in bubble’s workload unit graphs.
