DesignSetGo apps
How it works Examples Docs Pricing Blog WP Blocks Install free

Blog /

The plugin pile-on: five plugins one DesignSetGo app can replace

By Nealey

A small WordPress site with five years of organic accumulation looks like this in the plugin list:

  • A form plugin.
  • A calculator plugin (because the form plugin’s math was annoying).
  • A snippet plugin (because pasting one tracking script eight months ago was easier than learning the theme).
  • A custom CSS plugin (because the theme’s customizer was too slow).
  • A header/footer scripts plugin (because the snippet plugin was for PHP and this one is for JS).
  • And, ten months later, four more that no one remembers installing.

The site loads fine. It also has 26 plugins active. Each one is its own admin page, its own update channel, its own author with their own monetization model and their own security posture, its own little chunk of CSS and JS, and its own very small chance of breaking the site when it updates.

This post is about the structural argument for why those small bespoke utilities should be one DesignSetGo App instead of N plugins.

The argument is not “all plugins are bad.” The argument is that the plugins in this category, the small custom utilities the site owner installed because they needed a thing, are exactly the wrong shape for what they are.

The category problem

WordPress’s plugin model is great for general-purpose extensions. WooCommerce is a great plugin. Yoast SEO is a great plugin. WP Rocket is a great plugin. These do significant work that is the same across millions of sites, and they justify the plugin shape: a full PHP install, deep WordPress integration, an update channel, a brand.

The plugin model is wrong for custom utility code. The TDEE calculator on a fitness coach’s site does not need to be a plugin. The mortgage calculator on a real-estate agent’s site does not need to be a plugin. The “show me my latest 5 Instagram posts” widget does not need to be a plugin. None of these need PHP, none of them have generality, none of them have an update channel beyond “the site owner asked Claude to tweak it.”

But the only model WordPress offered for these things until recently was plugin. So everything became a plugin. And the small custom utilities the site owner cobbled together became 20 of them, each one a PHP file in wp-content/plugins/.

The structural mismatch shows up as the plugin pile-on.

The five plugins one app can replace (a real example)

I went through the plugin list on three small WordPress sites I help maintain and pulled out the categories that overlapped most. These five almost always coexist:

1. A form-builder plugin for the contact form. Sometimes Contact Form 7, sometimes WPForms, sometimes Gravity. Usually doing one form.

2. A calculator plugin for a custom math widget on a landing page. Calculated Fields Form, Formidable, or whatever was at the top of the search results the day they installed it.

3. A snippet plugin like WPCode or Code Snippets, holding two or three small JS/PHP modifications.

4. A custom CSS plugin for the design tweaks that did not fit in the theme customizer.

5. A header/footer scripts plugin for the Google Analytics snippet, the Facebook Pixel, and the Hotjar tag.

All five exist because the site owner needed something the theme did not provide and the plugin directory was the only place to look. None of these are doing the work that justifies being a plugin. They are utility code that happens to be packaged as plugins because there was no other shape available.

A single DesignSetGo App can subsume the custom parts of all five:

  • The contact form can be a DesignSetGo App with dsgo.email.send(). (For genuinely complex forms with payment integration, keep the form plugin; for the simple “name, email, message” case, the app version is one bundle.)
  • The calculator is exactly what DesignSetGo Apps were built for. The math is JavaScript; the UI is yours.
  • The snippet plugin’s JS modifications belong inside a DesignSetGo App, sandboxed, with declared permissions.
  • The custom CSS belongs in the theme or in the app’s own bundle, not in a separate plugin.
  • The header/footer scripts are best served by a tag manager (GTM) or, if you want them sandboxed, an app that registers them via dsgo.dom.head.append().

You go from five plugins to one app and one or zero new plugins. The plugin row count drops. The admin surface area drops. The update fan-out drops.

What you actually gain

This is not just an aesthetic argument. There are four concrete things you gain.

Fewer admin pages. A WordPress admin with 30 active plugins has 30+ admin menu items. A site owner who is not a power user gets lost in the menu. An admin with 10 active plugins is a different experience.

Fewer update notifications. Every active plugin checks for updates. Every update notification is a UI interruption and a small risk of accidentally clicking “update all” and breaking something. Cutting the active plugin count cuts the update churn.

Less security exposure. Every plugin is code that runs with full WordPress privileges. The supply-chain risk on a plugin (the author getting hacked, the plugin being sold to a less reputable maintainer, the plugin shipping a tracker in an update) scales with how many plugins you have. A DesignSetGo App is sandboxed and runs without PHP privileges. Fewer plugins, smaller blast radius.

Less coupling between unrelated tools. A bad CSS rule in one plugin can leak into another. A JS error in one snippet can break the dashboard another snippet relies on. Each app is its own bundle and cannot affect another app’s runtime. You stop debugging plugin conflicts.

What you give up

This is the part the argument has to be honest about.

You give up the “find a plugin in the directory that does the thing” path. The TDEE calculator, the recipe filter, the mortgage calculator: they are not in the directory as DesignSetGo apps yet. You have to build them (or have Claude build them) instead of installing them.

For most P1 site owners reading this, that is a real cost. “I would rather install a plugin than vibe-code an app” is a defensible position, and it is why the HTML upload importer and the Claude artifact drop flow exist: they collapse the “build” step into “download an HTML file” or “type a prompt.” The path is one step longer than installing a plugin and one step shorter than building a real plugin.

You also give up some plugins’ legitimate features. Gravity Forms has 12 years of edge cases (covered in detail Thursday). Calculated Fields Form has its own form-builder UI that non-coders prefer. If your need maps to those features cleanly, the plugin is still the right answer.

The shorter version: replace plugins where the plugin shape is overkill for the need. Keep them where the plugin shape is exactly right.

The criterion in one question

The question I use:

“If I built this thing fresh today, would I make it a full WordPress plugin with its own author identity and update channel? Or would I make it a small JavaScript bundle scoped to this one site?”

If the answer is “a small JavaScript bundle,” it should be a DesignSetGo App.

If the answer is “a full plugin with its own author identity,” it should stay a plugin.

Most of the small utilities in the plugin pile-on are the first answer. They became plugins because that was the only shape available. They do not have to anymore.

What this does not mean

It does not mean every WordPress site should have one DesignSetGo App and no other plugins. The site I am writing this on has DesignSetGo Apps and 14 other plugins. WooCommerce is one of them. So is a backup plugin. So is a caching plugin. So is a security plugin. None of those should be DesignSetGo Apps; they are infrastructure that justifies the plugin shape.

What it means: the custom utility category, which used to be a plugin because nothing else worked, now has a better-fitting shape. Use the better-fitting shape for that category. Leave the infrastructure plugins alone.

Further reading

Keep reading

More from the blog.