New Bubble pricing: a logical, but complex (r)evolution.

What's changing, in brief

Bubble, one of the major players in the Nocode universe, recently announced a major change in its pricing policy. The new pricing unit, called Workload Unit (WU), replaces the previous pricing unit, the Capacity Unit (CU). 

This decision is taken in order to be able to discriminate its prices according to the (supposed) value that its users (and therefore its owner) get from an application by using the volume of actions performed by the said application as a proxy. Until now, prices were a function of the server capacity required by the application to run at an acceptable performance, which was less directly a reflection of the value derived from the application.

The pricing structure remains similar (plan according to the desired functionalities and packages according to the use) but allows from now on to have no more (theoretical) limitation of performance.

Overall, the cost of a Bubble application will increase significantly in percentage terms but in most cases it will be sustainable in absolute value. It will have to be evaluated on a case by case basis.

The new pricing model will be effective as of May 1 for new applications, and 18 months later for applications already on a paid plan, or upon change of plan if this occurs before the 18 months.

A look back at the various announcements, and how this has shaken up the Nocode sphere:

First announcement (April 6):

• The new pricing model is announced by Emmanuel (co-CEO).
• The number of WU consumed by an application appears in the application logs.
• Users report that the calculated WU consumption would result in a price increase of 3 to 10 times for some applications.

Second announcement (April 7, 2023):

• More details are provided by Tatiana (VP of Marketing), including adding in the documentation what contributes to WU.
• Announcement of a webinar on 20/04 about optimization with respect to WUs.

Third announcement (April 12, 2023):

• Josh (co-CEO of Bubble) announces a revision of his formula for calculating the WU consumed by an application, and reveals more details on his formula througha table of correspondence of WU according to the type of workload.
• A calculator is available to estimate the price of an application for a given consumption of WUs.

It is necessary to wait for the first application consumption data to be collected on the basis of the new formula in order to evaluate the impact of the revision. After a few days, the reduction in the number of WUs is confirmed in the logs. We really notice a decrease of about -90% on our most WU consuming applications.

Our analysis

The advantages of Bubble remain relatively unchanged. From a functionality point of view, we can see an improvement for the same plan (the names have been changed to avoid confusion between current and future plans): the Free plan gives access to the API connector (which was not the case for the current Free plan), and the Growth plan (equivalent to the current Professional plan) now includes 10 branches (compared to only 3 for the current Professional plan) From a cost point of view, the price levels of the plans (which are linked to the features) remain relatively similar, with the Team price (equivalent to the current Production plan) even dropping a little compared to the current Production plan.

Bubble seeks to optimize its pricing to capture value creation rather than purely taking a margin on the production cost of its service. On the one hand, the economic reality of the market must somehow catch up with the company (their cash reserve is not in question, however), and on the other hand, it is a way to perpetuate the financial situation while remaining true to its credo: to make software creation accessible to as many people as possible. 

This new pricing model makes it possible to charge more to those who can, i.e. those who monetize or extract value from their applications, in order to absorb the costs of those who are in the launch phase.

However, projects without a business model, but which need to be scaled up, will be substantially more expensive to finance with this new pricing model than with the current one. It is also regrettable that the new pricing model does not directly take into account energy efficiency, which was the case with the old model, based on the server capacity used.

Development with Bubble will become more technical, which will tend to make it even more professional. Indeed, with a WU calculation formula based on a large number of criteria, it is probably one of the most complicated pricing tools in the Nocode universe.

The actions we take at Alegria for our current and future customers that we have directed or will direct to choose Bubble.

For the time being, we will secure the current pricing of our customers' applications for the next 18 months, as it will always be possible to switch to the new model at any time should it prove more advantageous.

Over the next 18 months we will be offering refactoring to our existing customers for optimizations that make sense in terms of ROI.

We will systematically put WU costs in perspective with development and optimization costs that may have a greater impact on the total cost of ownership, so as not to lose sight of the customer's overall objective.

We will also adapt our methodology and training to this new pricing grid. We were optimizing for performance (and in particular performance perceived by users), we will now also optimize for consumption (of WUs).

When we direct our customers to Bubble it is because it makes the most sense for their project (we also work with alternative architectures such as Xano + WeWeb, FlutterFlow + Firebase, etc.), not only from a technical point of view but also from a point of view of total cost of ownership, target, time to market, market constraints, resources, and degree of autonomy.

‍