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

Blog /

Stop paying Vercel, Supabase, and Anthropic for a widget your WordPress site could host for free

By 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 · See the developers page · Read the bridge spec

Keep reading

More from the blog.