It is very clear that your app is build on Bubble


Bubble strings are shown everywhere in code. It is not too hard to find out what platform your app is build on even you are allowed to use your own domain.

Does this bother you? Is there a way to get around this? Thanks.

Doesn’t bother me, and exactly zero of users know about it. Even if they did, not sure why anybody would care. It’s also easy to tell when an app is built with React or Angular, or Wordpress, or Bootstrap. Just doesn’t matter as long as your product is valuable, stable, and well executed.


Doesn’t bother me at all.

I’ve been using the wappalyzer plugin on chrome for a couple years now. I always know which stack the website I’m on is built with. It’s second nature for me to look at the stack before I even start interacting with a website, especially if it’s enterprise sized or an interesting start up.

Sometimes wappalyzer doesn’t load the stack on page load. I’ll even refresh the page until it catches it!

But yea, like @potentialthings says - users don’t know or care what stack you use, as long as it works.


Nope, doesn’t bother me at all.

Hi all,

Thanks for your options. I think i was being too overreactive :slight_smile:

Yeah, it’s not like you can keep client-side code a secret, and even if you expand to all internet code, the whole internet was grown by leveraging open code.

I think it’s actually in our best interest to not hide the fact that apps are built on Bubble. If we’ve invested in Bubble as a platform then we want other people to see it’s an option and join us on it. Otherwise Bubble might disappear, taking our investment with it.


I agree with everyone. I’m putting the made with bubble logo on my app. To promote it not hide it. I wNt to do my part to support it.


I’m actually proud of what I can accomplish with Bubble. I understand your worries, but we’re living in a time where even big companies aren’t afraid of making some of their codes open source.

1 Like

No matter what you use to build your app, someone somewhere will object.

“Oh you are ACTUALLY using Angular* are you ?”

*insert favourite framework


I have several remarks:

  1. Bubble is a enabling platform that I believe in and will continue to support.

  2. Enterprise customers of Bubble should absolutely be allowed to disable the “this was entirely built on Bubble” text that is visible in the console. Considering the current security vulnerabilities, such as any visitor being able to view the version-test of any Bubble app (private or not) to name one, I think it is more than an appropriate request for enterprise users on dedicated hardware to have some white-label features.

For business users, a construct of convenience is to minimize friction and anxiety with customers/potential customers. If I’m using a proprietary platform to build enterprise applications, I want to utilize all possible opportunities to reduce dialog around “you built my app on a website builder?! This can’t scale…what if my data is lost…how secure is this platform…what if they disappear…what if things go the route of Parse” with non-technical customers. In my business life (not associated with Bubble). I have frequently experienced enterprise customers ‘freaking out’ when they do not understand something, costing my company either significant consulting fees (legal, etc.) or a significant allocation of employee time that could have better utilized building a better service and product. For technical customers, they (usually) have a better understanding of engaging in a debate around preferred technologies and it is not so much of a concern, as they’ll be able to “see” Bubble anyway.

If Bubble is open-sourced, then the table shifts in a different direction. As of now, Bubble branding does present a level of resistance that could be easily avoided. Personally, I’m willing to pay for white-label features and am also comfortable with that option going away if/when the platform is open sourced.


I have observed this behavior as well. I have seen an instance where a third party - entirely isolated from any Bubble account credentials - on a device with no relevant stored password/login info in browser – was able to view and interact with the version-test.

So I can confirm that.
I don’t know how recently you experienced this? But its good that you have made note of it.

That being said though - I do almost all of my testing via the version-test URL inside a mobile browser (as opposed to the bubble iOS app). And the ability to just access the link without authenticating myself as a bubble user can in fact be convenient (for me).

However - the notion of the version-test being accessible for viewing to anyone, regardless of authentication (assuming the viewer is clever enough to somehow find the viewing link); is a little unsettling - Particularly if the Bubble app in question, is one that is continuously releasing new functionality etc.

The likelihood is incredibly low; but competitors, having access to view a web app that is still in “stealth mode” or working on unreleased functions etc - seems like an unnecessary risk; and could be circumvented with a secondary Bubble account login on the version-test page (assuming the bubble user isn’t already logged in).


All you have to do is look at the page source…all that would have to change, which isn’t going to happen.

It is no different to an app being covered in angular tell tales or wordpress etc. The very nature of web apps is that there are usually markers to libraries and frameworks all over the place.

I completely agree.

For technical customers, they (usually) have a better understanding of engaging in a debate around preferred technologies and it is not so much of a concern, as they’ll be able to “see” Bubble anyway.

For technical folks, we can dissect most web apps using an inspector or viewing the source code. For non-technical people (think industries and people that cannot make sense of code), it’s not as obvious in the source code that a codeless framework is being used (div tags aside). What is obvious: “built entirely without code on Bubble”…that could change with a very small adjustment. Every business and user has different needs, this happens to be one.

@jordanfaucet Yeah, I’ve noticed this a few times over the last couple of months…definitely unsettling. You’re right, popping up safari and Chrome on mobile is super easy to test things out. I like your idea of creating a second dummy Bubble account to share access to an app - sharing access to other Bubble accounts could be a great way of controlling access during development.

@emmanuel, any room in the pipeline to enable a ‘only share version-test with Bubble users: X, Y, Z’ ?

See this, it’s been there for a while now

1 Like

Appologies, I didnt make myself clear: I wonder if it is possible not to allow people to go to “”/ version-test url? And if they do manage to write this url, redirect them to the main (home) page of the Live Version?

you can’t prevent anyone to go to a URL, but you can add a password protection. That’s what we offer.

Thank you!

Limiting Access in the “General/Design” tab did the trick!

Does the Enterprise plan allow one to get rid of the Bubble print() in Console?

No one on a dedicated plan has asked for this, but we’ll consider if someone does, yes.


When we go to dedicated plan - expected hopefully next 3 months, I will take you up on that.

I am very much up for promoting Bubble - I think it is a superb application. Just want to be able to do it in a controled manner.