Hey guys, Bit of an open-ended question here, but i recently built an entire bubble website basically using HTML code written by Claude with some customizable user features through utilizing a bubble database setup. Just wondering before i publish the website if there is something i should pay close attention to in regard to the safety and durability of solely relying on HTML elements. Keen to hear past experiences pros and cons, and if any major errors happened down the track.
Kind Regards
Lucas
No, it’s a pretty good approach - doesn’t solve page load time but can be useful for frontend
It’s impressive, Lucas! Would love to see what you’ve built, please share your website or some screenshots of the project.
That’s definitely the most unusual way I’ve ever seen someone build something in Bubble hahaha. I’m definitely curious to see the end result too! Is the frontend basically just HTML embedded in the editor?
I had done a couple of posts before where I used this method…
but the way I did it was probably a little different because I have a single-page app, so I use reusable elements for the groups/pages and then use the toolbox plugin to connect to the backend. So some of my reusable elements were all built within an HTML element.
The only thing that I had a couple of problems with was some of the code messing with other features. So, it’s best when you write the code (or AI writes it) to put safeguards in place to keep things from changing other features… at least that was a problem in my situation.
George makes a good point about the frontend side. I’d be a little more cautious about what sits behind the HTML before publishing, though.
Using HTML/JS generated with Claude isn’t inherently a problem. The main things I’d check are:
- whether any API keys, tokens or sensitive logic are exposed client-side;
- whether Bubble Privacy Rules are doing the actual access control, rather than relying on what the HTML hides or displays;
- how user-controlled data is injected into the HTML/JS, especially for XSS/sanitisation;
- whether the generated JS depends heavily on Bubble’s current DOM/page structure, because that can make seemingly harmless changes break things later;
- and how maintainable the generated code is once you need to modify/debug it without Claude reconstructing large chunks each time.
If the HTML is mainly presentation and Bubble remains responsible for authentication, permissions, sensitive data and backend logic, that’s a much healthier architecture.
Since you’re still pre-launch, this is actually a good time to review those boundaries rather than waiting for something to break in production.
I work with Bubble, APIs and AI-assisted integrations, so if you want a second pair of eyes on the setup, I’d be happy to do a small pre-launch review and flag anything risky without trying to rebuild what’s already working.
One last thing I’ll say about this, because I think it’s interesting that someone else experimented with it, is that I really wouldn’t recommend it for a whole site.
If you’re just rendering a complex library (like a D3.js chart or a custom Canvas animation) or inserting a lightweight SVG shape or specialized CSS animation that standard groups can’t handle, I think it’s totally okay for those special occasions.
But doing an entire site this way means you lose a lot of the core benefits of using Bubble, like the visual editor, automatic security sanitization, etc.
As I said, I tried it and decided it wasn’t worth it overall. I still code some special things, as I mentioned.
If you want to code the whole app, I’d suggest just hosting it on Vercel or somewhere similar instead.
Just my thoughts!
