Migrate from Bubble to custom code only when a hard platform limit blocks a feature you need, or the bill stays high after the build is fixed. Short of that, stay and fix the build, or move one blocked piece out and keep the rest on Bubble. A rebuild means writing the logic again, because Bubble doesn't export your app as code.
A big workload-unit bill alone usually means the app was built expensively. We'd audit the workload first, stay if the fix is cheap, and put whoever will own the new code at the centre of any rebuild.
Is it Bubble's limit or how your app was built?
Three symptoms bring founders here: the bill, the speed, or a feature you can't build. Each one has a different test, and only the third points at the platform.
Start with the numbers Bubble already keeps, in two places: the Server logs tab, which shows cost per action and per workflow, and the App metrics dashboard, which covers the last 30 days and splits Development from Live. Both environments count toward your bill, so a messy test version can cost real money.
If one workflow or one page dominates the logs, you have a build problem. If the logs look evenly spread and the bill is still high, or if a feature hits one of the hard limits below, you're looking at the platform.
What does staying on Bubble cost?
Bubble measures server work in workload units (WU), counted monthly and reset each month. Bubble's pricing page, checked on 5 November 2026, lists these plans at annual billing:
| Plan | Price per month | WU included |
|---|---|---|
| Free | $0 | 50,000 |
| Starter | $32 | 175,000 |
| Growth | $119 | 250,000 |
| Team | $349 | 500,000 |
| Enterprise | Contact Bubble | Custom |
Past your allowance, overage costs $0.30 per 1,000 WU unless you've bought a workload tier, a subscription that adds workload to your plan. Tiers exist only on Starter, Growth and Team. Bubble emails you at 75% and again at 100%, when overages begin.
You can switch overages off, but the app then goes offline until the next billing period, or until you re-enable overages or buy a tier. For a pre-traction app that's tempting. For a live product it's a worse outcome than a bill, so we'd only do it on a prototype nobody depends on.
What makes WU add up is the activity table:
| Activity | WU cost |
|---|---|
| Page load | 0.15 |
| Search, base cost | 0.3 |
| Each thing a search returns | 0.015 |
| Thing written or modified | 0.5 |
| Thing deleted | 0.1 |
| Server-side workflow action | 0.6 |
| Outbound API call | 0.1 |
A worked example: one list, three bills
Illustration: an app on Growth ($119 a month) gets 200,000 page loads a month, each running one search, and makes 20,000 database writes. Here's what happens as the search returns more things:
| Things returned per search | WU per page load | Monthly total | Overage bill |
|---|---|---|---|
| 20 (paginated) | 0.75 | 160,000 | $0 |
| 50 | 1.2 | 250,000 | $0 |
| 200 (no pagination) | 3.45 | 700,000 | $135 |
Writes add 10,000 WU in every row. The 200-row case lands 450,000 WU over the allowance, which is where the $135 comes from. The same product, with the same features, moves from nothing extra to $135 a month depending on how many rows one list loads. That's a fix, not a rebuild. Your real total depends on your app.
The four build mistakes that inflate the bill
A Bubble forum member who describes themselves as having built 100+ apps over eight years posted on 3 August 2026 that four mistakes cause most surprise bills. They report cutting bills by more than half without removing features. That's one builder's account, but the causes match how the activity table works:
- Searches inside other searches.
- Long lists loaded without pagination.
- A database not designed around what the front end searches for.
- Advanced filters that make Bubble do the sorting work.
If your Bubble builder can't tell you whether any of these apply, that's your first question to them.
Which limits can't you tune away?
These ceilings don't move however much you tidy the build:
| Limit | Value |
|---|---|
| Sorted search results | 50,000 things |
| Stored list | 10,000 items |
| Workflow timeout | 300 seconds |
| API Connector response | 50 MB |
| One Thing | 20 MB |
The forum thread names the kinds of work that push people off Bubble: heavy external data, files above the API cap, long-running tasks, sockets, and core features that depend on plugins. Check whether any of these is a core feature of your app, not a nice-to-have. If one is, that's a real reason to move.
Bubble publishes the limits but not what your app costs against them. Test your worst page, the biggest list or the longest job, and see whether it comes near a ceiling. If it doesn't, you don't have a limit problem yet.
If one piece is blocked, such as heavy API polling or a long job, there's a middle route. We'd move that one piece into a small separate service and keep the rest on Bubble, which avoids a full rewrite. Bubble's Data API can still serve your data to that service.
When staying on Bubble is the right call
Stay if you have no users yet, if the pain is a one-off spike, or if you want to keep building the product yourself. Stay too if the bill is fixed by pagination, as in the example above. The forum thread's author says fixing a high workload bill "will cost way less than leaving Bubble", and we agree.
Staying needs a trigger so it doesn't become drift. Name the limit that would make you leave, for example a feature that needs a job longer than 300 seconds, or a bill that stays high after the four fixes. Write it down and review it each quarter.
What actually moves if you rebuild?
Bubble's ownership page is blunt: Bubble apps can only run on the Bubble platform, and "there's no way of exporting your application as code". Bubble keeps ownership of the underlying code. You own your data and your design, and Bubble says it can help you export the design.
So data and design come with you. The logic does not: workflows, privacy rules and the way features behave have to be rebuilt from what the app does, not from what it's made of. Expect two systems running side by side until you cut over, since nobody switches a live app off on a Friday.
Two questions have no published answer, and a good builder should cover both before you sign.
What will it cost and take? Write down your feature inventory, ask two or three builders for a written fixed scope against it, and compare.
What happens to your users on day one? Bubble doesn't publish how passwords carry over to another system. Export a test copy of your User type (Bubble's table of your users), ask Bubble support, and agree in writing with the builder how people sign in after cutover. Also ask where user data will be stored and who can reach it, since the personal data moves with you.
Who should do the rebuild?
The code will exist for the first time, so the real question is who holds it afterwards.
| Option | Who keeps repo and hosting | Can you replace them? | What you must judge |
|---|---|---|---|
| Agency | You (in the contract) | Hard | Scope and handover terms |
| Senior contractor | You | Yes | Code quality and architecture |
| First engineer who owns it | You | Yes | Whether they're good |
Agency
An agency suits you when you have no technical lead and want a fixed scope. The catch is that knowledge walks out with them unless the contract moves the repository, hosting and keys to you. HighCircl's piece on choosing between an agency, freelancers or nearshore covers vendor choice and ownership terms.
Senior contractor
A contractor can build the first version and hand it over. You pay for the build, not a salary, but you need to be able to judge the result. An independent scoping review before you sign gives you a second opinion without a technical lead.
The engineer who will own it
If you plan to keep developing the product, the person who writes the rebuild should be the person who maintains it. The hard part is hiring someone whose code you can't review yourself. Don't rewrite everything at once either; the rewrite versus refactor guide explains the staged approach, and the other pieces in HighCircl's startup scaling guides cover leadership and early hires.
What this means for your Bubble decision
You're choosing a build model, not a platform. Before you spend on a rebuild, have whoever built your app pull the last 30 days of workload and name the three most expensive actions. If a pagination fix drops the bill, you've bought months. If a hard limit blocks a feature you need, you have a real reason to leave.
If you do rebuild, decide the owner first, then the scope. Whoever writes the new code should be someone you can replace, with the repository, hosting and keys in your name from day one. If that means hiring your first engineer, how to evaluate an engineer you can't code-review is the next read.
Hiring the engineer who will own your rebuild through HighCircl
Bubble can't hand you the code, so the person who writes it first is the person you'll rely on longest. If that's a hire, the hard part is judging candidates you can't test yourself. HighCircl only works with senior engineers, and within 72 hours you get a shortlist of 3-5 of them to compare side by side. See HighCircl's founding engineers service.
FAQ
Can I export a Bubble app as code?
No. Bubble's ownership page says Bubble apps can only run on the Bubble platform and there's no way of exporting your application as code. You own your data and design, so you can take those, but the application logic has to be rebuilt.
Does Bubble switch my app off if I hit the workload limit?
Only if you've turned overages off. With overages on, Bubble bills the excess at $0.30 per 1,000 WU. With them off, the app goes offline until the next billing period, or until you enable overages or buy a workload tier.
How much does a workload unit overage cost?
Without a workload tier, it's $0.30 per 1,000 WU. Tiers are available on Starter, Growth and Team, not Free. In the example above, a Growth app that loads 200 things per search instead of 20 pays $135 extra a month.
Should I hire or use an agency for the rebuild?
If you'll keep developing the product, hire or contract the person who will own it. An agency is reasonable for a fixed scope, but only if the contract hands you the repository, hosting and keys. Either way, get a written fixed scope from two or three candidates first.