You’ve nailed it right here. I can understand why people are upset over the changes but i think a lot of users are severely under charging their own users for using their Bubble app. It’s good to offer value but it’s best not to undercut the market too much.
When considering what I can build in Bubble, I’ve always believed that Bubble was offering a steal with their legacy prices. The initial WU release was stupid but at least things look more inline with their original estimations now.
I never used the acronym MVP…but are you making that point based on a large experience working with clients and/or numerous community members expressing their plans with you or is it more likely just your own idea of what is or is not happening on Bubble anymore? Plus, who needs a lot of trust for an MVP?
Think about it like this…an MVP is a one night stand, maybe a weekend fling. Building and scaling an app is like a marriage. Who has ever thought they needed to trust the one night stand? And if you did trust your one night stand, you likely wake up with the consequences 9 months later or in some cases 2-3 weeks later with a burning sensation.
And you can be confident of that with traditional coding? What happens if the app is hugely successful and you need to add more servers? Of course cost per server might be known, but the number of servers is not, therefore your costs are unkown.
Why are they not best practices? Because they are a bit slower to filter the results? Plus, you can’t blame old information for being outdated due to new changes. Personally, in my apps, I don’t imagine I’ll have a need to optimize my searches. For me, I’ll mostly have to become more creative in data manipulation and getting data into the database.
Even in the Bubble webinar last night I spotted two areas in which a Bubble representative was giving some guidance on ways to optimize the app, that I could come up with more efficient ways, as alternatives. It is always important to remember that in Bubble there are a lot of different ways to come to the same end result, and as it was in the past and now, some people will be more effective at finding those ways. That is what sets some developers apart from others.
Yeah, I believe I mentioned that (not the telegram part) people leave Bubble, that is nothing new. People leave or stay for their own reasons. Like a lot of my clients have in the past, they built to validate an idea, start to grow the business, and then reach targets that enable building elsewhere.
I think people overall need to get off the complain train and understand that train has no destination. Bubble is not changing things. What they are doing is improving the new situation with new tools and features. I’ll personally still be here to voice my opinion on what features are needed to make Bubble more efficient in terms of WFUs, especially around data manipulation and in some respects data retrieval.
Nah, what you’ve described is not MVP 
MVP in classic terms is an early stage of product development when you release your app with just enough features to get early customers. Then you accumulate feedback and continue development if you can see that there is a market fit. Or close your app cause there is no demand. It’s impossible to validate an idea/product in 1 day or 1 week.
Because it has been tested by hundreds of bubble developers and also some best practices are mentioned in official Bubble documentation.
If there would be no “complaint train” - we would hardly see any positive changes from Bubble in WU costs and other things within new pricing model, btw.
True, when you only playing around for a few weeks all my arguments are dead.
If you do are serious and want a bit more than slides, glides and spreadsheets you look for things like Bubble. And not for a few weeks. If so, Bubble has no business at all anymore.
Given the 10x 100x markup of hosting prices that the new WU pricing is delivering we suddenly talk about prices for a search in the db. Traditional coding does not have this issue because it is 10x 100x cheaper in the first place and there is no cheaper alternative.
But true. No point of complaining but just good to make sure we share information so everybody can make up their own minds
It was an analogy to express the difference in time of relationships…one night stand versus marriage. Marriage is forever, need to use Bubble to scale indefinitely, one night stand is short term, need Bubble to validate a product.
And Again, Why is it a Best Practice? Because using filters is a bit slower? What other benefits are there to not using Filters…have you ever come across a situation in which using filters is faster, because I have.
You must be impatiently waiting for the outbound train then. It’s been a week, how fast do you expect them to move?
My comment was more about using lists than filters. Filters are usually not a big deal until you work with large amount of data or use advanced filtering .
Idk when and if Bubble will react to ideas and concerns shared by the community after WU re-weighting. But it’s important to continue providing feedback to prove that we care.
Hi there,
trying to get my self more into the recent pricing update and WU.
Definitely not good experience, but if you are in the startup world, and not only a hobby and learning building, and in particular if your app is community based, you can understand such management actions done by Bubble, despite we don’t see much as Bubble sees.
Nevertheless, It would be great if we (Bubble) can improve this part, where we can see how WU will be in monetary value, so that we can plan bit a head, raising funds, scaling, etc.
Or there is already a way to find this out? Thanks!
Having gone through the five stages of grief over the last fortnight, I’m firmly at acceptance. Their new pricing is fundamentally sound, have plans predominantly for editor/developer features, each with so much server usage, and then additional plans for server usage.
I think that’s fair for the value they’re providing. The problem is the way server usage is calculated and the sheer cost of it! Charging per character retrieved from the database and expecting customers to pay for the sheer inefficiency of their own weird database abstraction?! And the way they handled it all, either price anchoring or incompetence mixed in with more than a soupcon of seeming arrogance and ambivalence for their customers has indeed left a bad taste in one’s mouth.
However, Bubble is a great development platform, that hasn’t changed. I’ve spent too much time, effort & money learning & mastering it just throw it all away. I’m not gonna cut off my nose to spite my face by spending ages learning something else just to get back to where I already am. However I’m not gonna stick around just to be ripped off either.
With the exception of page views (which is a non issue for SPAs) avoiding using their server resources and outsourcing that to another service which allows me to potentially scale in an unmetered way and with predictable costs seems to be the way to take control of this situation. I’m moving to Xano using the Xano Connector plugin from Eli & Jared. There’s a minimal learning curve so can jump on immediately, there’s great import to move data out of Bubble and it’s database is a dream to work with compared to Bubble’s (I have Joins again! Sweet sweet Joins 
). Admittedly it ain’t cheap itself but it’s value add is well worth it imho and it’s the fastest, simplest and most cost efficient way to get out of this pricing mess for me.
If the bad taste persists with Bubble over time then I’ll eventually move to something else on the front-end when time allows (there’s some amazing alternatives out there to consider, Noodl, Toddle, WeWeb, Dittofi etc, all with their own pros & cons), but I’m not gonna let all of this derail me from my product plans and put my business in jeopardy for the sake of it. My nose is firmly in place and my face can suck on it. Ha! 
No you can not. You start with an idea but the WU is so complex that there is no way you can predict the total needed WU.
It depends on things like total characters returned from a db or api call. Or for the amount of items in “do a search for”.
What you can do is try to build features with minimum WU in mind. So no API calls is best, if you need api make sure to do it once per user and with as little characters in the body as possible. Also, use lists in fields as much as possible. Another good idea from WU perspective is to use client side workflows as much as possible. So first get your data to the client and do filtering client side. That will mean less WU. Forget about autobinding as it will do more calls than needed. Also make sure you do not add to much features that will keep your users hooked to the app/web because every click will consume WU units.
Good to know however, you will only have this issue when in the startup phase. As soon as you make millions, the costs per month likely does not matter that much. You will save money on developers, db engineers and network engineers.
That is also probably the idea of the new pricing structure. Moving to enterprises.
I’m really interested in this, but also have some doubts you @gazinhio and others planning the same way out could eventually help me with.
I’m referring to the table published here about WU consumption. Here is an excerpt from it:
As I understand it - but please tell me I am wrong - moving data to XANO would save -0.2 WU every time you write/edit data, but you would spend +0.2 WU more every time you delete data. At least that is my understanding:
The numbers may change by approx. 0.1 WU if instead of going through the API with the “API connector plugin”, you use the plugin Xano Connector plugin developed by @eli and @jared.gibb.
But I’m most certainly making a mistake…Please help 
Why do you say use lists in fields as much as possible. Seems like it will add more characters than you might require.
Could you give a concrete example of how that suggestion is optimal?
In stead of a new thing that costs WU units so Josh suggested that it might be better to use lists.
As in make a change to a thing and update the list field rather than create a new thing to store a single entry?
You’re assuming that you’ll be using either an API workflow and a server-side plug-in or Bubble’s API connector. All of which use Bubble’s server resources and accrue WUs. The Xano Connector is a client-side plug-in which uses Xano’s JS client library to call your Xano APIs so, as it doesn’t touch Bubble’s servers, you’re not using any WUs. You don’t use Bubble’s Backend Workflows, their database, their auth, database triggers or any server-side plug-ins so you’d be effectively using Bubble purely as a front-end tool with Xano at the back-end. That way you’re only accruing for page views, which should be manageable in your plan’s WU allowance, especially if your app is a SPA. Now obviously you’re gonna have to pay Xano but it’s not metered and your costs will be predictable and, while it ain’t cheap, it ain’t the same as wondering how many characters your users are gonna retrieve from the database this month so you can put food in your mouth!
Check out Eli Beachy’s YouTube channel, he’s got a couple of videos on there on how to use his and Jared’s Xano plug-in. It’s pretty straightforward.
Thanks a lot Gazinhio - I’m definitely going to chek it out! 
but is there any difference in performance* between:
*e.g. the speed of showing a list of images
Speed is comparable, faster for complex queries as you’re doing it on Xano’s servers & getting the result directly rather than some workaround with Bubble’s DB like nested searches.
The only downside is no realtime which is a not a norm generally but something we’ve taken for granted with Bubble, as it works over web sockets, although there are workarounds & the plug in gives some help by auto refreshing on update.
In terms of a list of images, they both return a list of image paths & then Bubble renders them on the page in both cases so there’s no difference either way.
What precisely do you mean by “realtime”? Does this mean that if a database value is changed the user needs to refresh the page to see the updated value? @gazinhio
I’ve heard of some workarounds where you keep a single item in the Bubble database, and your external database listens for its own changes and send a webhook to Bubble to update that one thing (Like a date/time field change or something). Then the client listens for the Bubble date/time change and makes an API call to your external database to get the new data
Not refresh the page but refresh the data source. With web sockets, the server pushes changes to the client, without it the client has to request data from the server. There are pretty simple workarounds and the plugin helps, but also remember the realtime has a price in their WU system.
If you need a feature like chat where realtime is essential then absolutely use Bubble’s DB for that as it’s perfect for it. For enterprise database querying, pulling data from different tables then Xano excels.
