If you’re interested in micromanaging WU and splitting DBs up just to save a few WU, Bubble isn’t the platform for you.
Is Bubble more expensive than hosting your own traditional code server? Of course.
Treat it as the cost of development. Unless you’re spending $5k/mo more in WU on Bubble than you would on traditional stacks, then you’re still net benefit by avoiding the cost of developers, not to mention the speed benefit that Bubble gives.
Why would you move a Likes table to Xano to save $30/mo or something? It’ll cost $200 in development time to set up let alone to maintain!
Thanks for your input George. Obviously I’d not move a table externally to ‘save a few WU’ right now as we’re still at small level, but when we have many users each liking and unliking hundreds of audio samples, that “few” WU starts adding up to big WU and eating away at profit margins etc. So at some point, it may well become the more economical option to move that particular ‘feature’ to an external database. Of course, as with anything, you’d have to seriously weigh up the pros and cons for the given circumstance at the time. Who knows, by then bubble may have dramatically slashed their write costs
I know - I’m just saying (and as someone that knows your app well) that you’ll save more money keeping it on Bubble and taking the WU cost hit than trying to mix and match external DBs. The point at which you may reasonably consider migrating this feature is when you’re in the region of of 5k+ likes per day.
Founders will often try and solve problems that will only hit a long time from now. I know my example was coding (well, no-coding) an automatic refund system for my app before I’d even launched. It took 2 hours to build as I was inexperienced, but each refund only took me two minutes to do manually Sure, I was protecting myself against the day (that never came) where I’d need to do dozens of refunds a day because my sales would be huge, but I could’ve spent that dev time elsewhere.
Of course consider them when you build so you don’t build up technical debt, but focus on what really matters for the here and now of your business!
Yes, completely possible and people do this type of thing. Anytime as a business owner you can save some money, that is in essence a way to increase your profits, which ultimately is the goal of any business. I grew up having a little coin case with the phrase on it ‘a penny saved is a penny earned’.
If you have a feature of your app, such as likes, that when implemented causes your app WUs to exceed your plan and you need to purchase an add on, and the cost of the external service is less than the add on price from Bubble WU tiers table, you would likely find yourself in a better position financially. For example, if you had to increase by 500K WUs a month in excess of your main plan allotment, that requires a $99/month, which is nearly $1,200/year, compared to a pricing tier of Xano as an example, which would be around $85/month…are the cost savings dramatic, no, are they enough to cover costs of the implementation of the external database, maybe not.
However, as with anything in Bubble, learning about it now, to only not need it now, but at the least have the knowledge to make a future decision better, it can be worth it, but that is a personal opinion. I live a little bit of a more relaxed and slow pace life, so I don’t focus too much on speed. I enjoy tinkering and learning.
I don’t imagine that happening…part of the reason is that if they were going to do that, they would have already, likely around 16 months ago when they first got the backlash from the community on the pricing scheme.
I’d imagine for most independent founders, Bubble plans will suffice for them to keep everything in Bubble. Once they gain some traction, they can better understand what parts of their apps eat up most of their WU credits and better determine what approach to take in order to decrease WUs and/or speed up their data processing. One example here is that you may find yourself with a large list of data that you need to make some changes to using the existing entries to create a new field from. I had to do this recently to take 3 data fields and ‘combine’ them into a single field in order to create the search keyword function and make them all lowercase. Rather than running this in a backend Bubble workflow, it could make sense in some situations to use Google Sheets to do this, which could be manually done with export and upload functions from app editor, or via API. So, not all situations would necessarily cause you to use an external backend.
In one past student app, they used an external database just to process a large amount of data. In Bubble backend it took nearly 4 minutes. When they setup the external database processing (I didn’t do this @jared.gibb did that magic) the time to process decreased to around 4 seconds if I remember properly. So, in some situations, the external DB is not solely utilized to save some WU costs, but perhaps to improve app performance. Had the student not done this in the beginning of the build prior to launch, they may have failed to ever gain traction as no user would of used the system that took so long to process data that was critical to their use of the software.
although if you were going that route I’m not sure why you would use Bubble for the front end when you could just use something like Caspio which can be used on any website as a host.
Caspio was one of the original no code/low code companies starting in 2000 and is used by some of the biggest companies in the world. They’re continually running Google ads about why use Bubble where everything is metered when you can use us. Still, Bubble has some features that are better and are probably worth the extra costs.
I think a selling point with a site like Bubble is the speed to market. It’s an all-in-one platform.
Work units are confusing. It’s listed how much is charged for each action, but, that doesn’t take into account user behaviour.
It’s possible to get an average based on users, but human behavior is impossible to identify.
It does cause you to optimize as much as possible…which is not a bad thing.
I think the company that is first to design an AI that not only builds a page but also adds workflows and everything else needed will be the next breakthrough in the no-code space.
Overall, I think Bubble is a good platform. If my app which I’m STILL building ever gets to anything meaningful with the public, I may reexamine things.
Like I said in the original post. Point was not to just bash Bubble here, Bubble development is great and fast. What keeps me using Bubble? I like the tool and the speed of building, heck me and my team just had an idea for a product and built it in 48 hours.
There is no right way or wrong way to build on Bubble but the way we build from now on will be external database first as we find it makes apps more performant and solves some of the other speed issues we experience. This post was moreso a point to just share that cutting down WUs dramatically is possible but it is a rather large effort.
Personally, I like the Swiss army knife approach with bubble where everything (front-end, logic, database, etc.) is on one single platform. My advice to clients is to keep the tech stack as short as possible, not just in the early days, but even as the business grows.
I have a client app with similar WU numbers on a legacy plan paying approx $500 per month (more capacity units, storage, etc.) and we are anticipating costs to go up by $200 or so in October, after optimizations have been made.
My team decided not to move the backend off bubble because it would become one more piece in the stack to manage, add one more point of failure in the chain, and will invariably increase the cost of maintenance and upkeep.
There are new features for measuring and monitoring workload like app metrics or custom workload notifications
If you’re on the new plans, you can run bulk operations in a more workload-efficient way with Schedule API Workflow on a List (SAWOL)
The Manual also has optimization tips, checklist, and case studies - in some cases, agencies helped customers reduce WU by 400%
On the roadmap side, I’m afraid the team keeps it under wraps but includes everything from better observability and reporting to platform improvements/optimizations.
I made sure to tell the team that users like you would like to have more details on what work the team is doing around WU!
I think it is more than fair that Bubble has not done work on drastically reduce WU consumption. After all, WU is now one of the main drivers how they make money.
As an example. In our already optimized app we could run thousands of users more or less on a €150 month plan. We introduced a backend and can now run on a €29 plan. This obviously took some time to setup but it now does not matter if we grow to 10.000 as our backend is mainly running idle with thousands of users. Suppose Bubble has 10.000 users like us. Helping me to reduce my WU without an external backend, would mean they loose 150-29 = 121 x 10.000 = 1.210.000 euro each and every month. Most SaaS infra costs are between 1-10%. So let’s take 5% as example. 150 x 5% = €7.5 costs. 10.000 x €7.5 = €75.000 a month in costs for customers like us. This means that by helping us reduce our WU they will loose €1.135.000 a month to cover for other costs and contribution to the bottom line.
Focus of Bubble is enterprise (who do not care at all if the Bubble bill is €5k, €10k or €20k a month as long as it is stable, flexible and secure while at the same time let them play at minimal costs.
Or on small agencies and companies that are unable to code and there have the feeling to be a rockstar developer as they can build a lot with Bubble. For those people the pricing hurts but they do not have a viable options elsewhere at the moment.
For most active people on the forum Bubble is in the mix to handle a quick front end setup and use external DB and other API calls to do fancy things. But those do not move the needle much for Bubble in terms of making money.
So enjoy the benefits of Bubble, when you no longer do you are probably too versed in IT in which case you can go hybride (different backend) or pick another frontend framework.
So your point is that you should be able to make thousands of dollars from your users but only pay Bubble a few hundreds, every month. For something that will cost you tens of thousands in infra and manpower (monthly) if built ouside of Bubble.
He’s defending bubble and saying users need to appreciate how much they’re saving and give their dues to bubble and don’t complain about the WU cost to much because ultimately it’s still cheaper than doing it in other ways, until a certain point but then by which time they’re probably ready to migrate to completely different tech stack anyway. That’s what I read anyway. So, your reply to him was kinda misplaced because I think you’re both on exactly same page.
Well this is fine if it’s a user starting a fresh project, but what if it’s a seasoned user who already has many complex apps built in bubble and find that bubble does the majority of what they need perfectly. Why reinvent the entire wheel. Also they may simply love bubble, and the community, as I do, and have spent years mastering it. There are probably many reasons tbh why someone may choose to build in bubble. I could personally list 100 reasons why Id not want to leave but it doesn’t mean I may not use some external services at some point to compliment. For example we currently use S3 (and considering cloudinary) for asset management rather than bubbles inbuilt storage.
Sure, I was protecting myself against the day (that never came) where I’d need to do dozens of refunds a day because my sales would be huge, but I could’ve spent that dev time elsewhere.
