From Bubble and Webflow to Custom Code: When to Migrate, and When to Stay

Two founders call us in the same week.

• The first has a Bubble app doing real revenue. They are convinced that moving to custom code would be reckless: too expensive, too slow, too dependent on developers.
• The second has a Webflow site whose CMS (content management system) holds their whole content operation. They feel safe because Webflow has an export button.

Both are wrong, in opposite directions. The first founder is already paying the migration cost, in monthly instalments they have stopped noticing. The second is holding an export button that does not export what they actually need.

We are a Gold-Tier Bubble agency. We build in Bubble, have certified Bubble developers on staff, and much of our work is improving Bubble apps rather than replacing them. So we have no commercial reason to tell you to leave.

Below is the threshold we use internally to decide whether a client should move to custom code, what the move involves, and when we tell founders to stay put.

"Easier to manage" is a claim about change, not about building

"Bubble is easier to manage" almost always means "Bubble was easier to build in." Those are different claims. Confusing 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
• Absorbing a pricing change you did not choose

No-code platforms optimise hard for the building cost and quietly shift the managing cost onto you. That trade is excellent early on. It is why we build MVPs (first versions of a product) in Bubble and will keep doing so.

But it stops being excellent at a specific, identifiable point. The rest of this article is about finding that point instead of guessing.

Where Bubble stops being easier to manage

Five things change, roughly in the order founders hit them.

1. Your hosting bill becomes a usage bill with no ceiling

Bubble prices on Workload Units (WU), a measure of how much server work your app does. As published on Bubble's pricing page in September 2026:

• Starter: 175,000 WU per month at $59/month, billed annually
• Growth: 250,000 WU at $209/month
• Team: 500,000 WU at $549/month

Go past your allowance and the standard overage rate is $0.30 per 1,000 Workload Units, with no cap. That is the clause 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. You find out afterwards.

Pre-purchased workload tiers lower the unit price, but not the underlying problem: your infrastructure cost is tied to how your app happens to be built, and you cannot analyse it the way you would analyse code.

2. You cannot take the application with you

Bubble does not offer source code export. You can:

• Get your data out via CSV (spreadsheet files) or the Data API
• Download your assets
• Read your workflows in the editor

You cannot get the application itself. This is not a criticism of Bubble specifically; it is built into the visual-development model. Every founder should price it in at the start rather than discover it during a fundraise.

The consequence: "we'll move later if we need to" is not a migration. It is a rebuild, and it will be quoted as one.

3. Basic engineering hygiene gets harder, not easier

In a code repository (the shared, versioned home for a product's code):

• A change is a "diff", a precise record of what changed.
• Someone else reads it, comments on a specific line, and approves it.
• If it breaks the live product, you undo that one change.
• Automated tests run on every change and tell you what broke before your users do.

None of this is exotic; it is standard practice. Visual builders do have branches and version history, but no line-level review, no automated regression testing (checks that old features still work), and no single-command undo.

As the app grows, these gaps compound. The fear of touching a working workflow becomes a management cost in itself.

4. Your hiring pool narrows to one platform

With a Bubble app, you are not hiring developers; you are hiring Bubble developers. That market is much smaller, priced accordingly, and does not overlap with the market you will need if you ever move.

Bubble-specific expertise is genuinely scarce and valuable. But if you are nervous about "depending on developers," notice that platform specialisation is a narrower dependency, not a wider one.

5. 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. 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 recurring ones trace back to this plugin 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 gives you.

What the export includes

According to Webflow's own help documentation:

• Static HTML for each page
• All the CSS (styling)
• The JavaScript that drives your interactions
• Your image and asset files

That is a real deliverable, and more than Bubble gives you.

What the export leaves out

• CMS content: Collection lists show their empty state, and Collection pages show nothing where your content was.
• Forms: including file upload and reCAPTCHA, do not work.
• Site search: does not work.
• Webflow Memberships: user accounts, logins and gated content are not included.
• Ecommerce content: not included.
• Localized pages: you get the primary language only.
• Password protection: protected pages stop being protected.

Read that list as a founder. The export gives you the part you could have rebuilt cheaply, the layout and styling. It withholds the parts that hold your business: your content database, lead capture, logged-in users and other languages.

You can export CMS and ecommerce records separately as CSV. That is your data, but it is not your CMS.

The honest summary

• Marketing pages only: you are genuinely flexible.
• A content operation, members area or store: you are much closer to Bubble's position, and the export button is not a plan.

Your vendor sets the terms

Webflow's pricing also moved in May 2026. The CMS and Business site plans were retired and merged into a single Premium plan: $25/month billed yearly or $39/month billed monthly, with 20,000 CMS items and 40 Collections. Existing sites were migrated automatically.

The numbers matter less than the shape of the event: your plan 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. Each deserves a straight answer.

"It will cost more every month."

Usually the opposite, once you are past the smallest plans. A modern custom web app runs on managed infrastructure priced like a utility:

• Vercel lists Pro at $20 per developer seat per month.
• 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 overage.

Custom costs are also visible: you can see which database query is expensive and fix it, which 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, but that comparison is unfair. 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 schedule risk in a migration is not writing code but data: untangling a data structure that grew organically inside a visual editor. That is why we start there.

"I'll be held hostage by whoever builds it."

This is exactly backwards. In a custom build you own a Git repository: every line, every change and every past version, in an account with your name on it.

If you fire your agency on a Friday, another team copies the repository on Monday and reads the whole history. That is the strongest supplier-independence position available.

The real hostage scenario is an application that exists only inside a platform that will not export it and can only be edited by that platform's specialists. If vendor dependence is your fear, custom code is the answer, not the cause.

"I won't be able to change anything myself."

You will change exactly the things you actually change: content, pricing, copy, images, email templates and feature flags (switches that turn features on or off). All of these belong in an admin panel or a headless CMS (a content editor separate from the app's code) built into the product.

What you lose is restructuring a workflow yourself at midnight. Be honest about how often you do that versus how often you ask a developer.

"Something will break and nobody will notice."

This fear has the least basis. Detecting breakage is something code is clearly better at:

• Automated tests run on every change.
• Staging environments (private copies of the app) let you see a change before customers do.
• Error monitoring alerts you before the support ticket arrives.
• Rollback: a bad release is undone in one command.

The uncomfortable truth: a mature Bubble app has fewer of these safety nets, not more.

Pros and cons, stated plainly

This is not one-sided. Here is the honest ledger.

What Bubble and Webflow give you

• Speed: a working product in weeks rather than months
• Simplicity: one vendor instead of five
• No infrastructure burden: no servers, deployment or on-call duty
• No handoff loss: a direct path from design to live
• Cheap validation: test a market before spending real money
• Founder control (Bubble): a non-engineer can make product changes without a release cycle

These are real advantages, and the reason we keep building this way.

What they cost you

• Unpredictable running costs that scale with usage in ways you cannot analyse
• Limited portability: none for the application (Bubble), or partial and excluding your database and users (Webflow)
• Weaker safety nets: review, testing and rollback fall short of any code repository
• A narrow hiring market restricted to platform specialists
• Plugin dependency with no maintenance guarantees
• A performance ceiling: you cannot optimise what you cannot see

What custom code gives you

• Ownership: an asset you own outright and can hand to anyone
• Visible costs you can understand and optimise
• Freedom: unrestricted integration and performance work
• Safety nets: tests, staging and instant rollback
• A hiring pool measured in millions
• Enterprise readiness: you can answer procurement questions about where data sits and who touched it

What custom code costs you

• A real upfront build
• Ongoing ownership: someone, your team or your agency, must handle deployments and monitoring
• Slower small content changes, unless the admin tooling is built well
• No more personal rewiring of a workflow on a Saturday

In practice: if the no-code column still describes your situation, stay. That is a legitimate outcome, and it is the outcome for most companies reading this.

The signals that it is actually time

Not vibes. These are what we look for, and any two together usually settle it:

1. Unforecastable bills: your platform bill has become a variable, and workload overages are a line item somebody asks about.
2. A blocked feature: something customers actively want is not hard or expensive but structurally impossible on the platform.
3. Unfixable performance: the remaining optimisations sit below the layer you can reach.
4. A failed security questionnaire: an enterprise deal has produced questions you cannot answer honestly.
5. Hiring friction: the developers you want will not take a role where the product is a visual builder.
6. 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 someone else's backend.

The earliest signal is the easiest to miss

That last one is usually the first to appear, and founders explain it away. When your engineers start putting the interesting parts elsewhere, the migration has already begun without anyone deciding.

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

We say this to paying clients regularly. Do not migrate if:

• You have not found product-market fit. You would be rebuilding a specification that is still changing, the most expensive possible time to do it.
• Your platform bill is small and predictable. There is nothing to fix.
• The pressure comes from an investor or advisor, not from something your product cannot do. Name the missing capability first; "it's not scalable" is not a requirement.
• Your app is an internal tool with twenty users. The economics will never justify it.
• Speed of iteration is about to matter most: a launch, a funding round, a seasonal peak. Postpone. A migration during a sprint gets you a delayed migration and a missed sprint.

If you are 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

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

Move one piece at a time and keep the old system running until the last piece is gone.

1. Start with the data model. This is where the real work is. Data structures grown inside a visual editor carry unwritten assumptions: fields that mean different things depending on a record's state, relationships stored as text, data checked only by whichever workflow created it. Mapping and cleaning this is typically the longest, least glamorous phase.
2. Run the new backend alongside the live app. Sync data into it continuously without serving anything from it yet. This proves the model against real production data, not a snapshot.
3. Move surfaces one at a time, low-risk first. Start with read-heavy parts such as marketing pages, public listings or a customer dashboard. Route traffic so both systems serve parts of the same domain, and users never see a switchover.
4. Keep the platform as the admin interface for as long as it is useful. Teams skip this step, yet it removes most of the risk. Your internal team keeps working in the tool they know while customer-facing parts move underneath them.
5. Move login (authentication) deliberately and late, with a plan for existing sessions and passwords.
6. Switch DNS (where your domain points) last. Keep the old system running and reversible for a full billing cycle afterwards.

Cost and duration

We do not publish a range, because an honest one would be too wide to be useful.

Price is driven by the number of distinct workflows and third-party integrations, not by pages or screens. A ten-screen app with forty workflows and six integrations is a bigger job than a forty-screen app with simple data entry behind it.

In practice: 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 stand, do three things before talking to anyone about a rebuild:

1. Split your invoices. Pull the last six months of platform invoices and separate the fixed subscription from usage charges. If usage is growing faster than revenue, you have your answer, in numbers rather than feelings.
2. Name the blocker. Write down, in one sentence of product terms, the specific capability you cannot ship. If you cannot write that sentence, you are not ready to migrate, and you should be relieved rather than disappointed.
3. Run an export drill. Export your data today, on a normal Tuesday. Not because you are leaving, but because seeing exactly what comes out, and what does not, turns vague lock-in anxiety into a short, factual list. For most Webflow teams, this 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.