Canvas Plugin Strategy: What to Keep, Replace, or Remove

Plugins are how Canvas apps grow features quickly. They are also the single biggest source of hidden cost in Canvas apps at scale: page weight, security risk, vendor risk, and ongoing maintenance overhead that the original installer never accounted for.

This article describes the framework we use at AppSavvy when auditing and pruning plugin inventories. It applies to any Bubble app but Canvas apps tend to accumulate more plugins than vanilla Bubble because the framework encourages component reuse.

The hidden costs of plugins

Before the framework, a quick honest list of what each plugin actually costs you.

Page weight. Every plugin adds JavaScript that loads on every page where it is referenced. Many plugins load globally regardless of whether the current page uses them. A 200KB plugin used on one page can add 200KB to every page load.

Security surface. Every plugin is third-party code with access to your app. A plugin compromise affects your users.

Vendor risk. Most plugins are maintained by individuals. They go quiet. They sell to someone else. They stop responding to bug reports. You inherit the maintenance.

Bubble update fragility. When Bubble pushes a platform update, plugins often need updating too. If a plugin you depend on is abandoned, you can be stranded.

Engineering bus factor. A plugin that does something custom is often the only thing in your app that knows how to do that thing. Replacing it requires rebuilding the functionality.

None of these costs show up on the plugin marketplace listing. They show up later.

The framework

For every plugin in your app, classify it into one of four buckets.

Bucket 1: Keep

The plugin is essential, well-maintained, and worth what it costs in page weight and risk. Examples are usually:

• Plugins from major vendors with active maintenance (Bubble's own, well-known paid publishers)
• Plugins doing things that genuinely could not be done without them and that the alternative implementations would be worse
• Plugins under active commercial support

Bucket 2: Replace

The plugin works today, but a better path exists. Examples:

• A plugin doing something that Bubble's native functionality now handles
• A plugin replaceable by a small bit of custom code or an API call that you own
• A community plugin replaceable by a more reliable paid alternative
• A plugin used for one feature that could be moved to a code service alongside Bubble

Replacing is not always urgent, but it should be planned within the next two quarters.

Bucket 3: Remove

The plugin is installed but barely used or no longer needed. Examples:

• Plugins installed for an experiment and never removed
• Plugins replaced by a different solution but never uninstalled
• Plugins only referenced on pages that were themselves deprecated

Remove plugins like this within the current quarter. The page-weight win alone is usually worth it.

Bucket 4: Migrate away from

The plugin is critical and there is no good replacement, but the plugin itself is abandoned or risky. This is the most uncomfortable bucket because the plugin is doing real work that your app needs.

The realistic options are:

• Find or commission a replacement before the plugin breaks
• Fork the plugin source and maintain it yourself
• Plan to migrate the feature off the plugin (often by moving it out of Bubble entirely)

Apps that find themselves with two or more plugins in this bucket are usually a year or so away from needing a serious migration conversation.

How to run the audit

The audit takes an afternoon for a typical Canvas app.

Step 1: list every installed plugin

In Bubble, open the Plugins tab. List every plugin name, publisher, version, and last update date.

Step 2: find every place each plugin is used

For each plugin, search the editor for references. Note which pages, reusable elements, and workflows depend on the plugin. Plugins used in zero places go straight into Bucket 3 (Remove).

Step 3: check publisher activity

For each plugin in active use, check the publisher's marketplace page. Has the plugin been updated in the last 12 months? Does the publisher have other recent activity? Have community questions about the plugin gone unanswered?

Plugins from inactive publishers move toward Bucket 2 (Replace) or Bucket 4 (Migrate away).

Step 4: identify what each plugin actually does

For plugins in Bucket 1 or Bucket 2, write a one-sentence description of what they do and why your app needs them. The exercise of articulating this often reveals plugins that look essential but are not.

Step 5: estimate replacement cost

For Bucket 2 plugins, sketch how you would replace them. Sometimes the answer is "two days of work, use a native Bubble pattern." Sometimes it is "two weeks, plus a small code service." The replacement cost determines priority.

Step 6: cost the page weight

For Bucket 1 plugins, especially ones loaded globally, check the impact on page weight. Bubble does not surface this directly. The easiest method is to disable the plugin in a staging environment and compare the network tab before and after.

If a plugin is adding more than 100KB to every page load, that is significant. Consider whether you can scope its loading to specific pages.

Common patterns we see

The "swiss army knife" plugin

A plugin that does many things. You installed it for one feature but it brings along eight other features you do not use, each adding to the page weight.

Replace with a smaller, more focused plugin or with custom logic. Bucket 2 unless there is no good alternative.

The "wrapper around an API" plugin

A plugin whose entire job is to call a third-party API and surface the result. Often the same functionality is achievable with Bubble's API Connector and a workflow, with less risk and more control.

Replace with the API Connector. Bucket 2.

The "I needed this once" plugin

A plugin installed for a specific feature that has since been removed or changed. Nobody removed the plugin.

Remove immediately. Bucket 3.

The "I think we are using this" plugin

A plugin where nobody is sure whether the app depends on it. The editor search shows references; whether those references actually fire is unclear.

Test by disabling the plugin in staging and exercising the app. If nothing breaks, Bucket 3. If something breaks, document what so the next audit does not waste time.

The "this is doing something it should not" plugin

A plugin handling something that should be server-side: authentication tokens, payment processing, sensitive data transformations. Even if it works today, it is in the wrong place architecturally.

Move the functionality out of the plugin to a server you control (a small code service, an API). Bucket 2 at minimum.

When the audit suggests a bigger problem

If the audit ends with a long Bucket 4 list and several abandoned-but-critical plugins, the app is carrying structural risk. Two paths:

• Invest in replacing or owning the critical plugins, accepting that this is now ongoing engineering work
• Plan a migration off the platform where the plugin functionality moves to a code stack with proper dependency management

Neither is wrong. The wrong answer is to leave the Bucket 4 list as it is and hope.

Ongoing plugin discipline

Once you have done the initial audit, prevent the next round of sprawl with a simple rule: every new plugin installation gets a written justification in the team's documentation. What does it do, why is it the best option, when do we review whether to keep it.

This is one short paragraph per plugin. The cost is small. The benefit is that the next audit only has to deal with plugins that were consciously chosen, not the ones nobody remembers installing.

What to do next

If you would like an external review of your plugin inventory, request a free Bubble app audit. The Maintainability section explicitly covers plugin sprawl and risk.

If you want a senior pair of eyes on a specific plugin replacement, book a 30-minute discovery call. Many of our retainer clients use us specifically for plugin replacement work.

Read next: The Canvas tech debt audit and Canvas performance optimisation.