The pilot worked with a small request register. Now the dashboard searches more records, a nightly import runs, and staff reopen the page throughout the day. Bubble pricing depends partly on that activity. Counting registered users will not tell you how much server work the application performs.
Choose the app plan whose publishing and collaboration features you need, then size workload from the running application. Consider a workload add-on before upgrading the whole plan solely for capacity. Stay with Bubble when the workflow, operating cost, and hosting arrangement meet your requirements. If independently deployable source code is mandatory, resolve that requirement before building because Bubble documents a rebuild when leaving its runtime.
Select Web, Mobile, or the combined package first
Bubble’s pricing page distinguishes Web, Mobile, and Web & Mobile projects. A browser app used on a phone is not automatically a native app-store deployment. The worked example below uses the combined Web & Mobile package throughout; do not apply its rates to a web-only project or compare it with another product’s browser-only starting price.
The combined package shares a backend, and Bubble says web and mobile activity accumulate into the project’s workload. List which interfaces you need and who must edit them. A second builder, version-control requirement, or longer troubleshooting history can affect the plan decision independently of the amount of data processed.
Measure the jobs that consume workload units
Bubble’s workload explanation defines workload units, or WU, as a measure of server activity, including database operations and workflows. There is no universal conversion from a registered user to WU. Two apps with the same audience can perform different searches and background jobs, so a user count alone leaves the usage estimate unresolved.
Use a representative pilot: a staff member searches open requests, opens a detail, changes its status, and returns to the dashboard. Include a scheduled import and a report export, then repeat with the record volume expected at launch. These are proposed measurement steps, not firsthand test results or a benchmark. Record the time window, database size, completed tasks, and any retries.
Bubble’s App Metrics documentation describes activity categories and drill-downs into workflows and expressions. Use those views to identify the work behind the total. Keep imports and maintenance separate from ordinary interactive use in your notes, then include both when estimating the month.
If repeated dashboard searches dominate the measurement, examine whether the same output can be prepared and reused with an acceptable freshness window. Check access before reusing a result across people. A lower WU total is not an improvement if it returns stale information or lets a user read another customer’s records.
A combined-package estimate at 300,000 WU per month
Assume one builder maintaining a Web & Mobile project for 50 active app users, with an assumed total of 300,000 WU every month. The WU figure is an input to this example, not an estimate derived from those 50 users. Both options use USD annual billing for a full year; taxes, plugins, external APIs, extra storage, app-store costs, and implementation are excluded.
| Web & Mobile configuration | Monthly WU available | Annual-billing calculation |
|---|---|---|
| Starter plus Tier 1 workload | 175,000 included + 200,000 add-on = 375,000 | ($59 + $26) × 12 = $1,020 |
| Growth plus Tier 1 workload | 250,000 included + 200,000 add-on = 450,000 | ($209 + $26) × 12 = $2,820 |
These are documented rates checked October 23, 2026. Both configurations cover the assumed workload without overages, but their feature sets differ. Growth should be justified by a requirement such as its additional editor or version-control capabilities, not by treating the base plan upgrade as the only way to buy more WU. Verify current checkout terms before purchasing.
A heavier month changes the calculation. Tier 1’s published overage rate is $0.15 per thousand WU beyond the available allowance. For example, 400,000 WU on the Starter configuration exceeds its 375,000 allowance by 25,000 WU, adding $3.75 if overages are enabled. That is an illustrative month, not a forecast that the application will stay near its allowance.
For a different app-builder billing model, Retool pricing examines which users and workflows must be included. Keep the same job, audience, and external services in any comparison. A subscription with more included users can still have a different implementation and operating cost.
Decide what happens when usage exceeds the budget
Bubble documents automatic notifications at 75% and 100% of the workload allowance and supports custom thresholds in its workload notification instructions. Assign someone to receive and investigate them. An alert reaching an unattended mailbox will not stop an expensive recurring job.
Disabling overages is a service decision as well as a spending control. Bubble’s workload explanation says an app goes offline after exhausting its included and purchased WU when overages are disabled. Choose the policy with the workflow owner, including how staff will handle requests if the app becomes unavailable.
Keep a short record of changes that affect usage: new searches, scheduled jobs, larger imports, and workflow retries. Compare metrics before and after each substantial change. Do not remove validation or access checks just to lower consumption; first confirm what work the application is repeating and whether it is needed.
Include a rebuild in any migration estimate
Bubble’s application and data ownership documentation says data can be exported, but the running application cannot be exported as code for independent hosting. Moving away requires rebuilding its logic. Treat an application configuration export and a runnable application as different deliverables when requesting a migration estimate.
Inventory data types, relationships, files, scheduled workflows, plugins, privacy rules, and external credentials. Export a permitted sample and check that identifiers and related records survive. Rebuild one complete request workflow in the destination before setting a cutover date, including status history, failed submissions, and the permissions that determine who can see it.
Reconnect each external integration and test with accounts representing different access levels. Compare the source and destination results, including a revoked user and an unfinished request. Keep the existing app available until the owner approves the replacement. A lower monthly hosting quote should be weighed against this rebuild and the effort of maintaining the new implementation.
For a structured database application, Baserow pricing examines a different budget based on collaborator roles. Confirm the required app behavior and access rules before treating that seat calculation as a replacement for this workload estimate.
Where Permute fits: reusable business outputs
Permute is the connected business data and custom application software we sell. We have a commercial interest in app infrastructure. When a dashboard combines a request register with accounting or customer records, we can help reconcile identifiers and apply declared definitions to a repeatable output, with evidence and freshness visible.
Your team defines what counts as an open request and which source establishes its status. We can reuse that definition across a report or custom app, subject to current permissions. An operations lead can inspect the supporting records when totals disagree, while an uncertain match remains available for review instead of becoming an unexplained count.
Inspect an operations total
Start with permitted source records and examine the definition and evidence behind a recurring report.
Keep application scope and savings unpromised
We do not sell Bubble licenses or promise a reduction in WU. This article claims no native Bubble connection or automatic migration. Source access and any external actions require verification and implementation planning. Enterprise app development covers scoping a workflow around shared business data and permissions.
Approve a budget tied to measured activity
Select the correct publishing package and required features before adding workload capacity. Measure representative operations, including background jobs, and carry their monthly cost into the budget. Decide who owns alerts and whether exceeding the allowance should incur charges or interrupt service. Keep a working application when its measured cost and portability constraints remain acceptable.
Review the data work behind your app
Bring a workflow and its source inventory to discuss definitions, access, and a scoped implementation.
Questions about Bubble workload and subscriptions
Can a user forecast determine the workload budget?
It helps describe the audience but does not establish WU. Measure the searches, workflows, and background operations the audience generates, then state the assumptions used to project the month. Update the estimate when the app or its data volume changes.
Does exceeding included workload require a higher app plan?
Not necessarily. Bubble offers workload add-ons on eligible paid plans, as the example demonstrates. Compare the required features and capacity separately before buying a higher base plan.
Is disabling overages safe for a live operations app?
It caps the available workload but can interrupt service when that capacity is exhausted. Decide whether the workflow can tolerate that interruption and assign an owner to alerts. A spending cap without an operating response can leave staff unable to complete requests.
Does exporting the data make switching straightforward?
The data export is one part of the move. Application logic, privacy rules, integrations, and user-facing workflows still need rebuilding and verification. Complete a representative workflow in the destination before committing to a full migration.