AI is a solved problem in Bubble - what now?

AI is now a solved problem in Bubble. Buildprint’s capabilities have advanced so far that many people are not even using the Bubble editor anymore, and spend the vast majority of their time working with agents to build on Bubble.

One-shotting complex UI and logic is now possible. See below for a one-shot generation with Opus 5.5, with pagination fully working, and mobile responsiveness. No manual edits were required. It took less than 10 minutes to generate.

We’ve even got custom maps and calendars, built natively into Bubble:

What does this actually mean for Bubble developers, and your app?

There’s been a lot of concern around Bubble’s future as a platform in an AI-world as their own agent is not remotely close to the capabilities of Buildprint or other traditional coding agents.

However, I think that after working with Buildprint heavily on real client projects, it fills me with more optimism than dread about Bubble’s future. It allows one to build things that would otherwise take too much time, with far more attention to detail than would otherwise be viable. It can step outside the native Bubble abilities where possible to build custom UI, custom APIs and more when it needs to (and only when it needs to).

As an agency owner that’s working on both Bubble and migration projects, I can tell you that most people aren’t interested in migrating. The platform is largely irrelevant to them - they just want to achieve their business goals, and Bubble is still the best place to do that for them. Of the people that are migrating, about 50% are doing it for bad reasons and are going to hit the same issues in code as they’re facing on Bubble. They have a technical design issue, not a Bubble issue.

Let’s suppose that building on Bubble with Buildprint is roughly as fast as building with AI-assisted code (you could argue over specifics but it’s definitely in the right ballpark if you’re using Buildprint well).

What then?

Well, you can build anything*.

*anything that’s possible on Bubble.

When there is no longer a time constraint, the next limitation of Bubble becomes the language. What does Bubble allow us to do? What arbitrary rules does Bubble force upon us?

For many apps, there will be no limitations they’re likely to face. Bubble does everything they need, and more. For other apps, there will be constraints. That might be frontend functionality, backend functionality, or database query limitations.

The question then becomes - what do you do to work with those constraints?

If you have a feature you want to implement that’s not possible in Bubble, you have a few options:

By ‘possible’, I mean ‘practically and maintainably’. We can implement anything with some obscenely hacky solution, but it’s not practical as it’ll be buggy and hard to build upon. We also kind of want to avoid the first solution (redesigning the feature) - we want to build what our users want, not what the Bubble platform wants.

For most cases, option 2 is the best approach. Bubble plugins can be created with Buildprint now, and custom APIs can easily be built with Buildprint Extensions. If you want more control, you are likely technical enough to spin up a custom API yourself and host it.

One of the biggest pieces of work Bubble is doing here is revamping the workflow engine. This is, by all measures, an update that will make workflows significantly more powerful. It introduces variables, branching, loops and more. You’ll need to migrate your app to the new workflow engine (a bit like migrating from old page engine to new responsive engine), but Buildprint will do the heavy lifting for you there.

The expression language is also being continuously expanded (it felt like there’s been more expression operators added in the last few months than had been added in the last few years!).

But for me, the sky will really be the limit for Bubble when custom code can natively be integrated with Bubble in a seamless way.

Bubble has three ways to expand functionality with custom code right now. The first is Toolbox plugin, maintained by Not Quite Unicorns, which is the most installed Bubble plugin and lets you execute arbitrary JS in both the client and server.

The second is the HTML element, which is semi-useful for specific cases, but don’t let you easily pass data to and from the element in an elegant way. The third is plugins. Plugins require a lot of effort to build and maintain, and kind of force you to step outside of the app into a completely separate plugin project. The plugin is, well, an addon to your app rather than something that’s built in to its core.

Bubble’s hesitation to add more support for custom code has in my eyes always been because it’s a no-code platform, and most users don’t need it. I think this is true. But as we move to a world where we only read code, not write it, I think that it’s the right time to really extend Bubble’s support for this.

Suppose for a second that we had a new HTML element. We could define input properties, that could be accessed from inside the HTML element. We could define output properties (or states), that could be set from inside the HTML element. Similarly, we might define workflow triggers from within the HTML element, so that when a user clicks something, it can trigger a workflow on our page.

This would enable custom UIs that are impossible to create on Bubble, but natively integrated with the workflow engine.

Next, we could have a native Javascript action. It lets us run arbitrary JS in the frontend. Importantly, it can return data so we can reference it in subsequent steps.

Finally, a native Node action. Like Toolbox’s server script, it lets us execute any arbitrary Node and like the JS action and HTML element, lets us define the data it can return so we can reference it. It is fast, without a cold start like existing plugin server-side actions. It makes possible efficient complex loops and data transformations.

The ideal end state for Bubble is a platform where visual programming can intersect with custom code. It allows visual development where possible in a managed platform that handles scaling for you and forces you to build in a way that scales. Meanwhile, it allows you to seamlessly expand it with custom code that steps outside visual programming where necessary.

Thanks for reading!

George

Founder
Not Quite Unicorns / Buildprint