A moment of doubt: should I just use WordPress?
The question
Every builder has the moment. You've just finished wiring up a VPS, debugging Bun's auto-serve quirk, wrestling with Cloudflare SSL modes, and writing systemd unit files. And then it hits you: couldn't I have just installed WordPress?
It's a fair question. WordPress powers a huge share of the web. It has multisite for multiple domains. It has a UI for editing content. It has plugins for everything. Why build a custom engine?
What WordPress gives you
There's no denying the appeal:
- A content management UI out of the box — no Markdown files, no git, no terminal
- A plugin ecosystem covering SEO, caching, forms, analytics, and everything else
- WordPress Multisite for running multiple domains from one install
- A massive community and decades of documentation
For most people building a website, WordPress is the right answer. The question is whether it's the right answer for this project.
Where it breaks down
| Concern | personal-presence-os | WordPress |
|---|---|---|
| Multi-domain | sites.yaml + Host routing |
WordPress Multisite (works, but heavy config) |
| Content format | Markdown files in git | Database (MySQL). No version control by default |
llms.txt |
Generated at build time | Need a custom plugin |
| Deployment | git push → webhook → rebuild |
Plugin updates, database migrations, PHP upgrades |
| Dependencies | 4 npm packages | PHP, MySQL, web server, 20+ plugins for basic functionality |
| Security surface | Static HTML | PHP runtime, database, login page, plugin vulnerabilities |
| Server maintenance | ~15 min/month | Hours/month (updates, backups, security patches, plugin conflicts) |
| Cost | $4/month VPS | Same VPS but needs more RAM for MySQL + PHP |
| Performance | Static files via CDN | Dynamic PHP unless you add a caching plugin |
The fundamental mismatch
WordPress is a dynamic CMS that renders pages on every request. This engine is a static site generator that prerenders everything at build time. WordPress solves a different problem — it's for people who want to edit content in a browser, not people who want content in git.
You could make WordPress generate static HTML (plugins like Simply Static exist), serve multiple domains (Multisite), and output llms.txt (custom plugin). But you'd be adding complexity to remove complexity that WordPress added in the first place.
The real comparison
This engine is ~500 lines of code I fully understand. The WordPress equivalent would be thousands of lines of PHP I don't control, plus a database, plus a dozen plugins, plus ongoing security vigilance. For the same result: HTML files on a CDN.
Every layer you add is a layer you maintain. WordPress adds a lot of layers. Most of them solve problems this project doesn't have.
The answer
No. Not for this project.
WordPress is the right tool when you need a content management UI, when multiple non-technical people need to edit content, when you need e-commerce or membership or forms. None of that applies here.
The custom engine exists because the requirements are specific: multi-domain static hosting, llms.txt generation, Markdown-in-git workflow, minimal dependencies, full architectural control. WordPress could be bent into this shape, but it would fight you every step of the way.
The moment of doubt passed. Back to building.