Every bootstrapped founder eventually hits the same fork: build the company website and product on WordPress, or pay for a custom stack. The pitch for WordPress has always been the same — cheaper, faster, familiar to whoever the founder hires next. The pitch against it has always been the same, too — plugin bloat, security patching, and a ceiling on what it can actually do without a developer who really knows the codebase.
That calculation is shifting, and the reason is AI tooling that can now work inside a live WordPress installation instead of just generating code in a chat window.
What Actually Changed
Until recently, asking an AI assistant for help with a WordPress project meant describing your setup in a prompt, copying back an error, and repeating the cycle until something worked. The AI never actually saw your site — your plugins, your database, your custom post types. It was a guess.
That’s changed with the Model Context Protocol (MCP), an open standard originally built by Anthropic that lets AI tools connect directly to a system and act on it — not just talk about it. Applied to WordPress, an MCP-connected AI can read theme files, inspect database tables, and check which plugins are active before it suggests anything, rather than working from a generic description of the problem.
A handful of tools are already built around this. Services like WPVibe AI connect an MCP server straight to a WordPress site so the AI works from the real install rather than a text summary of it, with theme changes staged as drafts and previewed before anything touches the live site. Code editors, including Cursor and Zed, now support MCP connections too, letting a developer query a WordPress environment directly from the editor instead of pasting context back and forth.
Why This Matters For The Buy-vs-Build Decision
WordPress still runs a large share of the internet — 41.5% of all websites, more than any other content management system by a wide margin. The reason it kept that lead even as no-code builders multiplied is the same reason it’s relevant to this shift: an enormous ecosystem of plugins, themes, and developers that a custom stack has to rebuild from scratch. The knock against it was always the labor cost of maintaining that ecosystem safely. AI tooling attacks that specific cost.
Tasks that used to require a specialist — writing a custom REST API endpoint, setting up ACF field groups programmatically, auditing a site full of undocumented plugins from a previous developer — are more approachable when the AI can see exactly what the installation looks like before it writes anything. For a founder paying by the hour or the project, that compresses the two things that make WordPress expensive in practice: the time spent debugging conflicts, and the time spent explaining the project to whoever inherits it.
It doesn’t erase the case for a custom stack. A product with heavy real-time functionality, unusual data models, or performance demands still outgrows WordPress fast, AI or not. But for a marketing site, a content-driven site, or a straightforward SaaS front end, the cost gap that used to push founders toward “just build it custom” is narrower than it was a year ago.
The Part Founders Still Need To Own
None of this removes the need for judgment. An AI that can read a database schema can still write a query that runs but performs badly under load. An AI that knows every plugin on a site can still recommend an integration that quietly breaks something else. The tooling raises the ceiling on what one developer can competently handle — it doesn’t lower the bar on what “competent” means.
For a founder evaluating a dev shop or freelancer, the practical takeaway is to ask directly whether they’re using this kind of tooling, and to still expect them to explain trade-offs rather than defer entirely to what the AI suggests. The permissioning question — what the AI can read, what it can change, and what needs a human sign-off first — is still being worked out across the ecosystem, and it’s worth asking about explicitly before handing over site access.
A Quick Framework
- Lean WordPress + AI tooling if the site is content-first, needs a non-technical team member to manage it day to day, and doesn’t depend on custom real-time features.
- Lean custom stack if the product itself is the software — complex logic, heavy data processing, or performance-critical user flows that WordPress was never built to carry.
- Either way, ask about MCP-style tooling upfront. It changes the cost and timeline conversation with any dev partner, and it’s a fair question to ask before signing anything.
The gap between “cheap and limited” and “capable but expensive” was the whole argument for skipping WordPress. That gap is what’s actually closing — not WordPress’s relevance, which was never really in question.
