The WordPress plugin I do not want to build anymore

There is a kind of WordPress plugin I have built too many times.

It starts as a small client request:

Can we add a little calculator to this page?

Or:

Can members see a simple dashboard when they log in?

Or:

Can we make a product selector that recommends the right plan?

None of these sound like plugins at first. They sound like features. Then the feature needs a shortcode, some CSS, a little JavaScript, an admin setting, a REST endpoint, maybe a custom table, maybe a nonce, maybe a place to put the files. Suddenly you are building a plugin.

The plugin is not big. That is part of the annoyance. It is just big enough to own forever.

The maintenance shape

A tiny bespoke plugin still has plugin-shaped responsibilities:

• It has to activate cleanly.
• It has to avoid naming collisions.
• It has to enqueue assets correctly.
• It has to handle updates.
• It has to survive theme changes.
• It has to be backed up.
• It has to be explained to the next person.
• It has to be audited if it touches data.

For a real WordPress feature, that is fine. For a small custom interface, it feels like too much ceremony.

That is the plugin I do not want to build anymore: the one whose job is mostly “render this custom interactive thing.”

AI made the mismatch louder

Before AI coding tools, the cost of building the interface was high enough that the plugin ceremony felt normal. You were already writing code by hand. Creating the plugin wrapper was just part of the job.

Now Claude Code can build the interface in a few prompts. The old wrapper starts to feel disproportionate. The UI got cheaper, but the WordPress packaging stayed the same.

That mismatch is the opening.

If the thing is mostly an interface, it should be packaged like an app, not like a full WordPress plugin. It should have a manifest. It should have a runtime. It should request permissions. It should be isolated from the rest of the site. It should be deployable without pretending every little tool is a first-class plugin.

What still deserves a plugin

I still want plugins for WordPress behavior:

• Custom post types.
• Payment logic.
• Admin workflows.
• Deep WooCommerce changes.
• Editorial tools.
• Server-side integrations.
• Anything that needs to run with WordPress privileges.

Those are plugin-shaped problems.

But a calculator, configurator, dashboard, browser, portal, or landing-page tool is often app-shaped. It needs to live on the site. It may need to read site data. It does not need to become part of the site’s PHP runtime.

That distinction matters more now that AI can produce app-shaped code so quickly.

The better unit

A DSGo App is the unit I wanted for those requests:

• Static bundle.
• Manifest.
• Permission prompt.
• Sandboxed runtime.
• Bridge to WordPress data.
• Deploy command.

It is small enough for a one-off tool and structured enough to be maintained. It gives the code a home without giving it the whole house.

That last sentence is the point. Most small AI-built tools do not need full WordPress privileges. They need a safe place to run and a narrow way to ask WordPress for data.

The founder bet

DesignSetGo Apps exists because I think this category will grow.

AI coding makes bespoke interfaces cheap. WordPress has the content, users, commerce, and distribution those interfaces need. The missing primitive is a runtime that lets those interfaces live inside WordPress without becoming plugins in the old sense.

That is the plugin I want to build: not the hundredth bespoke calculator, but the place where the next hundred calculators can safely live.

The old plugin model is not going away. It should not. WordPress is WordPress because plugins can do deep, server-side, site-changing work.

But not every custom thing deserves that much power.

Nealey