Writing This Blog Without WordPress

Since early October 2026, every post on this blog has been a text file that lives in the same code as the rest of popproxx.com. How the posts got out of WordPress is told at the end of my post on headless WordPress, so I won't repeat it here.

This post is about what blogging looks like now: what a post is, how one goes live, what I gave up, what I got in return, and when it's the wrong setup for someone else's blog.

What a post is now

Each post is one file, and the file's name is the post's address. This one is writing-this-blog-without-a-cms.md, so it lives at /blog/writing-this-blog-without-a-cms.

The top of the file holds what WordPress kept in the boxes around its editor: the title, a short summary for post cards and search engines, the date, the author, the topic, the cover photo with its alt text, and up to three posts to suggest under "Keep reading." Every post files under exactly one of six topics. This one is Studio News.

Below that is the post itself, written in Markdown. Markdown is plain text with a few marks for formatting: a line that starts with ## becomes a heading, words between double asterisks turn bold, and a link is the words in square brackets followed by the address in parentheses. John Gruber's original page calls it "a text-to-HTML conversion tool for web writers" (Daring Fireball).

Photos sit in a folder by year and month, inside the same code. A cover photo has no words in it, because the page lays the title over it as live text, and the file records where each photo came from. This one is from Adobe Stock's free collection.

A few posts brought over from WordPress still hold the HTML that WordPress served. When I rewrite one, it switches to Markdown.

How a post goes live

1. The draft starts on a branch

The site's code is kept in Git, a version control system: software that "records changes to a file or set of files over time" so you can go back to any version (Pro Git). A new post starts on a branch, a separate line of changes that leaves the live site alone until it's merged in.

2. The checks run

Before a post is merged, the site's tests run over every post file, and the whole site is built once as a check. The build also reads the top of every post, and a mistake there stops it with an error that names the file, so that mistake can't reach the live site.

3. A preview copy of the site

Vercel, which hosts the site, builds a preview deployment when a change is pushed to a branch other than the live one. Vercel's documentation says preview environments let you test changes "without affecting your production site" (Vercel). The post is read there in the real design: the photo header, the "On this page" box, the offer at the end and the "Keep reading" cards.

4. Merge, and it's live

When the branch is merged, Vercel builds the live site. Each post page is built ahead of time during that build, and the post is live when the deploy finishes. There's no Publish button and no draft status: a file in the main code is a published post.

The checks every post has to pass

The tests read the real post files, the way the post page shows them. A post fails if:

• it isn't filed under exactly one of the six topics;
• its offer has changed. The box at the end of each post is picked from its topic and address, and the tests pin each post's offer, so moving a post to another topic can't quietly change what it sells;
• the byline isn't mine, with my photo;
• the cover photo has no alt text (the description a screen reader reads aloud), or has junk instead. Some posts imported from WordPress had alt text that read "[object Object]";
• the cover photo appears a second time in the body;
• a "Keep reading" pick is a post the site no longer shows;
• a cover photo doesn't say where it came from;
• an image file is missing.

What the tests can't do is read. They can't tell whether a sentence is true or a paragraph makes sense. That's still a person's job.

What I gave up

WordPress's editor. In WordPress you write in a visual editor, see the formatting as you type, drop in images and press Publish. Here, the post is text with a few marks, and the design shows up on the preview.

Plugins. A WordPress plugin is an add-on piece of software you install to extend what WordPress does (WordPress documentation). On a site built in code, anything a plugin would add has to be built or installed in the code.

Publishing without a deploy. In WordPress, a post goes live when you press Publish, and you can set one to publish automatically on a chosen date (WordPress documentation). Here, a post goes live only when the site deploys, and there's no scheduling.

What I got in return

Complete design flexibility. This is the one that matters most to me. Every part of a post, from the photo header with the title laid over it to the "On this page" box and the offer at the end, is drawn by the site's own code, so a post looks however I design it. When a post needs something no template offers, I build it into the post: my post on the real cost of a free website builder has a bar chart drawn in code from real prices.

One system instead of two. Until October, WordPress stored the posts and the Next.js site displayed them: two systems to update, and two that had to keep agreeing. Now the blog is part of the site. On October 10, one change wrote the scope of my content plan add-on onto the add-ons page and into the post that describes it, and the two went live in the same deploy.

A history of every edit. WordPress keeps revisions too: its revisions system "stores a record of each saved draft or published update" (WordPress documentation). Git's history covers more than a post's text. It holds the top of the file, the photos and the code that displays the post, and every change carries a short note saying what it did. As I write this, the file for my post on editing your own website shows six changes, from the import out of WordPress on October 4 to one titled "State the content plan's scope and the Starter blog rule."

Changes across every post at once. On October 10, the blog's 14 old WordPress categories became five topics in a single change. A sixth, AI & Ideas, was added the same day.

No WordPress to keep up. A WordPress site needs updates to WordPress itself, its theme, its plugins and the PHP it runs on, as my post on looking after a WordPress site explains. With WordPress switched off, the blog adds nothing to that list. The site's own code still needs its updates, and the blog is part of that code.

Who this suits, and who it doesn't

It suits a blog with one author, on a site whose code I already look after. It wouldn't suit a team of writers publishing every day, or an owner who wants to publish without waiting on anyone.

On a site I build, you choose how posts get onto your blog:

• You send them and I publish them. They live as files in your site's code, like mine. That time is billed at $150 an hour, in 15-minute increments with a 30-minute minimum.
• I write and publish them. A blog post is $150, or the content plan is two posts a month for $250 a month.
• You publish them yourself. The edit-your-own blog add-on is $500: I put Payload in your site, and one training call shows you how to use it. Payload is open-source software that adds an admin panel to a Next.js site (Payload's documentation). You sign in, write and press publish, without waiting on me.

My post on whether you'll be able to edit your own website goes through each option and when it fits.

Where to start

A blog comes set up on two of my plans: Deluxe, $4,080 for seven pages, and Premium, $6,720 for ten pages with copy written for every page and five blog posts. On Starter, $2,400 for five pages, I quote the blog first.

Each plan is one build fee, paid in full for 10% off or half now and half before launch. The $79/mo care plan starts on launch day and covers hosting on Vercel with SSL, daily backups, uptime monitoring, and security and dependency updates. The edit-your-own blog and every other add-on are listed with their prices on the add-ons page.

Compare the plans, or start a project.