DEV Community

Mathieu Muller
Mathieu Muller

Posted on • Originally published at tinkernotes.io

Why I Built My Own Site with Astro, Not WordPress when I use WordPress for a Living

The short version — WordPress is a brilliant tool — it's also the wrong tool for a site that's nothing but articles, calculators, and a sitemap. Tinkernotes has no logins, no comments, no checkout, and no database it can't live without. So it's an Astro site built as static HTML and served from Cloudflare Pages. The result is a site that costs £0/month to host, ships almost no JavaScript, and can't be hacked the ways WordPress sites get hacked. If you're a WP dev sitting on a content project, this is the build I'd push you towards.

I've spent eight years shipping WordPress and WooCommerce for a UK agency — custom plugins, themes, gateway integrations, the lot. WordPress pays my mortgage. So the most reasonable question about this site is: why isn't it WordPress? I've had that question from two developers I respect already. Here's the long answer.

The choice I was expected to make

If you'd asked me to build a content site any year from 2014 to about 2022, the answer was reflex: WordPress. Pick a host, install WP, drop in a block theme or build one, add Yoast for SEO, write. I could have had Tinkernotes live in an afternoon and never thought about it again. That's not a knock on WordPress — that is WordPress's superpower. It collapses "publish a website" into a solved problem.

But "I already know how" is a sunk cost, not a reason. So before defaulting, I wrote down what this site actually has to do:

  1. Render articles, reviews, and guides from text I write.
  2. Run two interactive calculators in the browser.
  3. Generate a sitemap, meta tags, and structured data.
  4. Be fast, and stay cheap.

That's the whole list. Notice what's not on it: no user accounts, no comments, no shopping cart, no form that writes to a database, no content edited by anyone but me. The moment I saw the list written out, WordPress stopped looking like the obvious answer and started looking like a lot of moving parts solving problems I don't have.

What WordPress would be carrying that I don't need

A standard WordPress install is a PHP application that boots on every request, talks to a MySQL database, runs the plugin and theme hook stack, and assembles HTML — then you bolt a caching plugin on top to avoid doing most of that. It's a dynamic system pretending to be a static one because, for a content site, static is what you actually want.

Everything dynamic about WordPress is also its attack surface and its maintenance bill:

  • The database. A dependency, a backup job, and a thing that can get out of sync.
  • PHP version drift. Hosts deprecate, plugins lag, you babysit the gap.
  • Plugin updates. Yoast, a cache plugin, a security plugin — each one a small recurring risk and another notification.
  • The login page. /wp-admin and /wp-login.php are probed by bots within minutes of going live. Every WP site I've ever run shows it in the logs.

None of that is hard for me — I do it for clients every week. But it's all labour, and it's labour in service of capabilities this site will never use. Zero of those moving parts make a single article load faster for a reader.

The framing

A blog is read far more often than it's written. WordPress optimises the writing moment — the dashboard — and pays for it on every read with a PHP and database round-trip. A static site inverts that: do the work once at build time, then serve plain files forever.

The stack I chose, and what each piece does

Nothing here is exotic. It's the boring, well-trodden static stack — which is exactly the point.

Astro is the framework. I write content as MDX — Markdown with frontmatter, plus the ability to drop components into the prose. Astro renders every page to plain HTML at build time and ships zero JavaScript by default. The interactive bits — the 3-year cost calculator and the hosting cost calculator — are Svelte "islands": JS loads only for that component, only on the pages that use it. The article you're reading ships no framework JavaScript at all.

Cloudflare Pages hosts it. I push to main on GitHub, Cloudflare builds the site and serves the static output from its edge network. There's no origin server to keep patched, because there's no origin server. The free tier covers unlimited bandwidth and 500 builds a month — comfortably more than a one-person site needs.

Git is the CMS. Content lives in the repo as .mdx files. Every edit is a commit; every commit is a diff, a history, and a one-line rollback. I get drafts via branches and review via pull requests — the workflow I already use for code, now also for prose.

For a developer this is a feature, not a compromise. For a non-technical client it would be a non-starter, and that distinction matters — I'll come back to it.

What I gave up coming from WordPress

I want to be honest about the trade, because "just use a static site" advice usually isn't.

What I gained

  • No server to patch, no PHP version to chase, no database to back up
  • Hosting cost is £0/month on Cloudflare Pages — and stays £0 under traffic spikes
  • No /wp-admin to be brute-forced; the attack surface is basically static files
  • Pages render as pre-built HTML — fast without a caching plugin bolted on
  • Content is versioned in Git: real diffs, real history, instant rollback

What it cost me

  • No dashboard — publishing means a commit and a build, not a "Publish" button
  • No mobile editing, no "fix a typo from my phone in the pub" moment
  • A content rebuild runs on every change; fine at this size, slower at thousands of pages
  • The plugin ecosystem is gone — anything WP gives you free, you wire up yourself
  • It is a developer workflow: hand this stack to a non-dev client and it falls over

The last one is the real boundary. WordPress's enduring genius is that it hands a non-technical person a usable website and the means to run it. The day-to-day editor isn't meant to touch code. Astro-on-Git assumes the editor is the developer. For Tinkernotes — a personal site I both build and write — that assumption holds perfectly. For most of my agency clients it would be indefensible.

What changed once it was live

Three things, concretely.

Performance came for free. No caching plugin, no CDN to configure, no image optimisation stack to tune. The pages are already static HTML with hashed assets, served from the edge. I set a Lighthouse budget of 95+ and hitting it has mostly been about not breaking it, rather than chasing it.

The security worry just... left. There's no admin login to harden, no plugin CVE feed to watch, no "is this theme still maintained" question. A static file can't run a SQL injection. That's not nothing — a meaningful share of agency emergency work is cleaning up compromised WordPress installs.

Cost went to zero and stayed there. No managed WordPress host, no renewal-rate surprise twelve months in. If a post ever does numbers, Cloudflare's edge absorbs it on the same free tier — a static file under load is still just a static file. (Renewal-rate games are exactly the trap I dig into in the Kinsta UK review and Hostinger UK review — worth a read if you are hosting WordPress.)

When I'd still reach for WordPress — and I would

This isn't a conversion story. WordPress is still the right call when the site needs the things WordPress is for:

  • A non-technical person has to publish and manage content independently.
  • The site is genuinely dynamic — accounts, comments, gated content, member areas.
  • It's a shop. WooCommerce on WordPress is still where I'd start most UK ecommerce builds — the whole Shopify vs WooCommerce comparison exists because that decision is rarely obvious.
  • You need to move fast with a known team and a deep plugin ecosystem behind you.

The mistake isn't choosing WordPress. The mistake is choosing it by reflex — defaulting to a dynamic CMS for a job that's pure content, then spending the project budget caching and securing your way back to the static site you could have built directly.

The takeaway

Match the tool to the workload, not to your CV. Tinkernotes is content and calculators with one developer-author, so it's static HTML on the edge. Your next build might point straight back at WordPress — and that's fine, as long as you actually looked.

If you want the longer version of who's writing this and why, the about page covers it. The short version: I still write WordPress for a living. I just stopped assuming it was the answer before I'd heard the question.


More from Tinkernotes:

Top comments (0)