Bubble Sales Team 'trying' to help

Idea
1

I have 3 bubble apps that make up one system and we are in our first year of commercialisation with a race to take what it is essentially my MVPs to a scalable venture.
Now we have thousands of users, it is obvious that there are significant inefficiencies in the app.
Having a technical background, I have solved many of these, but there are hundreds more.

Today I received this email from Bubble sales:
" Hi there,

I noticed that your app is consistently using millions of WU per month - at your level of usage, most teams explore our advanced plans to unlock powerful features designed to support long-term scalability for high-growth and mission-critical apps.

If your business could benefit from:

  • Faster performance & greater stability

  • Enhanced security with dedicated monitoring

  • Boosted SEO capabilities

  • Direct Postgres database access

  • Local data residency compliance

  • Premium, hands-on support

We’d love to connect and explore how we can support your long-term success on Bubble.

Do you have time this Thursday (May 29th) to talk through this? If not, feel free to [pick a time that works best for you here]

Talk soon,

Fabio

My reply:
"Well hi Fabio,

Thank you for reaching out.

As you most observantly noticed, my app is using millions of WU per month, and whilst you may see this an opportunity for yourself to sell me more WU - this is all you are doing, I would rather appreciate it if Bubble.io:

  1. Contacted me to see how I could optimise my app to reduce my excessive WU consumption to “explore how we can support your long-term success on Bubble.” or;
  2. Diverted their AI investment into analysing the completely impossible server logs to identify poorly written workflows so that I can ensure long-term success.

You can contact me if you like tomorrow, but be prepared to talk about the above rather than ‘scaling’ my inefficient app to a more expensive plan.

Kind regards,
Peter"

This is my main problem for me with Bubble, I have gone past a development stage and need help to optimise.
I don’t trust the optimise button and I find the server logs too cumbersome to analyse.
To be clear - I know what processes are inefficent, but I need help to better reduce WU use.
There are hundreds or questions and different answers to the same issues of reducing WU.

Could Bubble divert AI investment to helping us move to the next stage of scale rather than selling us more WU?

3 Likes
2

I understand your frustrations. It’s obviously not the fault of the sales team. There’s absolutely no development going towards better server side logs, analytics, etc. I find bubble gets away with doing the absolute bare minimum these days and sometimes less than that.

I agree with your sentiment about AI. It can be cool, but it should not come before the hundreds of bugs and unfinished work that needed to be fixed or completed two years ago.

1 Like
3

If your app is at scale, it shouldn’t be on Bubble.

Bubble is positioned as a tool for MVPs, not for building scalable production apps. While some may disagree, the platform’s recent decisions and ongoing development focus make this pretty clear:

  1. High WU (workload unit) costs – Significantly more expensive than alternatives like Supabase.
  2. Expensive storage – Compared to services like S3, Bubble charges a premium.
  3. Lack of advanced components – Especially for things like file uploads.
  4. Limited database control – You can’t optimize or actively manage the database effectively.
  5. Inefficient database design – Built for ease of use rather than performance, which drives up WU usage.
  6. Multi-tenant architecture is clunky – Difficult to implement and manage cleanly.
  7. Performance issues with active users – Apps become sluggish as concurrent user count grows.
  8. Neglected API connector – Functional, but very barebones.
  9. Restrictive privacy rules – Limits flexibility in complex data-sharing scenarios.
  10. Inefficient data handling – Sends entire data objects to the front end, even unused or deleted fields.
  11. Bloated app loading – No control over how the web app loads, and it’s not optimized.
  12. Poor SEO support – Not suitable for apps that need to be discoverable via search engines.
  13. Limited conditional logic – The formula builder is clunky and restrictive.
  14. Limited reusables – Makes app maintenance at scale difficult and often requires hacky workarounds.
  15. Unfriendly to custom code – Injecting custom JavaScript, CSS, or scripts like Python often leads to instability or conflicts with Bubble’s internal engine.

The list goes on…

Bubble is great for building and validating MVPs. But it’s a poor choice for scale. It might work for single-tenant apps with a few hundred or low-thousands of users, but if you’re targeting real scale—thousands to tens of thousands of active users—you’re using the wrong tool.

3 Likes
4

Everything you’ve listed is a tradeoff that results from something being easy to use compared to alternatives.

5

Reach out to me in a PM to schedule a free call to talk about how my paid plugin Data Jedi can help reduce workload units from millions a month to just tens of thousands, allowing you to save hundreds of dollars a month, while simultaneously improving content download speeds by 30-50% on average, and opening doors for much more robust in app features, especially for things like changelogs and database backups.

2 Likes
6

Cheers Matthew,
Will do

Pete

7

For most apps, this really isn’t the case. An app that’s built well will be just fine.

@peter.hudson It’s normally 20% of logic which causes 80% of the workload units. It’s very likely that it can be optimized.

The optimize button doesn’t change your workload usage, it just removes unused parts of the app. You can use the logs to view which processes are consuming the most, and then begin to optimize them.

There are some simple rules of thumb which can help you:

  1. Use Schedule API Workflow on a list, rather than recursive workflows.
  2. Avoid passing lists of items into recursive workflows if you are using them.
  3. Use database searches rather than advanced filters.
  4. Avoid plugins like Fuzzy Search as they eat up workload units.
  5. Avoid Do-When-X frontend workflows that hit the server as these will all consume workload, even if someone isn’t even using the site as long as their tab is open.

You may find this useful: How to optimize your app’s workload units (biggest WU killers)

I would avoid using third-party plugins where possible, as that’s simply introducing a dependency on your app and can often make it more complex and hard to maintain than it needs to be. It’s perfectly possible to build an efficient app on Bubble, and it’s rare that I see an app’s workload units costing more than 10% or so of its revenue. We recently took over an app from an agency that heavily used Supabase and migrated that back into Bubble. Even though it cost more in workload units, it saved them more money in the long run through the development speed advantages.

People can argue that using an external backend or a plugin might not affect development speed, but if that were the case, that client wouldn’t have come running to us to save the app…

Of course, this varies significantly depending on the app type.

Also, https://getbuildprints.com/ is a free tool that allows you to chat with your Bubble app. If you see in your metrics that a certain part is using a lot of WU, you can use the AI Copilot to propose optimisation strategies. I hope it helps.

5 Likes
8

I’d have to disagree here, although I understand some of your points. I’ve worked on a few apps with 10,000s users and Bubble performs really well there. In a lot of circumstances the ability to publish changes faster than competitors due to using Bubble vs not, has put those sites in a much better position than if they were using trad dev.

This might be controversial but the cost of workflow usage and storage aren’t actually that much in the grand scheme of things if you’re running a profitable business. I know people like to get into the nitty gritty of what very specific actions cost versus other providers, but any saving I’ve found has typically been a drop in the ocean when all a businesses operating costs are taken into account.

A few years ago I’d probably agree with you that eventually you’d want to move off Bubble, but there doesn’t seem to be many good reasons to do so anymore.

6 Likes
9

Thanks George,
Yep - I believe I can optimise the app a lot and I am certain I can scale with Bubble too.
There are a few things in your avoid list I am using and will try and refactor out - particularly a couple of 3rd party SSA actions.
Also - I already have buidprints - but haven’t tried asking the CoPilot yet for help. I will definitely be trying that.
Thanks for the advice

Pete

10

Is this true even for “Do when X (yes/no) becomes yes”?

Can’t imagine this would be too WU heavy.

11

I’d suggest hiring a data engineer/analyst on a contract basis at the first stage—someone who can understand your domain, optimize the database pipeline/structure, and build a proper model.

No framework or refactoring will help in a long term if you have a sluggish database.