Two founders call us in the same week. The first one has a Bubble app doing real revenue and is convinced that moving to custom code would be reckless — too expensive, too slow, too dependent on developers. The second one has a Webflow site with a CMS holding their whole content operation and is convinced they are safe, because Webflow has an export button.
Both are wrong, and they are wrong in opposite directions. The first founder is already paying the migration cost, just in monthly instalments they have stopped noticing. The second one is holding an export button that does not export the thing they actually need.
We are a Gold-Tier Bubble agency. We build in Bubble, we have certified Bubble developers on staff, and a meaningful share of our work is making Bubble apps better rather than replacing them. That is exactly why this article is worth reading: nobody on this side of the argument has a commercial reason to tell you to leave. What follows is the threshold we use internally to decide whether a client should move to custom code, what the move actually involves, and the cases where we tell founders to stay put.
"Easier to manage" is a claim about change, not about building
The sentence "Bubble is easier to manage" almost always means "Bubble was easier to build in." Those are different claims, and conflating them is the single most expensive mistake in this decision.
Building is a one-time cost. Managing is what you do for the next four years: shipping changes, onboarding the person who ships them, finding out why something broke at 2am, proving to an enterprise buyer that your data is handled properly, and absorbing a pricing change you did not choose.
No-code platforms optimise hard for the first cost and quietly shift the second one onto you. That trade is genuinely excellent early — it is why we build MVPs in Bubble and why we will keep doing it. It stops being excellent at a specific, identifiable point. The rest of this article is about identifying that point rather than guessing at it.
Where Bubble stops being easier to manage
These are the five things that change, in roughly the order founders hit them.
Your hosting bill becomes a usage bill with no ceiling. Bubble prices on Workload Units. As published on Bubble's pricing page in September 2026, Starter includes 175,000 WU per month at $59/month billed annually, Growth includes 250,000 at $209/month, and Team includes 500,000 at $549/month. Go past your allowance and the standard overage rate is $0.30 per 1,000 Workload Units, with no cap. That last clause is the one that matters. A traffic spike, a badly written recurring workflow, or a customer running an aggressive export can turn a fixed cost into a variable one overnight, and you find out after the fact. Pre-purchased workload tiers bring the unit rate down, which helps with the price but not with the underlying property: your infrastructure cost is now coupled to how your app happens to be built, and you cannot profile it the way you would profile code.
You cannot take the application with you. Bubble does not offer source code export. You can get your data out via CSV or the Data API, you can download your assets, and you can read your workflows in the editor. You cannot get the application. This is not a criticism of Bubble specifically — it is a structural property of the visual-development model, and every founder should price it in at the start rather than discover it during a fundraise. The practical consequence is that "we'll move later if we need to" is not a migration, it is a rebuild, and it will be quoted as one.
Ordinary engineering hygiene gets harder, not easier. In a code repository, a change is a diff. Someone else reads that diff, comments on a specific line, and approves it. If it breaks production, you revert one commit. A test suite runs automatically on every change and tells you what you broke before your users do. None of this is exotic; it is baseline practice. In a visual builder you are working with branches and version history that are real features but do not give you line-level review, automated regression testing, or a revert that is a single command. As the app grows, the absence compounds: the fear of touching a working workflow is itself a management cost.
Your hiring pool narrows to a platform. When your product is a Bubble app, you are not hiring developers, you are hiring Bubble developers. That market is much smaller, it is priced accordingly, and it does not overlap with the market you will need if you ever do move. The same is true in reverse for a while — Bubble-specific expertise is genuinely scarce and genuinely valuable — but the direction of travel matters. A founder who is nervous about "depending on developers" should notice that platform specialisation is a narrower dependency, not a wider one.
Third-party plugins become someone else's roadmap. Most non-trivial Bubble apps depend on plugins. Each one is a small vendor relationship with its own maintenance record, and a plugin that stops being updated becomes your problem on a schedule you do not control. We have written separately about the security issues that show up in Bubble apps and how to solve them; several of the recurring ones trace back to this dependency layer.
Why Webflow's export button is not the exit you think it is
Webflow founders usually feel safe, because unlike Bubble, Webflow has code export. It is worth being precise about what that button actually hands you.
According to Webflow's own help documentation, a code export includes static HTML for each page, all the CSS, the JavaScript that drives your interactions, and your image and asset files. That is a real deliverable and it is more than Bubble gives you.
Here is what it does not include. CMS content is not exported with the code — Collection lists render their empty state and Collection pages show nothing where your bound fields were. Forms, including file upload and reCAPTCHA, do not work on an exported site. Site search does not work. Anything built on Webflow Memberships — user accounts, logins, gated content — is not included. Ecommerce content is not included. Localized pages and content are not included; you get the primary locale only. Password-protected pages stop being protected.
Read that list again as a founder rather than as a developer. The export gives you the part you could have rebuilt cheaply — the markup and the styling — and withholds every part that actually holds your business: your content database, your lead capture, your logged-in users, and your other languages. You can export CMS and ecommerce records separately as CSV, which is your data but is not your CMS.
So the honest statement is that Webflow gives you portability for a brochure site and something much closer to Bubble's position for anything with a database behind it. If your Webflow build is marketing pages, you are genuinely flexible. If it is a content operation, a members area, or a store, the export button is not a plan.
Webflow's pricing also moved in May 2026: the CMS and Business site plans were retired and merged into a single Premium plan, listed at $25/month billed yearly or $39/month billed monthly, with 20,000 CMS items and 40 Collections, and existing sites migrated automatically. Note the shape of that event rather than the numbers. Your plan structure changed because your vendor decided it should. That is the deal on every managed platform, and it is fine — as long as you knew you had signed it.
The fears about custom code, answered one at a time
Founders rarely say "I don't want custom code." They say one of five specific things, and each one deserves a straight answer rather than reassurance.
"It will cost more every month." Usually the opposite, once you are past the smallest plans. A typical modern custom web app runs on managed infrastructure that is priced like a utility: Vercel lists Pro at $20 per developer seat per month, and Supabase lists Pro at $25 per month including 8 GB of database. Call it $45 to $150 a month for a serious production stack with room to grow. Bubble's Growth plan alone is $209 a month billed annually before any workload overage. The custom stack's costs are also legible — you can see which query is expensive and fix it, which is precisely the thing Workload Units make hard. What costs more in custom code is the build, not the running.
"It takes forever." It takes longer than the Bubble build did, and that comparison is unfair, because you are no longer building an unknown product. The second build has a specification: your existing app. There is no discovery phase, no feature debate, and no market risk in the scope. Most of the schedule risk in a migration is not writing code, it is data — reconciling a model that grew organically inside a visual editor. Which is why we start there.
"I'll be held hostage by whoever builds it." This one is exactly backwards, and it is worth being blunt about. In a custom build you own a Git repository. Every line, every change, every historical version sits in an account that has your name on it. If you fire your agency on a Friday, another team clones the repository on Monday and reads the whole history. That is the strongest supplier-independence position available to you. The hostage scenario is the one where your application exists only inside a platform that does not export it and can only be edited by specialists in that platform. If vendor dependence is your fear, custom code is the answer to it, not the cause.
"I won't be able to change anything myself." You will change exactly the things you actually change. In practice that is content, pricing, copy, images, email templates and feature flags — and all of it belongs in an admin panel or a headless CMS that is part of the build. What you lose is the ability to restructure a workflow yourself at midnight. Be honest about how often you do that versus how often you ask a developer to.
"Something will break and nobody will notice." This is the fear that has the least basis. Breakage detection is one of the things code is unambiguously better at: automated tests run on every change, staging environments let you see the change before customers do, error monitoring tells you about the failure before the support ticket does, and a bad deploy is reverted in one command. The uncomfortable truth is that a mature Bubble app has fewer of these safety nets, not more.
Pros and cons, stated plainly
We are not going to pretend this is one-sided. Here is the honest ledger.
What Bubble and Webflow genuinely give you: a working product in weeks rather than months; one vendor instead of five; no infrastructure, deployment, or on-call burden; a design-to-live path with no handoff loss; the ability to validate a market before you have spent real money; and, on Bubble specifically, the ability for a non-engineer founder to make product changes without a release cycle. These are real advantages and they are the reason we keep building this way.
What they cost you: running cost that scales with usage in a way you cannot profile; no application portability (Bubble) or partial portability that excludes your database and your users (Webflow); weaker review, testing and rollback than any code repository provides; a hiring market restricted to platform specialists; a dependency on third-party plugins with no maintenance guarantees; and a ceiling on performance tuning, because you cannot optimise what you cannot see.
What custom code gives you: an asset you own outright and can hand to anyone; costs that are legible and optimisable; unrestricted integration and performance work; the standard safety net of tests, staging and instant rollback; a hiring pool measured in millions; and the compliance posture that enterprise procurement asks for, because you can answer questions about where data sits and who touched it.
What it costs you: a real upfront build; the need for someone to own deployments and monitoring, whether that is your team or your agency; a slower path for small content changes unless the admin tooling is built well; and the loss of the founder's ability to rewire a workflow personally on a Saturday.
If you read those four lists and the no-code column still describes your situation, stay. That is a legitimate outcome of this decision and it is the outcome for most companies reading this.
The signals that it is actually time
Not vibes. These are the things we look for, and any two of them together usually settle it.
Your platform bill has become a variable you cannot forecast, and workload overages are now a line item somebody asks about. A feature your customers are actively asking for is not buildable — not hard, not expensive, but structurally unavailable on the platform. Your performance problems have stopped being fixable, because the remaining optimisations are below the layer you can reach. An enterprise deal has produced a security questionnaire you cannot answer honestly. You are hiring, and the developers you actually want will not take a role where the product is a visual builder. Or, most telling of all, your team has begun routing around the platform — the real logic is quietly moving into external services, and the platform has become an expensive user interface in front of somebody else's backend.
That last one is worth dwelling on, because it is usually the earliest signal and the one founders explain away. When your engineers start putting the interesting parts somewhere else, the migration has already begun without a decision being made. We wrote up what that drift costs over a year in our breakdown of a stacked no-code setup, where the monthly number is the least interesting part of the damage.
When not to migrate
Equally concrete, and we say this to paying clients regularly.
If you have not found product-market fit, do not migrate. You will be rebuilding a specification that is still changing, which is the most expensive possible time to do it. If your platform bill is small and predictable, there is nothing to fix. If the pressure to move is coming from an investor or an advisor rather than from something your product cannot do, get specific about the missing capability first — "it's not scalable" is not a requirement. If your app is a genuine internal tool with twenty users, the economics will never justify it. And if you are about to enter a period where speed of iteration matters more than anything else — a launch, a funding round, a seasonal peak — postpone. A migration during a sprint is how you get both a delayed migration and a missed sprint.
If you are earlier than all of this and still choosing your first approach, the upstream question is covered in our comparison of no-code versus full-code development.
How the migration actually runs
The version that fails is the big-bang rewrite: a parallel team rebuilds everything for six months while the live product freezes, then everyone switches over on one terrifying evening. Avoid it.
The version that works moves one surface at a time and keeps the old system running until the last piece is gone.
Start with the data model, because that is where the real work is. A schema that grew inside a visual editor carries assumptions that were never written down — fields that mean two different things depending on a record's state, relationships expressed as text, data validated only by the workflow that happened to create it. Getting this mapped and cleaned is typically the longest phase and it is entirely unglamorous.
Then stand up the new backend alongside the live app and sync data continuously into it, without serving anything from it yet. You are proving the model against real production data rather than against a snapshot.
Then move surfaces individually, starting with the ones that are read-heavy and low-risk: marketing pages, public listings, a customer-facing dashboard. Route traffic at the edge so both systems serve parts of the same domain, and your users never see a cutover.
Keep the platform as the admin interface for as long as it is useful. This is the step teams skip, and it is the one that removes most of the risk. Your internal team can keep working in the tool they know while the customer-facing surfaces move underneath them.
Move authentication deliberately and late, with a migration path for existing sessions and credentials, and cut DNS over last. Keep the old system warm and reversible for a full billing cycle afterwards.
On cost and duration: we do not publish a range, because an honest one would be so wide as to be useless. The price is driven by the number of distinct workflows and third-party integrations you have, not by how many pages or screens you see — a ten-screen app with forty workflows and six integrations is a larger job than a forty-screen app with simple CRUD behind it. The fastest way to get a real number is to have someone count the workflows.
What you should do this week
If you are unsure where you sit, do three things before you talk to anybody about a rebuild.
Pull the last six months of platform invoices and separate the fixed subscription from the usage charges. If the usage line is growing faster than your revenue, you have your answer and you have it in numbers rather than in feelings.
Write down the specific capability you cannot ship. One sentence, in product terms. If you cannot write that sentence, you are not ready to migrate and you should be relieved rather than disappointed.
Export your data today, on a normal Tuesday, as a drill. Not because you are leaving, but because knowing exactly what comes out — and what does not — converts a vague anxiety about lock-in into a short, factual list. For most Webflow teams that drill is the moment the export button stops looking like an exit.
The decision is not no-code versus custom code. It is whether the trade you made at the start is still the trade you would make today. Bubble and Webflow buy you speed at the price of ownership, and that is a genuinely good deal right up until the moment your constraint stops being speed.
Founders get this wrong symmetrically. The ones who stay too long mistake a low build cost for a low management cost, and keep paying for the difference in workload overages, in features they cannot ship, and in a hiring market that keeps narrowing. The ones who are afraid to move are usually afraid of dependence — which is the one thing a repository they own actually fixes.
We build in both, which is why we will say the unprofitable thing: most companies reading this should stay where they are, and the ones who should move can name the capability they cannot ship in a single sentence. If you can write that sentence, the next step is counting your workflows and integrations, not getting a quote for a rewrite.
Not sure which side of the line you are on? Talk to our team — we will look at the app you actually have and tell you honestly whether it is worth moving.
“"Bubble is easier to manage" almost always means "Bubble was easier to build in." Building is a one-time cost. Managing is what you do for the next four years.”
