Vibe coding vs hiring a WordPress developer: when each is the right call

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:

1. 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.
2. 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:

1. 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.
2. 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).
3. 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.
4. 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.
5. 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:

1. 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.
2. 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.
3. 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.”
4. 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) are too big for it.
5. 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.

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:

1. 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.
2. 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.”
3. 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. 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: the architectural version of “use both.”
• 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: the same argument applied to calculators specifically.
• docs/competitive-review.md: full positioning against the WordPress plugin and SaaS landscape.