# Build brief — a focused alternative to WordPress

> **Verdict:** Partly, if you narrow it · **Buildability:** 51/100 · **Category:** Website Builder
> **Source:** https://www.canitbevibecoded.com/wordpress
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from WordPress. Verify current pricing and capabilities before acting.

## 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?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/wordpress