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

Blog /

The four boring parts of WordPress your vibe-coded app secretly needs

By 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. 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 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 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 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

Keep reading

More from the blog.