# What a Bubble rebuild costs, and what drives it > Nobody can price a Bubble rebuild from a screenshot. See the four things that set the number, and how to compare it against what staying already costs you. - Author: Marlon Trettin - Published: 2026-08-21 · Updated: 2026-08-21 - Language: en - Canonical: https://yowpi.com/en/blog/what-a-bubble-rebuild-costs --- A Bubble rebuild is priced by the logic you accumulated, not by the app you can see. Four things set the number: how many workflows and branches exist, how many external integrations they touch, how tangled the data model became, and how many permission rules per role you have. Screen count barely moves it. ## TL;DR - Anyone who quotes a Bubble rebuild from a screen recording is guessing. The price lives in the workflow inventory, which is not visible from the outside. - Screen count misleads. A large share of screens are variations on the same handful of operations. - The comparison that matters is against the cost of staying, and part of that cost is documented: [$0.30 per 1,000 workload units](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) in base overage without a tier. - Migrating is the cheapest moment to delete what you no longer need. That deletion is the biggest single lever on the number. ## Why won't anyone give you a number up front? Because the number is not knowable from the outside, and a number given without the inventory is a sales tactic rather than an estimate. Bubble's own documentation explains why. The platform states that [apps run only on the Bubble platform and there is no way to export the application as code](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership). So the rebuild is not a port. It is a reimplementation of business logic that currently exists only inside a visual editor, and nobody can size it by looking at the front end. You will find price ranges published online. Treat them the way you would treat a construction quote given over the phone: the honest ones come with the disclaimer that the range is wide enough to be useless, and the confident ones are the ones to worry about. We do not publish a range for this reason, and any studio that gives you one before counting your workflows is pricing a different project than yours. What you can get quickly, and should insist on, is the inventory itself. Counting is cheap. Guessing is what gets expensive later. ## What actually sets the price? Four things, in rough order of weight. **Workflows and their branches.** Every workflow is logic somebody has to read, understand and rewrite, including the branches that only fire in edge cases. Branch count matters more than workflow count, because the branches are where the undocumented business rules hide. **External integrations.** Each API connection carries its own authentication, error handling, retry behavior and failure modes. Integrations are also where migration risk concentrates, because the other side does not care that you are rebuilding. **Data model complexity.** Not table count, but how much of the model is accidental. Lists that should have been relationships, option sets that grew into tables, fields that exist because a workflow needed somewhere to put a value. Untangling that is the work with the longest tail, because everything built afterward inherits the decision. **Permission rules per role.** Privacy rules are quiet and load-bearing. They are also the thing most likely to be reproduced incorrectly, because the original intent is rarely written down anywhere. Notice what is not on the list. Screen count, which is what most people lead with, is a design task once the logic is settled, and design is cheap next to logic that has to be reasoned about twice. ## How do you compare it against staying? Put both on the same monthly line, because a rebuild is a one-time number and staying is a recurring one, and comparing them in different units is how the decision gets postponed. The cost of staying has a documented part and an undocumented part. The documented part is workload: Bubble tracks [twelve activity types](https://manual.bubble.io/help-guides/workload/understanding-workload) feeding the monthly total, and the [pricing FAQ](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) sets the base overage at $0.30 per 1,000 units when you have no workload tier subscription. Pull twelve months of that and project it against your growth curve rather than your current usage. The undocumented part is what the constraint costs the business: the feature nobody built because it would have been expensive, the manual step that stayed manual, the report that gets exported and finished in a spreadsheet. That number is larger than the invoice in most operations we see, and it never appears on any invoice. There is a third option that gets skipped, and it is often the right first move. In the [Colo Saúde platform](/en/cases/colo-saude) the app was stabilized on Bubble and its consumption cut by 60 percent before any rebuild started. Part of a workload bill is architecture rather than platform, which means part of the pressure to migrate can be removed without migrating. Buying runway that way changes the rebuild from an emergency into a plan. ## How do you make the number smaller? Delete first. Systems that grew inside a visual editor accumulate workflows that exist because somebody needed them once, and migration is the rare moment when deleting them is politically possible. Every workflow you retire is one you do not scope, build, test or maintain. Then sequence by revenue. Rebuilding the whole app before shipping anything is the most expensive path and the one with the worst failure mode. Cut over per workflow, starting with the ones the business depends on, and let the rest keep running where it is. Then decide what stays simple. Not every part of an operation deserves custom software, and a rebuild is a good moment to notice which internal tool could be a spreadsheet with rules, or stay on the platform indefinitely because it works and nobody touches it. Scoping the work against the inventory rather than against the screens is what separates a project that lands from one that doubles. The sequence for running it is in [migrating from Bubble to custom code](/en/blog/migrating-from-bubble-to-custom-code). ## Frequently asked questions **Can you estimate my rebuild from a demo of the app?** Not honestly. A demo shows the screens, and the screens are the cheap part. An estimate needs the workflow and branch count, the integration list, the data types with their relationships and the permission rules per role. Producing that inventory usually takes days, not weeks. **Is rebuilding cheaper than building custom from the start?** Usually not cheaper in absolute terms, but that comparison is not available to you any more. What is available is rebuilding now against rebuilding later at a larger size, and later is reliably more expensive, because the logic keeps accumulating while you decide. **Should I fix the app on Bubble first?** Often yes, and it is the least discussed option. If the pressure is workload cost, part of that bill comes from how the app was built. Stabilizing buys runway, and runway is what decides whether the rebuild happens calmly or under a deadline set by an invoice. ## Next step If you want the inventory before you want a number, an Operational Architecture Diagnostic is a 30 minute conversation to map what your app actually contains and what it would take to move it. [Book a conversation](/en/contact).