Hi, thank you for the great answer, but what specifically are these “advanced filters” I see people mentioning around?
My suggestion: look at bubble in it’s current stage as a great prototyping tool and if you start receiving traction, build it with code right away
This has been my takeaway over the last 12 months of getting to learn bubble. And it’s not a knock on Bubble itself - providing a truly low-barrier-to-entry “codeless” app platform by default must come with some technical sacrifices. I compare it to a high-end custom Linux configuration vs Microsoft/Apple. The former will always be more efficient, but only the high end of powerusers will be able to make use of those efficiency gains. Most people just need something to help them handle the basic CRUD activities that make up 95% of their usage habits. Microsoft (and then Apple) provided that monolithic but stable user experience that was easy even for a rank beginner to do complex things. There is a reason why Microsoft and Apple completely own the PC space while Linux has only a niche user base. And yes, I do see Bubble as a potential Microsoft/Apple of the codeless development platform space
If you get to the point where you need to control server architecture for edge performance gains, you’ve outgrown what Bubble is good at providing for you. But that’s a good thing, because it means you’ve created something awesome that tons of people need to use every day!
I do believe - just from what I’ve seen in terms of responsiveness of @emmanuel and @josh - that once Bubble cracks the monetization nut, they will be able to focus on providing great support for powerusers.
I apologize for my previous off-topic reply. I meant to talk about this and deviated. Anyway, it is indeed cruel or at least inappropriate to think like that. You can see Bubble’s current limitations and fortresses and build something based on its fortresses. A business that rakes in somewhere between $10 and $30 per customer per month, no free users, is very well served.
Such app will never get to 100k users or something along that, and doesn’t need to. Is one supposed to throw away such bubble app and “switch to code right away”? Of course not.
Obviously be vocal about your needs so they can know about and address it whenever they can and it fits their roadmap, but don’t trash it away just because it doesn’t serves a use case. It has a lot of uses and goes very well with most of them, given standard functionality, the API and custom JS capacities.
TL;DR: Focus on building something profitable that works well within Bubble’s current capacity, which is already a lot and is also liberating.
hey @vini_brito it’s this functionality - quite powerful but can really slow things down:
And if that works for you, that’s great. The whole purpose of this conversation is to define at what point Bubble’s “fortress” becomes a significant limiting factor in continued growth - and it’s at the point where a strict SLA becomes mandatory to maintain a reasonable user experience or ensure computational ability if you’re dealing with huge datasets/data science type functions.
If you’re getting to a point where you have to alter your design and user experience to stay within Bubble’s current limitations, you’re doing yourself and your users a disservice. And actually hurts Bubble in the long run as it would unfairly get criticized for performance problems.
This is now implemented: [New Feature] Scheduling API workflows can now be done recursively
thanks for your input @vlad. Quick question: at what point do you sync all your objects so they share the same data? in the same workflow or in another workflow? or when?
Do you mean something like the following?
- You have a list of message objects as a list field on a task object
- You have a task as a field on the message object
- You update the task for a particular message
- When do you update the list of messages for both the old task and the new task?
If the above is correct, I would probably have a custom workflow or API workflow which I pass all new and edited messages through that would update any associated objects with it. I would call that custom workflow/API workflow after performing any project updates.
Agreed, I’m paying $1500/mo right now, same issues. Currently working with a professional dev team to build in real code. Only thing I’d add past performance issues is lack of any real testing capability, and no staging environment. It is important to note, that I’ve got a very complex app, and that @feee and I are the exceptions to the rule (ie., Bubble is the reason that I was able to prototype my platform, and why I was able to accelerate to 40K MRR)… and this shouldn’t be interpreted as “Bubble won’t scale so I shouldn’t use it.”
That’s a lot of money. I paid $100 for a custom WordPress website (one-time) and I just pay for the hosting which is around $20/mo for a VPS. Why is Bubble this expensive?
Edit: You can argue that it was cheap to create the website because it was using WordPress, but generally, I’ve had to switch 3 apps from Bubble to either a CMS or a custom made website due to the issues I was having and I’m not getting complaints about page load times anymore. Why would I pay $1500/mo for a no-code platform that’s supposed to save time and money?
My lesson from Bubble is, you’ll have to switch from it when your app grows, unless you want a Dedicated Server from Bubble which (most of the time) costs more than hiring a developer to create it for you.
I think we’re talking about 2 different things here. A web app like Bubble is meant to build can’t be created on WordPress, and if you do end up hiring a developer for less than $1500 a month you’ve gotten a bad developer.
Considering the size of the website and the price I was paying before and after Bubble and the control we have now, I wouldn’t say I’ve gotten a Bad Developer. Besides, we recreated the app (not using Bubble) and it has the exact same features and it looks the same from when it was on Bubble.
And by the way, I would know if I’ve gotten a “Bad Developer” or not, I’m the owner of the website, and not you.
If he is a good developer and he is full-time dedicated he is completely underpaid
Last I checked, he is not full-time and he does have a part-time job. Anyway, this isn’t about the developer, it’s about the performance issues Bubble is having.
Coming back to Bubble. Bubble is excellent for a few things, very good for the great majority of things and very bad at certain things. Just like any similar product.
The problem I see is that the marketing of Bubble is causing some confusion or just setting hopes very high.
But it’s just marketing. When you see an ad of Nike what do you feel? That you can do anything, right? You just need to have the attitude and just do it. Then reality crushes you big time. You are not going to become Usain Bolt. And that’s ok. So long you know it’s just marketing. I’m pretty sure people that buy a pair of Nike running shoes don’t go on Nike forums saying that the performance of their shoes is crappy because they have not turned into Usain.
Maybe Bubble could add a “what’s Bubble for and what is not for” in their marketing scheme.
I get your marketing point, but compare Nike to Bubble.
Awesome to read this discussion and views, as performance has been our pain point since day one. Equally, without Bubble, alternative code options would likely have taken longer and initially cost more - so bravo to Bubble. Overall, this tool is just super sophisticated.
With that said, we’ve optimised our app / pages as much as possible and like other users above, we’ve reached the point where we’re proven and ready to scale, but… everyday, we get slow page loads, user complaints of performance and even random white screens of death. To retain frustrated users, we’ve had to increase phone support and work harder.
But, we see that as a good problem to have.
To solve these, we’ll explore Dedicated plans, but the road blocks seem to be #1 price (especially with USD:AUD FX rates and variability and the extended contract), #2 support (it doesn’t seem like extra support is yet available) , #3 customisation (ie. without paying for extra dedicated configurations, it seems we can’t configure our own ‘baseline’ server to better align to our app’s needs) and #4 guarantees of speed (from reading here, Dedicated doesn’t seem to be the silver bullet with speed issues) even once localised and we’re targeting <1sec for page to page transitions, to ensure an app like experience.
Given the expense and 2,3,4 above… while we’d love to remain on Bubble indefinitely, it seems like and based on the advice of many above, that rebuilding is the only option now that our app is needing scale and quality / reliability / speed is 100% expected by users (especially to win over the new users)… and even with 20 units of capacity, it’s too slow.
So I guess that leads to things we’re wondering…
What success have people had with Dedicated? Anyone in Australia specifically?
Are there any (short term) plans for Dedicated to offer affordable hosting prices? (here I mean ‘affordable’ in the context of cheap enough to not consider rebuilding)
What have people rebuilt with when leaving? (Flutter, React Native, Native etc?)
Are upgrades / releases about to occur to solve these performance issues?
Great discussion, amazing system and hoping to learn if Bubble can work longer term.
Hope you get some answers, you’ve asked some great questions. I’ll be following the thread.
Being from australia too I’m quite interested.
I’d love to check out your app aswell…
@michaelm Thanks for the feedback and we understand your concerns regarding performance especially for app users in Australia. We have received a lot of interest for regional servers on main cluster plans and this is something we definitely want to consider for the longer term. Meanwhile, we are always here to help. While we cannot build your app, we can take the data points you share from app/page optimization tests and dig deeper into optimization opportunities at the backend.