Plugins, templates, and native Bubble
Use native Bubble when it is clear enough
Use native Bubble when the native version is clear, maintainable, and does the job.
That sounds obvious, but a lot of Bubble apps end up with plugins for things Bubble can already do: an iframe, a loading spinner, a sticky group, a simple API call, a basic animation, or a reusable bit of UI. Those plugins can make the first five minutes easier, but they also add something else to maintain.
The issue is not whether plugins are good or bad. The issue is whether this plugin is worth being in this app.
If the native version is a normal Bubble element, condition, custom state, reusable element, API Connector call, or workflow that another developer can inspect in the editor, I would usually start there. It keeps the app easier to debug and reduces the number of things that can break outside your control.
There are exceptions. If the native Bubble version needs a horrible workaround, or if a good plugin saves days of work, use the plugin. Just make that a deliberate decision.
Plugins should earn their place
A plugin should earn its place by doing something useful enough to justify the dependency.
Good reasons include:
Bubble does not support the feature natively.
The plugin saves meaningful build time.
The plugin handles a difficult integration better than you would.
The plugin is maintained and documented.
The native Bubble version would be harder to support than the plugin.
Weak reasons include:
The plugin looks easier than learning the Bubble feature.
The plugin wraps a very simple element.
The plugin hides an API call you could make with the API Connector.
The plugin is already installed, so someone keeps using it.
The API Connector example is common. If you need a straightforward Stripe API call and the plugin only exposes a few settings, the plugin can become the problem later. You may need a parameter, error response, object, or webhook behaviour that the plugin author did not expose.
Some Stripe plugins are good. The point is to check API plugins carefully, because they can trade short-term speed for long-term limits.
Do not make this a purity test
NQU maintains plugins. We use plugins. Some plugins are absolutely worth using.
Do not turn this into "never use plugins". Real Bubble apps use plugins when they are worth it.
The useful version is: do not install a plugin when the native Bubble version is simple enough. If the plugin saves real time or gives you capability Bubble does not have, fine. If it exists because someone did not know Bubble could already do the thing, remove it or avoid adding it.
I would be much more cautious with plugins that touch billing, authentication, data sync, file handling, or anything central to the app. If a loading animation plugin breaks, that is annoying. If a billing plugin blocks a required Stripe parameter, that can block the product.
Templates are useful when you understand them
Templates can save time, but only if you understand what they imported into the app.
The best case is a template you built yourself or have audited properly. For example, a base Bubble app with login, a dashboard shell, admin pages, user management, reusable navigation, and basic account settings can be a good starting point. If your team knows how it works, it can make client work faster and cheaper.
Marketplace templates are riskier because you inherit someone else's data types, privacy rules, repeating group searches, page-load workflows, plugins, responsive settings, and naming conventions.
That is where templates often become slower than starting cleanly. You try to add a feature and a hidden workflow changes the same data. A reusable element has conditions you did not know about. A header runs searches on every page load. A repeating group works with demo data but loads too much when the app has real records.
If you are spending more time reverse-engineering the template than building the app, the template has not saved time.
Audit a template before building on it
Before using a template as the base for a real app, check the parts that usually cause pain later:
Data types and fields.
Privacy rules.
Plugins.
API Connector calls.
Repeating group data sources.
Searches in headers, popups, reusable elements, and page-level groups.
Workflows that run on page load.
Backend workflows.
Reusable element properties and custom states.
Responsive settings.
Do this before you build features on top of it. A bad search in a header is easier to remove before every page depends on it. A bad data model is easier to fix before you have workflows, privacy rules, and reusable elements built around it.
If the template fails this audit, either clean it up first or do not use it.
UI kits are a smaller risk than full app templates
Treat a small pasted UI pattern differently from a full app template.
Small UI kits can be useful because you can inspect them quickly. Check the responsive settings, conditions, data source, and workflows, then adapt the UI to the app.
The risk goes up when the imported thing owns data structure or app logic. A reusable table component with its own searches and filters needs more review than a static card layout. A template with user roles, admin workflows, and billing flows needs more review than a landing page section.
Use the amount of app behaviour it controls as the review standard.
Use the shortcut only when it stays a shortcut
Before adding a plugin or starting from a template, ask:
Can we build this clearly in native Bubble?
Will another Bubble developer understand this in the editor?
What breaks if this plugin stops being maintained?
Does this template have searches, workflows, or privacy rules we have not checked?
Are we using this because it is better, or because we do not want to learn the Bubble feature?
If the native Bubble version is simple, use it.
If the plugin or template saves real time without importing a mess, use it.
If the shortcut makes future changes harder, skip it.