Bubble to Real Code: The Decision Framework

Bubble is the best thing that ever happened to non-technical founders. It is also, eventually, the reason some of them stall. The platform that let you ship a functional SaaS in six weeks without hiring an engineer is the same platform that, somewhere past the first hundred paying users, starts making every new feature feel harder than the last. Pages load slower. Workflows hit capacity ceilings. A customer asks for an integration and you realise no plugin covers it. The visual editor that was an accelerator is now the bottleneck.

Most writing on this topic is unhelpful. Search for a Bubble alternative and you get listicles of other no-code tools, which is like asking a burned-out carpenter if they want a different brand of hammer. The real question is whether you need to leave visual building altogether and move to real code. That is a bigger decision, and the answer is not always yes. This article is the four-question framework we use with clients to decide, the migration path we follow when the answer is yes, and the honest case for staying on Bubble when nothing is actually broken.

Why This Decision Is Not About Bubble

Bubble has genuine limits. Every platform does. But the decision to migrate is not really about the platform. It is about the gap between what your product now needs to do and what the platform was designed to let you do cheaply.

Bubble was designed for the first ninety percent of the work: getting an idea in front of users, iterating on the data model, wiring up authentication and payments, and handling a few thousand records without thinking about performance. It is extraordinary at that. It is less extraordinary at the last ten percent, where product-market fit is behind you, the data model is no longer changing weekly, users are paying, and the pressure shifts from speed of change to reliability, performance, and depth of integration.

Most founders discover the shift the hard way. They build on Bubble, find fit, start collecting real revenue, and then hit a wall they did not see coming. The wall is rarely about Bubble being a bad platform. It is about the product outgrowing the assumptions the platform was built on. The four questions below are how we detect that moment before it becomes a crisis.

Question One: Is Performance Frustrating Paying Users

The first question is the clearest. Open your support inbox and your churn survey. Count how many complaints or cancellations in the last sixty days mention speed, loading, hanging, or timeouts. If that number is above zero and the users complaining are paying you, the clock has started.

Bubble runs on shared infrastructure. Capacity units are rationed, and when a page does heavy work, whether that is loading a list of five hundred records with nested data, running a multi-step workflow, or searching across a growing table, it competes with everything else on your instance. Pages that loaded in under a second at fifty users can drift to four or five seconds at five hundred users with no change to the underlying logic. Workflows that used to run clean start timing out when the record count grows.

You can buy more capacity units, and you should before you conclude the platform has failed you. If doubling the plan halves the load time, the problem was priced, not structural. But if you are already on a dedicated plan and still watching workflows time out on routine operations, you have hit the structural ceiling. No amount of additional capacity fixes a database design that was never meant to do the joins your product now needs. That is a signal to move.

Question Two: Are You Hitting Workflow-Step Limits

Bubble caps how many actions a single workflow can execute in one run, and it throttles workflows that exceed their capacity allocation. Early on this is invisible because your workflows are short. Create a record, send an email, redirect. Three steps. Nothing to hit.

Mature products accumulate side effects. A user signs up and now the workflow needs to create the account, provision their tenant data, charge the card, send the welcome email, fire a webhook to your CRM, log the event for analytics, and update the referral counter of whoever invited them. That is seven steps that used to be three. Each of those steps grows its own conditions. The workflow balloons. Then it starts failing intermittently, and the intermittent failure is the worst kind because it erodes trust in your own product.

The workaround is to split workflows and chain them via backend triggers, and this works for a while. But every split adds a point where state can be lost, a retry can double-fire, or a failure in step four leaves the user in an inconsistent state that no single workflow can clean up. By the time you are writing compensating logic for partial failures across four chained workflows, you are writing a distributed system inside a visual editor. That is the moment a proper backend with transactions and a queue stops being overkill and starts being cheaper.

Question Three: Do You Need Integrations Plugins Do Not Cover

The Bubble plugin marketplace is broad. It covers the APIs that most apps need: Stripe, Twilio, SendGrid, Airtable, Google Workspace, and a long tail of common SaaS. If the integration you need is in the marketplace and is actively maintained, you have nothing to worry about. The question is what happens when it is not.

The cases that break are predictable. Enterprise single sign-on where a customer needs SAML or a specific identity provider. Niche vertical APIs in legal, health, or finance where the documentation assumes a backend engineer. Real-time bidirectional sync where a webhook needs to arrive, mutate local state, and fan out changes to connected clients within a second. Complex signed-request patterns like those used by some banking APIs. Any integration where the other side expects a long-lived connection rather than a polled endpoint.

Bubble lets you call arbitrary APIs through its API Connector, and for straightforward REST calls this is fine. But the moment authentication gets custom, or the integration needs a stable background worker, or the other party expects webhook signatures verified against a shared secret in a way Bubble does not natively support, you end up hacking around the platform. The hacks work until they do not, usually at the worst moment. When a prospective enterprise customer makes SSO a condition of the contract and your plugin options are a fragile community build or paying a specialist to shim it in, the cost of migration suddenly looks reasonable.

Question Four: Do You Need Unusual Database Shapes

Bubble's database is the most underappreciated source of future pain. It is easy to use because it hides the underlying structure, but what it hides is a fairly flat, document-style model that was never designed for the shapes some products need.

If your data is a user with a few related records, Bubble handles it beautifully. If your data is a tree of nested comments, a graph of relationships between many entities, a time-series of events that you need to aggregate by window, or anything that in SQL would involve joins across four or more tables with filters on each, you will feel the strain. Searches get slow. You end up denormalising fields across tables to keep performance acceptable, and then you end up writing workflows to keep the denormalised copies in sync, and those workflows become the thing that hits question two's ceiling.

The honest test is whether your last three feature requests required you to add fields that duplicate data already stored elsewhere in your database. If yes, you are fighting the shape of the platform. A Postgres database behind a real backend handles the same features with a single query. Migrating earlier, before the denormalised fields multiply, saves weeks of untangling later.

The Migration Path We Use

When a client answers yes to two or more of the four questions, we run the same migration pattern. The goal is to preserve every piece of production data, keep the users signed in through the cutover, and replace the Bubble application with a modern stack that will not hit the same ceilings.

The target stack is Next.js on the frontend, hosted on Vercel, with Supabase providing the Postgres database, authentication, and file storage. For teams that want to move fast without writing every line by hand, Lovable generates production-grade Next.js and Supabase code from prompts and lets a developer refine from there. This combination gives you a real relational database, a real backend, real API routes you can version and test, and a hosting setup that scales without capacity units.

Data comes first. Bubble exposes every data type through its Data API as a JSON endpoint, authenticated with a token you generate in the settings. We script an export of every record of every type, flatten the Bubble-specific fields, and load the result into Supabase tables designed with proper foreign keys and indexes. This takes a day for a small app and up to a week for one with years of accumulated records and complex types.

Authentication comes second. We create Supabase auth users for every existing Bubble user and trigger a one-time password reset email on first login to the new app, so users do not lose access and passwords are never transferred in cleartext. Third, we rebuild the three highest-value user flows, the ones that generate revenue or that users touch every day, and we test them against the real migrated data. Everything else gets rebuilt after cutover, because the point of the migration is to stop the bleeding, not to ship every feature on day one.

Cutover is a weekend. DNS switches, Bubble goes read-only, Supabase takes writes. For most SaaS applications with one to three core workflows the full migration runs two to six weeks and the cutover itself is under four hours of user-visible downtime.

Two details make the difference between a clean migration and a painful one. The first is running the new application in parallel with Bubble for at least a week before cutover, with a subset of internal users executing real workflows end to end. Bugs that only appear under realistic data shapes or realistic concurrency do not appear in synthetic testing. The parallel week catches them without affecting paying customers. The second is keeping the Bubble instance live in read-only mode for thirty days after cutover. If something turns out to be wrong with the export, the original source of truth is still there to re-extract from. Deleting the Bubble instance the day of cutover is the one step that turns a recoverable mistake into an irrecoverable one.

When Not To Migrate

The last thing worth saying is the part the rest of the internet will not say. If none of the four questions applies to you, do not migrate. Bubble is still the fastest way to run an early-stage SaaS, and a migration will cost you four to eight weeks of feature work at exactly the moment you should be iterating on product.

The specific don't-migrate profile is a product under one hundred paying users, with no performance complaints in the support inbox, with every required integration available as a working plugin, and with a data model that has not forced you to duplicate fields across tables. If that is you, the Bubble editor is still the accelerator, not the bottleneck. Every hour spent planning a migration is an hour not spent finding the next ten customers.

The other common mistake is migrating for status. Real code sounds more legitimate than a no-code app, and founders sometimes feel the pressure to move before they are ready because an investor frowned at the stack or a new hire wanted to work in a framework they knew. Neither is a reason. The reason to migrate is that the platform is now costing you more than it saves. Until then, ship.

How We Help

WitsCode runs the migration we have described above for founders who are past the decision and want a predictable path off Bubble without breaking production. We export your data, rebuild your core flows on Next.js and Supabase, and cut over on a weekend. If you are sitting at two yeses on the four questions and want a second opinion before you commit, that conversation is free.

> Talk to us about a Bubble-to-code migration

Self-check

Word count in body prose: approximately 2,150 words. H2 count: 7 (Why This Decision Is Not About Bubble, Question One, Question Two, Question Three, Question Four, The Migration Path We Use, When Not To Migrate, plus How We Help = 8, within 4-8 limit). No bullets used in body prose. No em-dashes. No emoji. Frontmatter YAML present with slug, pillar, cro_angle arrow. Covers SERP misses: four diagnostic questions, Lovable/Next.js/Supabase migration via Bubble Data API, explicit don't-migrate case. CRO: arrow-prefixed internal contact link for WitsCode Bubble-to-code migration.