The Backlash Against Bubble: How Pricing Changes Sparked Negative Community Response
It’s not uncommon for software products to become community favorites, attracting a loyal user base that sings their praises and recommends them to others. But even small changes to a once-loved product can quickly turn that love into loathing, sparking backlash from the very community that once championed it. Whether it’s a change to pricing, a feature alteration, or a perceived lack of attention to user feedback, the community can quickly turn on a product, leaving its creators scrambling to regain the trust of their users. In this article, I’ll explore how pricing changes may impact community support for Bubble’s growth and trajectory.
What is Bubble?
Bubble is a no-code platform that allows users to create custom web applications without needing to write code. The platform uses a drag-and-drop interface and a visual editor to enable users to design, build, and launch their own web applications, including marketplaces, social networks, and other complex web-based tools. With Bubble, users can easily create fully functional web applications without the need for technical expertise or programming knowledge. This allows entrepreneurs, businesses, and individuals to bring their ideas to life quickly and easily, and to build powerful digital solutions without the traditional barriers to entry that come with software development.
What happened?
Bubble announced changes to its pricing model, introducing a new metric called “workload usage” to quantify an app’s usage on the Bubble platform. The change aimed to introduce a pricing model that allows apps to scale without the risk of being throttled and to ensure Bubble’s long-term success as a platform. This update replaced the previous usage-based metric, called “capacity,” which was introduced in 2017 to protect Bubble’s infrastructure by preventing any single app from putting too much stress on the systems.
The “capacity” metric, however, created challenges for users, especially during peak usage times, when apps were more likely to be throttled. The introduction of “workload usage” aimed to improve scalability by measuring the amount of work an application needs to do, like data retrieval, API connections, and web interactions. How quickly Bubble performs this work does not affect workload computation, which means that as Bubble improves its performance, the pricing model remains aligned with usage.
Existing users were given the option to remain on their old plans for 18 months, with a 10% price increase, until October 1, 2024. The new plans would be available starting May 1, 2023. The company also offered support to help users optimize their apps to minimize workload consumption.
The impact of pricing changes on agencies
The introduction of Bubble’s new pricing model based on “workload usage” has significant implications for agencies that use the platform to develop and maintain web applications for their clients. Under the new pricing structure, agencies may face increased technological costs, particularly for apps with high workload consumption. As a result, agencies may find themselves in a challenging position where they need to renegotiate contracts with their clients to account for these higher costs. The transition may require agencies to have candid conversations with their clients about the rationale behind the pricing changes and the impact on the overall cost of maintaining and scaling their web applications. Agencies will need to carefully assess how the new pricing model affects their margins and service offerings, and they may also need to explore optimization strategies to minimize workload consumption, thereby mitigating the financial impact of the pricing changes on both the agency and its clients.
Increasing concerns of vendor-lock within the No Code ecosystem
The pricing changes introduced by Bubble, with the transition to a “workload usage” metric, have raised concerns about vendor lock-in within the no-code ecosystem. Vendor lock-in refers to a situation where customers become dependent on a single vendor’s platform or service and face challenges in migrating to alternative solutions.
For users and businesses that have invested significant time and resources into building and maintaining their web applications on Bubble’s platform, the shift in pricing can lead to apprehension about the increased cost of operating their applications. The new pricing model may result in higher expenses for certain apps, particularly those with high levels of workload consumption. This could create a financial burden for users and organizations that have already built complex and data-intensive applications using Bubble’s no-code tools.
The situation is further complicated by the inherent nature of no-code platforms, which abstract away the underlying code and provide a visual development environment. While this makes it easier for non-technical users to build applications, it can also limit their ability to migrate applications to other platforms or technologies. The specificity of each no-code platform’s visual programming language and features means that transferring an application built on Bubble to another no-code platform or a traditional coded solution may require a significant amount of manual work and reconfiguration.
These concerns highlight the potential risk of vendor lock-in, as users may feel constrained by the platform’s pricing changes but find it challenging to transition their applications to alternative solutions without incurring substantial redevelopment costs. The fear of vendor lock-in has led some users to call for greater transparency and predictability in pricing models, as well as the exploration of more open and interoperable no-code development standards. Users may also seek assurances from no-code vendors regarding long-term pricing stability and support to mitigate the risk of unexpected cost increases that could impact their businesses or projects.
Confusion surrounding workload usage calculations
The introduction of the “workload usage” metric by Bubble as part of its new pricing model has led to confusion among some users regarding how workload usage is calculated and its impact on the cost of operating their applications. Workload usage is designed to measure the amount of computational work an application needs to perform, including data retrieval, manipulation, API connections, and web interactions. However, the complexity of these processes and the diversity of applications built on the platform have led to challenges in understanding and optimizing workload usage.
One of the primary sources of confusion is the lack of clarity about which specific actions or processes within an application contribute to workload consumption and how they are quantified. Users may be uncertain about how different features, workflows, or database queries affect their app’s workload usage and whether certain design choices or optimizations could help reduce consumption. Additionally, users may struggle to predict how changes in user behavior, such as increased traffic or more intensive interactions, will impact workload usage over time.
The introduction of workload usage as a new concept means that many applications were not initially designed with workload optimization in mind. As a result, users may find themselves needing to reassess and reconfigure their applications to minimize workload consumption, which can be a complex and time-consuming task. To further complicate matters, the variability in workload usage depending on usage patterns and traffic spikes makes it challenging for users to accurately forecast their future costs.
To address these concerns, Bubble has taken steps to provide support and resources for understanding and optimizing workload usage. This includes publishing content, organizing webinars, and offering assistance from their team to help users optimize their applications. Nonetheless, users continue to seek more detailed documentation and tools that enable them to monitor and analyze workload usage in real-time, as well as clear guidelines on best practices for optimizing performance and minimizing costs.
Overall, the confusion surrounding workload usage calculations highlights the importance of clear communication and education by no-code platform providers to ensure that users have a comprehensive understanding of how pricing metrics are determined and how they can effectively manage their applications within the new pricing framework.
Some users are supportive
While the introduction of the “workload usage” metric and the associated pricing changes by Bubble have led to mixed reactions, some users within the Bubble community have expressed support for the new model, recognizing its potential long-term benefits for both the platform and its users. These users understand that the shift to a workload usage-based pricing model is aimed at aligning Bubble’s revenue with the actual usage of its platform, thereby ensuring the financial sustainability and long-term success of the company. By implementing a pricing model that scales with usage, Bubble can continue to invest in the development and improvement of its no-code platform, providing users with better performance, enhanced features, and a more robust and reliable development environment. Supporters of the new pricing model appreciate that Bubble’s growth and ability to innovate are essential for the continued success of their own applications and businesses built on the platform. They acknowledge that the changes, though potentially challenging in the short term, ultimately serve to strengthen Bubble’s commitment to delivering a high-quality product that empowers users to create and scale web applications without coding expertise. This perspective reflects a broader understanding of the symbiotic relationship between the platform and its user community, where Bubble’s success as a business is viewed as a key enabler of the success of the applications and projects built using its tools.
Hobbyists and Indie Makers as a customer segment
The rise of no-code platforms has democratized software development, enabling indie makers, hobbyists, and solo entrepreneurs to build and launch digital products without extensive coding expertise. However, from a business perspective, catering to this user segment can present profitability challenges for many no-code platforms. Indie makers and hobbyists often operate on tight budgets and may not have the financial capacity to afford higher-tier pricing plans. Consequently, they tend to gravitate towards free or low-cost plans, which can limit the revenue potential for no-code platforms. Additionally, projects initiated by solo entrepreneurs and hobbyists may not always scale to a level that requires more advanced and costly features offered by the platform. As a result, their contribution to the platform’s revenue may remain relatively modest over time. While no-code platforms value the creativity and innovation that indie makers bring to the ecosystem, the sustainability of catering to this segment can be challenging, especially when platforms need to invest in infrastructure, product development, and customer support to meet the needs of a diverse user base. Balancing the need to support indie makers and hobbyists while maintaining a sustainable and profitable business model remains a complex and ongoing consideration for no-code platforms as they continue to evolve and grow.
Potential alternatives for Bubble
In light of the pricing changes introduced by Bubble and the introduction of the “workload usage” metric, some users have expressed concerns about the potential impact on the cost of operating their applications, prompting them to explore potential alternatives to Bubble. Among the alternatives gaining attention are platforms like WeWeb and FlutterFlow, which offer features that address some of the concerns related to vendor lock-in and cost. For example, FlutterFlow provides users with the option to export their codebase, allowing them to self-host their applications and have greater control over their deployment and maintenance. This feature is particularly appealing to users who are concerned about being tied to a single vendor’s infrastructure and pricing model. Additionally, WeWeb offers competitive pricing plans, attracting users who are seeking more cost-effective solutions for building and scaling their web applications. The ability to export code and self-host applications, combined with the allure of lower costs, has led some users to consider these platforms as viable alternatives that provide flexibility, control, and affordability while still enabling them to create sophisticated web applications without the need for traditional coding expertise.
The no-code movement, exemplified by platforms like Bubble, has revolutionized the way people create and launch digital products by making software development accessible to a broader audience, including indie makers, hobbyists, solo entrepreneurs, and non-technical founders. However, the introduction of pricing changes, such as Bubble’s transition to a “workload usage” metric, has sparked a range of reactions within the user community. While some users express support, recognizing that the changes are designed to ensure Bubble’s long-term sustainability and continued innovation, others are concerned about the impact on their costs and the potential for vendor lock-in. These concerns have prompted some users to explore alternative no-code platforms, such as WeWeb and FlutterFlow, that offer features like code export and self-hosting options.
The challenges of profitability, especially when catering to budget-conscious indie makers, further underscore the complex dynamics of operating within the no-code ecosystem. As no-code platforms continue to evolve, clear communication, transparency in pricing, and ongoing efforts to educate and support users will be essential in fostering a strong and collaborative relationship between platforms and their user communities. Ultimately, the success of no-code platforms hinges on their ability to empower users to create and scale their digital products while maintaining a sustainable and forward-thinking business model that benefits both the platform and its users.
About The Author
Dominic O Norton is an experienced, impact-driven social entrepreneur and the founder of Missing Black People, a comprehensive tech-enabled platform that brings awareness to missing black people cases worldwide, which has been featured in BBC, ITV, The Independent, Vice UK, and RT. With a professional background in technical product management and a postgraduate diploma in Business Administration & Management from the University of London, Dominic utilises his experience to build impact-driven initiative and to help over 11,000 entrepreneurs on TikTok do the same using “No Code”. As a fellow of On Deck and creator-in-residence for #100DaysofNoCode, Dominic is highly experienced in software development which has led him to becoming a guest lecturer in University of California, All Nations University, APTech Computer Education in Uganda and more.
This article was assisted by artificial intelligence