When to leave Bubble, and when not to
Most Bubble apps should stay on Bubble. This is the test we run before quoting anything, written out so you can run it yourself.
Lucian Lutas
We make money migrating Bubble apps to code, so treat what follows with the scepticism it deserves. It is also the test we run before quoting anything, and most of the time it says the app should stay where it is.
Here it is in full, so you can run it without talking to us.
The two lists
Read both. The question is not whether you can find one item on the right, because you can always find one. It is whether the right-hand list describes your week.
stay on bubble if
- Workload Unit spend is flat month over month
- Workflows are simple and mostly synchronous
- The user base is small and growing slowly
- Nobody is asking you about SOC 2 or HIPAA
- Nothing about the app feels slow to the people using it
- It is working, and it is cheap
time to leave if
- Workload Unit costs climb every month and you cannot see why
- Users complain that it is slow and you have run out of fixes
- You need to hire developers and cannot find Bubble ones
- SOC 2, HIPAA or data residency has entered the conversation
- An acquirer or investor is asking to see the codebase
- Native mobile performance has become a real problem
If only the first list describes you, stop reading. You do not have a platform problem, and anything you spend on migrating is money that could have gone into the product.
What each signal actually means
Workload Unit costs climbing. The signal is the slope, not the number. A €400 monthly bill that has been €400 all year is a cost of doing business. A €140 bill that became €795 in eleven months without a matching increase in users is the platform charging you for work rather than for value, and that gap widens as you succeed. Before concluding anything, read what Bubble actually costs at scale. A lot of climbing bills turn out to be dead scheduled workflows rather than growth.
Slow, and out of fixes. The qualifier matters. Most Bubble apps that feel slow have unconstrained searches and workflows doing database work on every page load, and those are fixable in place for a fraction of a migration. The signal is that you have already done that work and hit a floor you do not control.
Hiring. This one is usually decisive and rarely on the list when people first call. You cannot hire a Bubble developer the way you hire a React developer. The pool is small, expensive, and every hire is a bet on one platform staying healthy. If your plan for next year involves adding two developers, the platform decision is already made.
Compliance. SOC 2, HIPAA and public-sector procurement ask questions about infrastructure, logging and data residency that a no-code tenancy cannot answer on your behalf. Note that Bubble gives you between two and twenty days of server logs depending on plan; some frameworks want a year.
Acquirer due diligence. Buyers discount what they cannot audit. The discount is usually larger than the migration would have cost, which makes this the one signal where the arithmetic is not about running costs at all.
Native mobile. If the complaint is specifically that the mobile experience feels wrong, and you have already tried the obvious things, that is a structural limit rather than a tuning problem.
Three reasons people migrate that are not reasons
These come up in most first calls, and none of them survives contact with a spreadsheet.
"We're worried about lock-in"
Everyone is locked into something. The question is what the lock costs and what leaving costs, and both are knowable numbers. Lock-in as an abstract anxiety, with no cost pressure, no hiring pressure and no compliance pressure behind it, is not a business case. It is a feeling, and it will cost you five figures to resolve.
Revisit it when it attaches to a number.
"A developer told us Bubble doesn't scale"
Sometimes true, usually imprecise. Ask which part. If they cannot point at a specific workflow, a specific search or a specific line on the Workload tab, what you have is a preference rather than a diagnosis, and developers who do not like no-code tools are not a rare species.
The version of this that is real: a named bottleneck, already optimised, with a measured ceiling.
"We want to be acquirable someday"
Someday is not a trigger. Due diligence is. Migrating two years before anyone asks means paying now for an option you may never exercise, on a codebase that will have drifted by the time it matters.
The exception is if you are actively raising or actively in a process, at which point this stops being "someday" and moves onto the first list.
The order to work in
Even when the second list wins, migrating is rarely the first thing to do:
- Find the waste. Workload tab, server logs, scheduled workflows nobody remembers creating. This is free and it frequently ends the conversation.
- Price a workload tier. Bubble sells volume discounts on units and does not publish the rates. Check your billing page before assuming the bill is fixed.
- Fix what is fixable in place. Unconstrained searches, workflows doing avoidable database work, privacy rules that force full-table reads.
- Then run the numbers on leaving.
Most apps stop at step one or two. That is a good outcome and it is not a failure of the exercise.
If you do get to step four
The calculator will give you a break-even in months against a migration quote, using published pricing with the assumptions shown on the page. It returns "stay on Bubble" when the numbers say so, including the case where the replacement stack is simply more expensive than Bubble, which happens more often than you would expect at the small end.
If it says migrate and you want the version with your actual workflows read rather than modelled, that is what the audit is for. It costs €500–750, it takes a week, and it is allowed to conclude that you should not migrate. That is the point of paying for it.