Vercel is the wrong place for your WordPress widget

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:

1. Ask Claude Code or v0 to build a small app.
2. Get a working local project.
3. Deploy it to Vercel.
4. Copy the Vercel URL.
5. 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