Vibecode WordPress
track this build5 steps, step by step0%KINDA · weekend project
The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a weekend 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 one sitting, 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.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of WordPress. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # WordPress indie build ## Goal Build the smallest trustworthy replacement for the core WordPress workflow for one developer or a tiny team. ## Scope 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. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - 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 If those capabilities are essential, use WordPress instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build 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. ## Required capabilities - 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 ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of WordPress. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # WordPress indie build ## Goal Build the smallest trustworthy replacement for the core WordPress workflow for one developer or a tiny team. ## Scope 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. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - 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 If those capabilities are essential, use WordPress instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build 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. ## Required capabilities - 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 ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of WordPress. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # WordPress product brief ## Problem The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a weekend 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 one sitting, 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. ## Product outcome 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. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - 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 ## Explicit non-goals for v1 - 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 ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting 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. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted WordPress capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# WordPress indie build ## Goal Build the smallest trustworthy replacement for the core WordPress workflow for one developer or a tiny team. ## Scope 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. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - 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 If those capabilities are essential, use WordPress instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build 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. ## Required capabilities - 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 ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# WordPress product brief ## Problem The thing people actually use WordPress for on a personal site, write posts, upload images, publish, have an RSS feed, is a weekend 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 one sitting, 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. ## Product outcome 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. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - 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 ## Explicit non-goals for v1 - 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 ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting 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. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted WordPress capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent · this prompt is generated from the build plan · improve it via PR
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.
xThe plugin ecosystem: SEO, forms, caching, memberships, analytics, backups, all one click away in WordPress and all your problem in the DIY build
xWooCommerce and anything resembling commerce
xGutenberg block editing and the visual page builders non-technical people actually like
xA theme marketplace, so your site looks like whatever the agent felt like that day
xAny hope of handing the site to a developer who already knows the stack
xSecurity updates and managed hosting done by someone who is not you
Nothing worth pointing at. That's why the prompt exists.
share on X ↗"I just replaced WordPress ($4/mo) with one prompt"
Vibecode WordPress
Kinda. The core of WordPress is buildable in a weekend with the prompt on this page, but there are real gaps: 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. Read the honest list above before committing.
How much does WordPress cost?
WordPress costs about $4/month (Personal, checked 2026-08-18), which is $48 per year.
What do I lose by replacing WordPress?
Honestly: 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. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to WordPress?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.