Introducing DesignSetGo Apps

I’ve been using WordPress since people still argued about whether self-hosting was worth it. I’ve also spent the last year watching AI coding tools turn what used to be a weekend project into a fifteen-minute one. Those two worlds aren’t talking to each other, and that bothers me.

The vibe-coded stuff lives somewhere else. Vercel. Netlify. A Lovable URL someone pasted in Slack. A standalone site that doesn’t know your customers, doesn’t share your auth, doesn’t show up in your sitemap, and doesn’t get backed up alongside the rest of your business. You build a thing on Tuesday, and by Friday you’ve forgotten the URL.

Meanwhile WordPress, the actual home of your content, your users, your domain, is still treated like it’s only good for posts and pages. Want to add a tool? “Find a plugin.” Want a custom calculator? “Hire a developer.” Want to drop in something Claude wrote you? Good luck.

DesignSetGo Apps is the bridge.

What it actually is

A WordPress plugin. You install it, and your site grows a new surface: /apps/{slug}. Each app is a static bundle (HTML, JS, CSS) that lives inside your site, served from your domain, on your hosting plan. Nothing new to log into.

Apps run in a sandboxed iframe (or, optionally, an inline-rendered mode for SEO-friendly multi-page apps). They can’t touch your theme, your other plugins, or your database. What they can do is talk to a permissioned bridge: a postMessage protocol that lets an app ask “give me the latest 10 posts in this category” or “who’s the current user,” and the plugin answers if (and only if) the app’s manifest declared it needs that data, and you approved it at install time. Same model as a browser extension.

That’s the whole pitch in one sentence: sandboxed enough to be safe, connected enough to be useful.

And if you want, the app can be the website

The default lives at /apps/{slug}. But an app’s manifest can also declare mount.mode: "root", and now it serves at /, with no prefix and no slug. One app per site, and it never shadows real WordPress pages, posts, archives, or feeds (those still win). Inline-mode root apps go further: any path WordPress would otherwise 404 on falls through to a route the app declares, so a multi-page app with its own routing effectively becomes the whole site, with WordPress quietly running underneath as the CMS, the auth layer, and the data source.

That changes what the plugin is. It’s not just “host a calculator on your blog.” It’s “build the entire front-end of your WordPress site as an app you wrote in fifteen minutes with Claude Code, while your team keeps editing posts and pages in wp-admin like nothing happened.” The /apps/ surface is for additive tools. The root mount is for replacing the whole front-end.

Two ways to build

You don’t have to pick a stack or a workflow. The runtime doesn’t care where the bundle came from.

In the browser. Open the admin page, drop in an HTML file (a saved Claude Artifact, a Bolt/Lovable export, anything self-contained), and get a URL. The harness can also generate apps from a prompt via WP-CLI (wp dsgo harness generate --prompt="..."), routed through the WP AI Client so it uses whichever provider your site is configured for. No separate keys, no separate billing.

From Claude Code locally. npx designsetgo apps init scaffolds a starter project with a typed bridge client and a CLAUDE.md that teaches the agent your manifest format. Build, iterate, test. When you’re ready, npx designsetgo apps deploy --build pushes the bundle to your site. It’s there in seconds.

Same runtime. Same permissions. Same /apps/{slug} URL. The casual user and the Claude Code power user end up in the same place.

Why now

WordPress 7.0 (May 2026) shipped three things that change what’s possible in a plugin:

• Connectors API: site admins configure their AI provider once, every plugin inherits it
• WP AI Client: provider-agnostic PHP API for invoking the model
• Abilities API: a way to register functions the site’s AI agent can call

Together, those mean a plugin can offer real AI features without holding API keys, without paying for inference, and without locking users into one provider. DSGo Apps is built on top of that stack. Apps you build can both consume AI (via the bridge) and publish their own abilities for the site’s agent to invoke. (More on that one in a later post.)

What’s next

The plugin is real. The bridge spec is frozen at v1. The CLI ships, the importer ships, the AI surfaces ship. There’s plenty more to build (block embed, write permissions, more bridge methods), but the wedge is in.

If you’ve been waiting for a way to let WordPress hold the things AI is helping you build, this is it. Try it, break it, tell me what’s missing.

The docs are the place to go deeper: manifest schema, bridge API, the works. The follow-up posts in this series cover the safety story, the Claude Code workflow, and how apps can publish abilities your site’s AI agent can call.

Justin