When to stay on Bubble, even though custom code looks tempting

Tips
1

When to stay on Bubble, even though custom code looks tempting

I’ve been building on Bubble for 8 years, 100+ apps. I also build custom code, and I’ve moved some apps off Bubble.

And I’m seeing a lot of people debating this ‘should I move off Bubble?’ question.

Very often my answer is no. Here’s how I think about it.

Most high WU costs are a build problem, not a Bubble problem

Before you price up a rebuild, check these four things. In my experience they account for the majority of surprise bills:

  1. Searches inside the filter of other searches. This is the most common one.
  2. Long lists rendered with no pagination or inefficient data sources.
  3. A database structure designed without thinking about the searches that run against it on the frontend.
  4. Advanced filters, which are usually a symptom of number 3.

Fixing this will cost way less than leaving Bubble. I’ve seen (and helped) bills drop by more than half without touching a single feature.

If you haven’t done this audit, you don’t yet know whether you have a Bubble problem.

Stay if you want to be the builder

The builder, not necessarily the owner. Especially true if you are non-technical.

If your plan is to keep building the product yourself, every week, for years, Bubble is IMO the right tool. It gives you well-defined blocks and lets you figure out how to join them together to build your business logic. That’s a learnable skill with (very importantly) a limited number of moving parts.

Writing code with AI gives you unlimited options and no guardrails. If you can’t evaluate the architecture, you can’t tell when it’s gone wrong. A constrained system you understand is MUCH better than an unconstrained one you don’t understand, no question about it.

Stay if nobody’s using it yet

If your app works but has no users, it’s basically a prototype, regardless of what you’ve been through to get here. Migrating works best when you have a clear definition of what you want. So spend that money finding out if people want it first - and if that’s already on Bubble, it’s not worth moving. There’s a chance you can keep it on Bubble for a while.

Stay if the pain is a one-off

Hitting a one-off limit isn’t a good reason to leave. Hitting the same limits every month justifies a move more. But again, if these limits you’re hitting are an optimization problem, you’re better of fixing them. If you’re hitting limits even after optimizing (happens often as well), that might justify considering a move.

When it IS the right move to migrate

The cases where optimisation won’t help:

  • Lots of external data interactions - IoT dashboards, device fleets, anything polling frequently. Every API call adds to WUs, and optimization doesn’t change that much.
  • Large file handling. The 50MB API response cap is a limit.
  • Things the platform structurally can’t do. Long-running tasks, socket connections, etc. Any app where your core feature depends on a plugin or custom code injection.
  • Very complex apps. These gather tech debt a lot faster than others and get really hard to maintain with nocode.

These aren’t bugs- it’s just how the platform is designed, and it’s good at what fits inside the subset of what it handles well.

One thing I’d really watch out for tho

Bubble apps accumulate tech debt and that’s an inherent downside of nocode in general. Specifically on Bubble, privacy rules are limited by DB relationships, so you end up copying parent references into child tables. Two-degree searches are not efficient, so you have to design data around screens / functionalities rather than strictly around your business logic.

Both are reasonable workarounds, but they compound as complexity grows. A year or 2 in, a meaningful chunk of your database exists to work around the platform rather than describe your business logic, and every new feature has to respect all of it.

You can manage this. It just means revisiting your data model at intervals rather than only adding to it. Which also means that refactoring or changing a feature can take more work than it should.

So it’s a balance between 2 important things:

  • how much you control the product
  • how performant / optimized it is

I put a full-length thought dump here

Happy to discuss this more

2

hey @ranjit, thank you for putting this together.

I wonder what we could do at Bubble to make this a better experience :thinking:

3

I love how Bubble lets non-technical users implement privacy rules,
But it can be restrictive for more complex builds - and that almost defeats its purpose sometimes

After looking at the lifecycle of a lot of Bubble apps, I think the lowest hanging fruit (and I understand this is a big ask) might be making privacy rules handle more complex statements (X’s Y’s Z’s…). Support for even one more level of complexity here can drastically reduce a the tech debt that apps gather because of DB workarounds.

That’s also more on-brand with allowing users to build visually - privacy rule conditions should be where the logic lives