Our Bubble.io App Costs $15,000 a Year. Should We Rebuild It?

One Bubble.io application we run now costs exactly $15,000 a year to host. Development has mostly stopped. The bill has not.

That number comes from our own operating records. It is not an audited study of Bubble pricing, and it is not a benchmark for other apps. A small product with modest traffic may cost far less. Still, $15,000 is enough to force a serious question: should we keep this app on Bubble, optimise it, or rebuild it in code?

The tempting answer is to compare the Bubble bill with the price of a few servers. That comparison is incomplete. Bubble is not selling us a few servers. It is bundling hosting, deployment, scaling, data services, and a development environment behind one application-level model. A code rebuild would give us different levers, but it would also return a long list of responsibilities to our team.

The decision is therefore not “Bubble bill versus server bill.” It is whether the current cost behaviour, operational control, customer impact, and product constraints justify staying—or whether taking back more responsibility is worth it.

The incident that changed the question

The annual bill got our attention. A single incident made the control problem concrete.

A Bubble workload incident added more than $1,400 to our bill. We traced and localised the cause, but stopping the cost drain took several hours because we could not stop that workload without taking the entire application offline. We kept the app available while we contained the incident. The main post and follow-up are our public first-person record of what happened.

There is an important limit to this account. Tracing and localising the cause does not prove that the underlying class of failure can never recur. Nor does one incident prove that Bubble is generally unreliable or unusually expensive. It tells us something narrower: in this case, the immediate cost-control action and the service-continuity action were coupled.

That left me with a counterfactual, not a fact: what if the same incident began on a weekend, when the team could not react immediately? I do not know what the bill would have been by Monday. The useful question is not the imaginary total. It is whether the system gives us enough time and enough selective control before cost and customer availability collide.

Bubble’s own documentation helps explain the trade-off. Bubble defines workload as an aggregate measure of the server resources an app consumes. App plans include workload, and owners can add more through subscriptions or pay-as-you-go overages. Bubble says overages are enabled by default to help an app remain live under higher demand; they can be disabled, but the app can go offline after its included and purchased workload is exhausted.

That policy is not evidence about the exact mechanism of our incident. It is evidence that cost protection and availability can be a real product trade-off in the platform’s operating model.

Control is more than a spending cap

An absolute cap sounds like control until the cap takes the product away from its users. Unlimited overages sound like resilience until a faulty or unexpectedly expensive process keeps running unattended.

For a business-critical application, useful control has at least four parts:

1. Attribution: Can we identify which workflow, query, API call, page load, or scheduled process is consuming resources?
2. Detection: Can we learn about abnormal consumption early enough to act?
3. Isolation: Can we stop or restrict the expensive process without stopping the whole product?
4. Recovery: Can we return to normal operation, verify the result, and reduce the chance or impact of recurrence?

Bubble provides real tools for the first two parts. Its workload tracking documentation says historical app metrics can be drilled down to actions and expressions, while server logs show individual operations shortly after they occur. Bubble also provides automatic and configurable workload notifications.

It also has some specific protection mechanisms. For example, infinite recursion protection can terminate workflow chains that exceed an app-level depth limit. That is useful, but it is deliberately scoped: it protects against runaway recursive scheduling, not every possible source of high workload.

The question for our app is not whether Bubble has monitoring. It does. The question is whether the available attribution, alerts, and stop mechanisms cover the failure modes that matter to this product, with a response window our team can actually meet.

Option one: keep it

Keeping the app on Bubble is rational if the current bill is predictable, the product is not blocked, and the platform continues to remove more engineering burden than it creates.

Fifteen thousand dollars a year is a large hosting line for us, but it may still be cheaper than owning a replacement. A rebuild has an initial cost, a migration risk, and an indefinite maintenance cost. It can consume months of attention while the existing product still needs to serve customers. If Bubble lets a small team operate a stable product without maintaining infrastructure and deployment systems, the bundle may be economically sensible even when the raw hosting figure looks uncomfortable.

Our case should not be projected onto every Bubble app. Bubble says most plans include enough workload for users to get started building, testing, and launching. Apps differ in traffic, data volume, workflow design, integrations, and business value. A simple internal tool and a mature transaction-heavy product do not have the same cost curve or control requirements.

The strongest case for staying would include evidence that:

• normal workload is stable enough to forecast;
• the incident was bounded and the relevant guardrails now reduce its possible impact;
• the features we need remain practical to build and operate;
• the team can diagnose problems within an acceptable response window;
• the annual platform cost remains lower than the full cost and disruption of a rebuild.

“The bill is high” is not enough to reject that case.

Option two: optimise it

Optimisation is the middle path, and probably the first one to test when the cost can be traced to specific behaviour.

Bubble’s optimisation guidance groups common problems into complexity, volume, and repetition. A workflow may do more work than necessary, a query may return more data than the product uses, or a cheap operation may become expensive because it runs too frequently. Bubble also cautions that workload reduction is only one priority: an optimisation that damages security, capability, or user experience is not automatically a win.

For our app, an optimisation programme should produce more than a lower invoice for one month. It should show:

• a baseline of workload by major product operation and time period;
• the few processes responsible for most avoidable consumption;
• before-and-after measurements for each change;
• alerts tied to a response procedure, not merely an inbox;
• a tested way to contain the incident class without cutting off every user;
• evidence that savings persist under representative traffic and jobs.

This is where platform tooling can be valuable. Bubble’s metrics and logs can help identify expensive actions, and its optimisation checklist gives concrete patterns for searches, workflows, bulk operations, and repeated work. But the result has to be measured in our application. Documentation can suggest where to look; it cannot promise our savings.

Optimisation becomes a weak answer if the team can reduce normal consumption but still cannot bound the impact of the failures it considers plausible. Efficiency and control overlap, but they are not the same thing.

Option three: rebuild it

A rebuild becomes credible when the control gap is structural rather than incidental: important product changes are blocked, operating behaviour cannot be bounded well enough, or the combined platform cost and constraints exceed the cost of owning the next system.

Code can give a team more granular levers. A queue consumer can be paused while the public application stays online. A service can have a concurrency limit. A costly job can have a budget, deadline, circuit breaker, or kill switch. Different workloads can be isolated and scaled separately. Those are possible design choices, not automatic properties of “using code.” They exist only if the replacement is designed, tested, and operated that way.

Rebuilding also unbundles the work Bubble currently absorbs. The new total cost of ownership includes more than compute:

• application and database deployment;
• security updates, secrets, and access control;
• monitoring, alerting, and log retention;
• backups and tested restoration;
• incident response and on-call availability;
• capacity planning, performance work, and scaling;
• vendor integration changes;
• ongoing framework, dependency, and infrastructure maintenance.

Some of those costs are paid to providers. Many are paid in engineering time and attention. AI-assisted development can reduce the cost of writing and changing code, but it does not accept operational responsibility. Generated infrastructure still needs security review. Generated tests still need to represent the failures that matter. An agent can propose a kill switch; the team must decide what it is allowed to stop and verify that it works under pressure.

This is why I am not putting a speculative replacement-hosting number next to $15,000. A small compute instance is not a replacement for the system we operate today. Any credible rebuild estimate must describe the target architecture, migration, staffing, operating model, and risk—not just a monthly cloud subtotal.

The evidence that should decide it

We have one annual cost, one expensive incident, and an observed control constraint. That is enough to investigate the decision. It is not enough to declare the answer.

Before choosing, I want a comparison built from the same categories on all three paths:

The comparison must use representative periods, not one flattering week. It must separate recurring cost from migration cost. It must include the people required to operate the result. And it must state uncertainty instead of hiding it inside a precise-looking total.

Our decision remains open. The immediate work is to measure the app’s normal workload, verify the guardrails around the incident class, and estimate a code replacement as an operating system rather than a pile of servers. Staying may be rational. Optimisation may buy enough control. Rebuilding may be worth the added responsibility.

The $15,000 bill is not the verdict. It is the point at which “what does hosting cost?” becomes “what kind of control are we paying for?”