Thanks @josh for the update, these are some nice changes. It’s always good to hear your thought process on the roadmap and how Bubble should move forward. Bubble is one of the few companies where it feels like they want to have a dialogue with their users.
This should be the most important objective of 2026. As I’ve said before, it’s been a full decade since 2016, during which time every niche that can be conquered has already been conquered. LLM-powered apps are the final frontier. I use the example of the “laundromat point of sales software” of @BrianHenderson fame. If he had tried to create that today, it would be unsuccessful because he would be competing with his already established self. This is not necessarily a Bubble problem but an industry problem. It’s why even giants like OpenAI and Google are scrambling to build “AI automation” into their core products. Workflows, etc. The amount of business Bubble has lost to n8n since 2023 could have been completely avoided with the right focus (making Bubble JSON-native, allowing for parallelization of LLM calls, etc.).
@emmanuel recently stated that AI-generated Bubble apps have less churn than regularly-created Bubble apps, presumably for this reason. In my opinion you are focusing on the wrong type of churn. I would like to distinguish “effective churn” from “raw churn.” Raw churn contains users who would have stopped building on Bubble even if the product was perfect, simply because they don’t actually have the motivation/work ethic/talent to build a company from scratch. These are just tinkerers and opportunists looking for the next “easy buck.” Effective churn is what you need to look at. The best place to see this is the conversion rate from Starter –> Growth and Growth –> Team. These are your highly profitable pricing bundles that make up for the Free/Starter “loss leaders.”
I suspect that these numbers have gone down from their historic highs. I obviously don’t have the internal data to prove it, this is just based on foresight. The mechanism for this, I believe, is two-fold:
-
Users start building LLM-powered apps and hit major roadblocks with a lack of parallelization and poor/unintuitive JSON handling. They decide it’s too much work to build a proper AI-native app in Bubble, pack their stuff up, and go somewhere else. This is the most common reason. It’s ironic because it’s analogous to vibe coding an app and hitting a roadblock, which is exactly what Bubble is trying to “fix.”
-
Users hit product market fit, costs go brrrrr, they decide it’s time to go with something cheaper rather than more nimble (since the features have already been built). I think this is less common than #1 and applies more to the Enterprise tier than anything else (which is why we need a tier between Team and Enterprise.). The best way to fix this is to prevent users from tinkering with plugins and code. It’s a slippery slope. Any time you require users to familiarize themselves with Javascript or 3rd party services (Cloudflare Workers, etc.), they get a little bit more comfortable moving off the app. You need to adopt the Apple mentality of, “every single element is fully-featured and polished” and stop thinking about the plugin marketplace as a monetization opportunity. This is why Apple slowly integrated all the major apps (i.e. plugins) into the core of iOS over the course of 10-20 years.
Anyway, focus on fixing #1 rather than trying to capture “inevitable churners.” I also think part of the problem is wrong targeting. You should be aiming for vibe coders who hit roadblocks/security issues and focus the marketing on that. Kind of like the TV show “Botched.” You want to position yourself as the way to fix their useless apps, not as “just another” product that creates useless apps.
Lastly, and this is addressing the 100,000 pound herd of elephants in the room: I think the entire AI agent is misguided and not even technically feasible. Bubble is legos. You’re trying to combine “3d-printed” code with legos that have very specific tolerances and ways of fitting together. It’s never going to be safe to edit an entire application. This is ignoring the fact that no context window is going to large enough for some of the larger apps’ JSON files.
The AI editor needs to be an “airlock.” You click on an Action, Thing, or Element and say “Edit in Assistant.” This sends it over to a sandboxed environment where now the chat-based assistant can edit it freely without worrying about breaking the entire app. You can’t let the LLM decide where to place the code snippets in the JSON. You also can’t let the LLM have access to the entire JSON. Instead you create specific element templates with strict guardrails where the chat assistant inserts dynamic data into the static template. That way you can safely create whatever you need in the validated environment of the sandboxed assistant, and then copy/paste it directly. The user decides where it goes and if it’s good enough. This also has the nice effect of not depending on the buggy undo/redo feature to roll back multiple changes.
Please understand that I took the time to write this post for free because I care about the future of your company as much as you do.