Can WordPress be vibe coded?
Open source CMS that runs a huge chunk of the web, plus a paid hosted tier and an infinite plugin economy.
The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a focused build and always has been. An agent can hand you a SQLite-backed CMS with a markdown editor, media uploads, drafts, tags, and a sitemap in a focused implementation, and it will be faster and less hackable than the real thing. What you cannot one-shot is the other 90 percent of WordPress: 60,000 plugins, WooCommerce, Yoast, Elementor, the block editor, and the fact that any freelancer on earth can pick up your site. Also worth noting that core WordPress is already free and self-hostable, so the honest question is whether you want to maintain your own CMS instead of someone else's. If your site has a contact form, a store, or a client who needs to log in, stop reading and just install WordPress.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
medium editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- A single-admin, self-hosted CMS that stores posts in SQLite, edits them as markdown, uploads images to local disk, and serves fast static-ish HTML with an RSS feed.
- Create a constrained editor with preview, publishing, and reusable sections.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- The plugin ecosystem: SEO, forms, caching, memberships, analytics, backups, all one click away in WordPress and all your problem in the DIY build
- WooCommerce and anything resembling commerce
- Gutenberg block editing and the visual page builders non-technical people actually like
- A theme marketplace, so your site looks like whatever the agent felt like that day
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- Years of history, configuration, and habits make migration costly.
Build, switch, or keep paying
Narrower, with trade-offs
A single-admin, self-hosted CMS that stores posts in SQLite, edits them as markdown, uploads images to local disk, and serves fast static-ish HTML with an RSS feed.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
$4/mo
Almost nobody pays for WordPress the software. They pay for managed hosting so the site stays up and patched, for the three or four plugins that quietly run their business, and for the person who knows how to fix it when the theme update explodes. A personal CMS you built yourself removes the hosting bill and adds an on-call rotation of one. That trade is fine for a blog and terrible for anything that takes money.
Visit WordPress ↗Why people still pay
Almost nobody pays for WordPress the software. They pay for managed hosting so the site stays up and patched, for the three or four plugins that quietly run their business, and for the person who knows how to fix it when the theme update explodes. A personal CMS you built yourself removes the hosting bill and adds an on-call rotation of one. That trade is fine for a blog and terrible for anything that takes money.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
Years of history, configuration, and habits make migration costly.
Trust, audits, and counterparties matter more than feature parity.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to WordPress
Context
WordPress — Open source CMS that runs a huge chunk of the web, plus a paid hosted tier and an infinite plugin economy. It currently costs $4/mo.
The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a focused build and always has been. An agent can hand you a SQLite-backed CMS with a markdown editor, media uploads, drafts, tags, and a sitemap in a focused implementation, and it will be faster and less hackable than the real thing. What you cannot one-shot is the other 90 percent of WordPress: 60,000 plugins, WooCommerce, Yoast, Elementor, the block editor, and the fact that any freelancer on earth can pick up your site. Also worth noting that core WordPress is already free and self-hostable, so the honest question is whether you want to maintain your own CMS instead of someone else's. If your site has a contact form, a store, or a client who needs to log in, stop reading and just install WordPress.
This brief describes a focused, single-operator replacement for the part of WordPress that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
A single-admin, self-hosted CMS that stores posts in SQLite, edits them as markdown, uploads images to local disk, and serves fast static-ish HTML with an RSS feed.
Create a constrained editor with preview, publishing, and reusable sections.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
Node 22 and a machine or VPS to run it on.
A domain and TLS if you want it public.
Local disk or an S3 bucket for media.
Your own backup habit.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
Build a self-hosted personal CMS for a single author. Empty folder, no cloud services, no telemetry, no accounts beyond one local admin.
Stack, non-negotiable:
Node 22 with TypeScript, Fastify for the server
SQLite via better-sqlite3, single file at ./data/cms.db, schema created on first boot
Server-rendered HTML with Eta templates, no client framework
Plain CSS in one stylesheet, readable typography, dark mode via prefers-color-scheme
markdown-it for rendering, with a syntax highlight pass and HTML sanitization on output
Features in scope:
Posts and standalone pages: title, slug, markdown body, excerpt, tags, status (draft, scheduled, published), publish timestamp
Admin at /admin behind cookie session auth: one admin user, password hash from ADMIN_PASSWORD_HASH in .env, argon2 or bcrypt
Admin editor: textarea with live preview pane, save as draft, publish, unpublish, delete with confirm
Media upload to ./data/uploads, images resized to a max width with sharp, served with long cache headers, insert-into-post button that pastes markdown
Public routes: home with paginated post list, /posts/:slug, /:pageSlug, /tags/:tag
/feed.xml RSS 2.0, /sitemap.xml, per-post OpenGraph and Twitter card meta tags
Full text search over posts using SQLite FTS5
Scheduled posts appear automatically based on publish timestamp, checked on request, no cron needed
Import script that reads a folder of markdown files with YAML frontmatter and inserts them, so a WordPress export converted to markdown can be loaded
npm run backup that copies the db and uploads into a timestamped tarball
Explicitly out of scope: plugins, themes, comments, multi-user roles, multisite, e-commerce, a block editor, and any hosted API.
Secrets in .env with a committed .env.example. Ship a README with setup, the password hash generator command, and how to run it behind Caddy with TLS. Include a seed script with three sample posts and a page so the site is not empty on first run.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
The plugin ecosystem: SEO, forms, caching, memberships, analytics, backups, all one click away in WordPress and all your problem in the DIY build.
WooCommerce and anything resembling commerce.
Gutenberg block editing and the visual page builders non-technical people actually like.
A theme marketplace, so your site looks like whatever the agent felt like that day.
Any hope of handing the site to a developer who already knows the stack.
Security updates and managed hosting done by someone who is not you.
What you still own after launch
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Maintain every third-party integration as APIs and OAuth rules change.
Risk
Operational risk. The code is achievable; dependable data, integrations, and ongoing operations are the real cost.
Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/wordpress
You still own the product
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.
Projects built from this idea
No reviewed implementation has been linked for WordPress yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of WordPress?Submit the project as evidence for this report.
Before you start
Can WordPress be vibe coded?
Partly, if you narrow it. The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a focused build and always has been. An agent can hand you a SQLite-backed CMS with a markdown editor, media uploads, drafts, tags, and a sitemap in a focused implementation, and it will be faster and less hackable than the real thing. What you cannot one-shot is the other 90 percent of WordPress: 60,000 plugins, WooCommerce, Yoast, Elementor, the block editor, and the fact that any freelancer on earth can pick up your site. Also worth noting that core WordPress is already free and self-hostable, so the honest question is whether you want to maintain your own CMS instead of someone else's. If your site has a contact form, a store, or a client who needs to log in, stop reading and just install WordPress.
What can an AI coding agent reproduce from WordPress?
A single-admin, self-hosted CMS that stores posts in SQLite, edits them as markdown, uploads images to local disk, and serves fast static-ish HTML with an RSS feed. Create a constrained editor with preview, publishing, and reusable sections. A responsive interface with real empty, loading, success, and error states.
What will a DIY WordPress replacement still be missing?
The plugin ecosystem: SEO, forms, caching, memberships, analytics, backups, all one click away in WordPress and all your problem in the DIY build; WooCommerce and anything resembling commerce; Gutenberg block editing and the visual page builders non-technical people actually like; A theme marketplace, so your site looks like whatever the agent felt like that day; Connectors, OAuth flows, and vendor API changes require constant upkeep.; Years of history, configuration, and habits make migration costly.
What do I still own after building a WordPress alternative?
Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss. Maintain every third-party integration as APIs and OAuth rules change.