Why I Pivoted from WordPress to a Static Site (and What I Lost)

The real reasons I left WordPress, the parts I gave up, and the parts I was surprised to find I did not miss.

The setup I hadUntil this week, ctrlaltbrian.com was a Hostinger-managed WordPress site. Domain registered with Hostinger, hosting on Hostinger's WordPress tier, WordPress installed via the auto-installer, the default "Hello world" post, the default "Uncategorized" category, four posts total over fourteen months. The site was up. The site was technically a blog. The site was not a blog in any meaningful sense, because I had not written anything for it in over a year.The reason I had not written anything was not WordPress. The reason I had not written anything was me. WordPress is a fine CMS, and the missing posts were not WordPress's fault. I have written that part of the story in [the flagship post. The summary is: a working blog writing factory fixed the missing-posts problem, and the missing-posts problem was the only reason the site had been in WordPress in the first place.Once the factory was working, the question changed. The question was no longer "how do I get myself to write." The question was "what should the site actually be." WordPress was the answer to the first question, because WordPress is what I had at the time, and a working CMS is better than a broken one. The factory is the answer to the second question, because the factory does not care what the underlying CMS is, and the underlying CMS does not have to be WordPress.The real reasons I left WordPressThere were three. The first was permission friction. The site was on a Hostinger-managed tier, which meant the role-based permissions I needed to publish posts via the API were not available to the user I had set up. The setup I had was admin in name, and read-only in practice. I spent an afternoon trying to fix it via the wp-admin UI and a Cloudflare-style bot challenge. The afternoon ended with the realization that I was spending more time fighting the platform than I would spend building the same thing from scratch in a weekend.The second was the dependency surface. The WordPress install had the standard Hostinger plugins (LiteSpeed, the AI assistant, the reach plugin, the tools plugin, the amplitude plugin, the Google Site Kit). Each one was a small dependency. Each one could break, become incompatible, or get a CVE. Each one was something I would have to maintain or pay someone to maintain. The cumulative surface was about 12 plugins I had not chosen, did not need, and could not easily remove without breaking the host's "managed" tier guarantees.The third was the content shape. The site I wanted was a small collection of long-form posts, each one a self-contained HTML file. WordPress is built for the opposite shape: a database of posts, dynamically rendered, with comments, with categories, with tags, with a media library, with users, with a settings page, with a database to back up. The site I wanted did not need 90% of what WordPress was doing. The site I wanted needed a folder of HTML files and a way to serve them.What I gave upThe static site does not have comments. That is a real loss. I have read the comments on other people's posts, and good comments add value to a post in a way that even the best post author cannot add. A good comment raises a question I had not considered, points out a flaw in the post, or shares a use case the post did not cover. The static site does not have comments, and so the static site does not have that value. The trade is real.The static site does not have a CMS. There is no wp-admin, no block editor, no "Add New Post" button. To add a post, I open a text editor, write a file, save it, and drop it in the posts/ folder. The workflow is fast, but it is not the workflow I would hand to a non-technical person. The static site is a tool I built for me. It is not a tool I would build for a client.The static site does not have analytics (yet). I am not running Google Analytics, Plausible, Fathom, or any other analytics tool. I will add one when the traffic justifies it, but I do not want to add one before I have a sense of how much traffic there actually is. The default is zero analytics. The upgrade is one tool, added when I am ready to act on the data.What I was surprised to find I did not missWordPress's media library. I had been carrying around the assumption that the media library was important. It is not. The static site has a folder of images, and the images are referenced from the posts that use them. There is no library, and the lack of a library has not been a problem. The mental model is "this post has the images it needs," which is the right mental model.WordPress's user management. The static site has no users. There is me, writing posts in a text editor, and there is the deploy script, which is a bash command. There is no "Authors" page, no "Editors" page, no role-based access to the post-writing flow. The lack of users has not been a problem because I am the only user, and the only user does not need user management.WordPress's scheduled publishing. The static site has a static deploy, which means every post is published at the moment the file lands on the server. There is no "schedule for next Tuesday" button, because the deploy is a single command and the command is run when I run it. If I want a post to publish at a specific time, I run the command at that time. If I want to batch-publish, I drop 10 files in the folder and run the command once. The lack of scheduled publishing has not been a problem because the workflow I actually want is "publish when the post is done," which is the workflow the static site gives me.The deployThe static site deploys in 30 seconds. The deploy is: copy the contents of the ctrlaltbrian-static folder to the web root. There is no database to migrate, no plugin to update, no theme to compile, no cache to flush. The deploy is the most boring deploy I have ever done, and the boring-ness is the feature. I can deploy from any machine with rsync, scp, or even a USB stick. I can deploy on a Tuesday at 3am, or on a Friday at 5pm, or any time in between. The deploy is the part of the site that does not have an opinion about when it happens.That is the contrast with WordPress. WordPress deploys are not boring. WordPress deploys are "did the plugin update break anything," "did the cache flush clear correctly," "did the SSL cert renew on time," "is the database backed up," "are the user roles still set right." Each deploy is a small risk assessment, and each risk assessment is a small piece of attention I have to give the platform. The static site has no deploy risks. The deploy is a file copy.What this is forThis is for people who are considering leaving WordPress for a static site. The case is strongest when the site is content-driven (a blog, a portfolio, a docs site, a small marketing site) and the content shape is "long-form posts that link to each other." The case is weakest when the site is interactive (a forum, a comments section, a paywall, a user account system) and the content shape is "things that change in response to user input."If your site is the first kind, the static site is probably a better fit than you think. The tools have gotten good. There are static site generators for every preference, but the generator I used was none, because the site is 12 HTML files and a CSS file. The static site does not need a generator any more than a Notion document needs a generator. The static site is a folder. The folder is the site.What I would tell past-meIf I could go back to the day I first installed WordPress and tell myself one thing, it would be: the platform is not the problem. The platform is the easy part. The hard part is the writing, and the writing does not care what the platform is. When the writing is working, the platform is interchangeable. When the writing is not working, no platform will save you.I would also tell past-me: do not pay for a managed WordPress tier unless you need the management. The managed tier is a contract, and the contract is "we manage the platform for you." The contract is fine. The contract also means you cannot manage the platform yourself, which is the part I did not realize. The first time I tried to fix the role permissions on my own, the host's "managed" tier guarantees meant I could not. The platform was managed. So was I.Past-me would have done better with a cheap VPS and a non-managed WordPress install, or a static site from day one. The static site is the future-me's choice, and the future-me is happier with the choice. The site is a folder. The folder is the site. The deploy is a file copy. The writing is the part that matters, and the writing works the same in any platform.Want the factory that makes the writing work?The Blog Writing Factory is platform-agnostic. The output is a markdown file. You can publish that markdown file in WordPress, Ghost, Substack, Medium, a static site, a PDF, or anywhere else. The factory does not care. The factory's job is the writing. The platform is your job.Buy on Gumroad. $14

Send me the rough edges if you try it. I read every message.