On this page 6 sections
Rebuild your Bubble app in code when it crosses one of four thresholds: a workload bill that climbs past roughly 5,000 daily active users, more than about five integrations, page speed your users won’t accept, or a privacy-rule surface too big to audit. Until then, stay. Bubble is a legitimate production platform.
We know because we build on it. Glibzter, a two-sided coaching platform with assessments, video lessons, 1:1 booking and Stripe payments, runs on Bubble, and it works. But every Bubble app we’ve seen live past year two hits the same wall in roughly the same order, and by the time the team notices, they’ve usually been paying for it a while. This piece is about the point where staying costs more than leaving, and how to leave without freezing the product.
The four thresholds that decide it
Every Bubble migration we’ve done as part of our Code Rescue work was triggered by at least one of these four. Two or more, and the decision is already made; the founder is just catching up to it.
User count. Bubble’s workload model meters the server work your app does - page loads, searches, workflows - in workload units (WU) per month. Each plan includes an allowance (175K WU on Starter up to 500K on Team), and past it you buy a workload tier or pay overages. Our rule of thumb, not a Bubble limit: under ~1,000 daily active users you almost never notice. Between 1,000 and 5,000 you start pushing plans and tiers up. Past ~5,000 the workload bill stops being competitive with a small server. This threshold shows up as a bill growing faster than revenue, driven by exactly the users you don’t want to lose - the most engaged ones.
Integration depth. In our experience Bubble handles up to about five external integrations comfortably through the API Connector. Past that you’re managing retries, rate limits, secret rotation, error visibility and upstream API versions - Bubble’s weakest area. If your product is mostly integrations (say, a marketing tool with 30 destinations), Bubble stops fitting somewhere around the tenth.
Page speed. Bubble page loads sit in the 1.5-4 second range in our measurements, because a Bubble page has to load the Bubble runtime and hydrate its data sources before it’s usable. It will not match a hand-tuned frontend on first load. If your users are consumers and your competitors load in 400ms, you have a gap no amount of Bubble tuning will fully close. If your users are B2B and your reference point is Salesforce, you’re fine.
Audit surface. Bubble’s privacy rules are the correct primitive but a fragile control plane. Every new data type is a new privacy-rule decision, and the failure mode is silent: a data type with no privacy rules is publicly visible to anyone, logged in or not. It’s one of the most common findings in the Bubble security audits we run. It’s fixable, but the cost of continuous auditing rises with every data type you add.
If none of these are biting yet, stop reading. Ship features on Bubble. The rest of this piece is for teams sitting on at least one of them.
The bad plan: rewrite everything at once
The most common way to leave Bubble is also the worst: pick a stack, hire two engineers, freeze Bubble development, rewrite. Twelve weeks in, the rewrite is a little over half done, the Bubble product has three months of piled-up user requests, and someone starts talking about “just a few more sprints.”
This is the plan that kills migrations. What kills it isn’t the technical work - it’s the freeze. A frozen product loses ground to the market and to internal frustration. By month five, whoever green-lit the rebuild is under pressure to justify it, and the incentives flip against finishing.
The good plan: move it one piece at a time
We plan every Bubble migration as a strangler-fig operation. Bubble stays running. New surface - starting with the hottest workflows or the most integration-heavy feature - moves to code. Users hit either the Bubble UI or the new UI depending on which part of the product they’re in, and both sides read the same data, kept in sync from Bubble.
In practice:
-
Pick the piece. Usually one of: a compute-heavy workflow (the LLM feature, the pricing engine, the recommendation surface), the integration layer, or an internal admin dashboard. NOT the auth system - auth is the last thing you should touch in a migration, and the piece we’ve watched teams break more than any other.
-
Extract the data model to Postgres. You can’t connect to Bubble’s database directly. Export via the Data API, land it in your own Postgres, and keep it in sync one way (the new side only reads) for the first few weeks. Once the new surface is stable, add write-back.
-
Ship the piece behind a feature flag. New Postgres-backed code, same URL structure, same visible UI, gated by a flag on the user record in Bubble. Put a proxy in front of both apps (Cloudflare or similar) so the same URL can route to Bubble or the new code per user. Turn it on for 5% of users. Watch the metrics.
-
Bring one more workflow across. Repeat every 2-4 weeks. The Bubble surface shrinks and the code surface grows. Somewhere between three and six workflows in, the whole app is on the new side except for the admin - and by then the admin is easy because the rest is stable.
-
Cut over the admin. Retool or a hand-rolled admin dashboard on top of the same Postgres. This is the thing every migration forgets to plan; budget one to four weeks for it - a week if you lean on Retool, closer to a month for a custom admin.
Nothing in this plan needs Bubble development to freeze. That’s the whole point.
How to decide, in five bullets
- Under 1,000 DAU, no compliance surface, five or fewer integrations. Stay on Bubble. Ship features.
- 1,000-5,000 DAU, growing steadily, some slow workflows. Optimize on Bubble. Move the two slowest workflows to server-side functions called from the API Connector. That buys 12-18 months.
- 5,000+ DAU or a compliance boundary (SOC 2, HIPAA, PCI, GDPR data processor). Start planning the migration. Do NOT freeze Bubble. Plan a piece-by-piece move, starting with one specific part.
- Any DAU, if your product is mostly integrations or is latency-sensitive. Bubble was probably the wrong platform to begin with. Migrate now, while the app is still small enough to redesign.
- Any DAU, if you’re about to raise or exit. Buyers and investors mark you down for “Bubble-based” more than the risk warrants, and technical diligence will ask about platform lock-in. If you’re 6-12 months from a raise, migrate first.
What to avoid
- Don’t move to a hosted “code” platform with the same lock-in as Bubble. If you’re leaving Bubble for something proprietary that will eventually give you the same problems, you’re paying the migration cost twice.
- Don’t rewrite the URL structure. Every changed URL is one Google has to recrawl and reindex, and rankings can fluctuate while it does. Match URLs 1:1, 301 anything that has to move, and keep those redirects for at least a year, as Google recommends.
- Don’t skip observability on the new stack. Bubble hides the failure modes; when you leave it, you inherit the responsibility. Set up error tracking (Sentry), logs (any of Axiom, Grafana Loki, Datadog), and uptime monitoring before you cut a single user over.
- Don’t underestimate the admin work. Budget one to four weeks: a week if a tool like Retool covers what your team needs, closer to a month if you’re rebuilding a custom admin your team spent months perfecting in Bubble. Plan for it.
How Zeroic runs a Bubble exit, one piece at a time
Our Code Rescue engagement is a fixed 2-4 week block, from $6,000 and starting with a 3-day review, that rebuilds one clear piece of a Bubble app (or a Lovable, Bolt or Cursor MVP - the pattern is the same) to production grade. Senior engineers, one deliverable, deployed to production. It’s built for Bubble-founded products whose founders know they want to leave the platform but can’t afford to freeze. More on how we run these: Bubble to code migration.
The engagements we say no to are the ones where the team wants a wholesale replacement in six weeks. That’s a green-field MVP with an extra dependency, and it should be scoped as an MVP Sprint instead.
Before you engage anyone, we usually recommend a Security or Performance audit first. It starts at $1,000, takes 1-2 weeks, and surfaces the specific issues driving your urge to migrate. Sometimes the answer is “you have three privacy-rule holes and one workflow that’s 40x slower than it should be” - fix those and stay on Bubble for another year. That’s a legitimate outcome, and it’s cheaper than a rewrite.
The right time to leave Bubble is when your growth makes one of the four thresholds inevitable within twelve months. If that’s you, we can talk it through.
Frequently asked questions
- Is Bubble production-ready?
- Yes, for a specific band: public-facing marketing sites, internal tools, single-tenant SaaS under roughly 5,000 active users (our rule of thumb), and MVPs that need to ship in weeks. It stops being the right platform when you cross one of the four thresholds in this piece: workload cost, integration depth, page speed, or audit surface.
- How long does it take to migrate a Bubble app to code?
- Six to sixteen weeks for a mid-sized app, depending on integration surface and whether you rebuild feature for feature or use the migration as a redesign. Done one piece at a time, each block is 2-4 weeks. We usually recommend the redesign, because Bubble apps carry decisions that made sense on Bubble and don't need to survive the port.
- Can we stay on Bubble and just fix the slow parts?
- Sometimes. Move the two hottest workflows to a server-side function called from Bubble and keep the rest. In our experience this buys 12-18 months, and it's cheaper than a rewrite. It doesn't work if the data model itself is the bottleneck, because then every workflow is slow for the same reason.
- What's the biggest hidden cost of leaving Bubble?
- Rebuilding the admin UI. Bubble's data editor does a lot of quiet work, and leaving it means either building your own admin dashboard or picking a tool like Retool. Budget one to four weeks for it - a week if you lean on Retool, closer to a month if you rebuild a custom admin.
- Do we lose SEO when we migrate?
- Only if you change URLs. Keep the URL structure identical, 301 anything that has to change, and match content one to one on the initial cut. Done that way, rankings usually hold. If URLs do change, Google says it can take a few weeks or more for a medium-sized site to settle on the new ones.
Prashant Abbi