Baseline standards for acceptable plugins? Or, how to create a functioning plugin marketplace?

I’m probably treading into hot water here, but geez!

The plugin marketplace is really hard to make sense of as a consumer. Some plugins work, some don’t, and it has no correlation to pricing. Seems like maybe we need some standards, or at the least more functional filters?

Some plugins offer clear explanations of how to implement them, some offer no guidance.

Some plugins require additional coding knowledge, some plugins allow you to bypass additional coding knowledge.

Not sure where other people stand on this, but it seems like it would be hugely beneficial to implement some type of baseline standards for plugins that are distributed via Bubble.

Folks should not be releasing these plugins without producing step-by-step tutorials for how to implement them.

Plugins should be categorized based on whether or not they need additional code in Bubble or elsewhere.

Users should be able to flag a plugin, and plugins that don’t work effectively should be removed from the marketplace.

I’m sure there are plenty of other things that should and should not be done, but these seem like some bare minimum requirements for fostering a marketplace that is useful.

Yeah it’s far from ideal, Bubble owners and team knows it, makers know it, users know it, yet here we are, talking about this. The only ones who can change it is the Bubble team, send this as an email to them.


I think this is specifically hard due to the vast experience range of users. MOST work totally fine and more often than not are user errors/misunderstandings even with documentation. Restricting it would restrict many advancements that have been brought to bubble by the community. Specifically not so beginner friendly plugins that solve massive problems for more advanced bubblers like pdf fillers, list shifters, email/web builders, saas alias, JS tools, and much more.

Granted, there are some broken plugins that I agree should be removed however that’s why bubble has the pro rated/refund option when you uninstall something & the review section.

There are countless plugins I’ve seen reviews on saying it “doesn’t work” and I’ll grab it anyway, implement, and it works great.

Bubble is a community platform and should stay flexible as such. I do like your idea of tagging requires code/external API idea though.

Restricting it would be like restricting GitHub or other open source repositories.

If I had to build custom even 20% of the plugins I’ve used time to market would take drastically longer.

1 Like

I would add that something that could help is to be able to release a plugin in a “beta” status. When you first build a plugin you are trying to solve a problem you have run into in your own app and hope that it solves someone else’s problem as well. It’s not necessarily 100% functional, but you want to get some folks to test it (similar to the experimental feature options Bubble implemented recently).


A lot of it has to do with new versions of bubble breaking older, no longer supported plugins. My suggestion to Bubble is on every plugin page, have a text that says (supports latest version of Bubble) and (may not support latest version of Bubble) if the plugin has or hasn’t been updated to the latest version of the API.

Simple solution in my opinion!


I’m not advocating for any kind of censorship, or limitation of what can be built. Creating different filters that allow people to see what level of coding expertise is required for a plugin has nothing to do with the freedoms of plugin builders.

I 'm not arguing with the fact that there are people leaving reviews saying “it doesn’t work” when it does in fact work. That’s parallel to what I’m saying.

If people who can’t get the plugins to work knew that they couldn’t get them to work, then that would probably produce better results.

1 Like