Why I built this site on Statamic instead of WordPress

WordPress runs roughly 43% of the web. It is the obvious answer when someone says I need a website. It is the answer most agencies will give you. It is almost always the cheapest path from we need pages to we have pages.

I built this site on Statamic.

This is not a WordPress-bashing post. WordPress is the right answer for a lot of websites, maybe most websites. I want to lay out the actual reasons I chose differently for D3 specifically, and the places where WordPress would still be the call I would make for a client.

Reason 1: the content lives in Git

The most fundamental difference between the two is where the content goes after you save it.

In WordPress, when you click Publish, your post is written into a wp_posts row in a MySQL database. Your media goes into the filesystem; everything else lives in the database. The CMS history is a wp_postmeta-based revision log that you can scroll through inside the admin UI.

In Statamic, when you click Publish, your post is written into a markdown file with a YAML frontmatter block. The file goes into a folder. The folder is in the same Git repository as the rest of the site. The CMS history is the Git history.

That sounds like a small distinction. It changes how everything else works.

Drafts become branches. A content review becomes a diff. Reverting a typo becomes git revert. Comparing what the homepage said in March versus today becomes a normal commit log. If you are a developer, you already have tooling for all of this. You do not need a separate plugin to manage content workflows because Git is the workflow.

If you are not a developer, this is mostly invisible. You hit Publish in the control panel, a file gets committed, everyone else fetches.

Reason 2: the public site does not need a database

Statamic's default storage is flat files. The public-facing pages on this site read from markdown and YAML, full stop. There is no database serving traffic.

That has knock-on effects.

No database hosting fee. No nightly database backup chore. No wp_posts table to migrate during a host swap. No SQL injection vector, because there is no SQL.

No database to compromise via a third-party plugin's bad escaping. WordPress sites get hacked through plugins more often than they get hacked through core, and most of those exploits write to or read from the database. Cut the database and you remove most of the playbook.

You can still wire Statamic up to MySQL or MongoDB or Firebase if you need to. For high-volume forms or user-generated content, you probably will. But the marketing site, the blog, the project pages, the about page, all sit on disk as files. Files are easy.

Reason 3: one editor, one mental model

The current state of WordPress editing is a story. There is the classic editor. There is the block editor (Gutenberg). There is a half-dozen page builders: Elementor, Divi, Beaver Builder, Bricks, Oxygen. There is Advanced Custom Fields layered on top of any of them. Most production WordPress sites use two or three of these at once because the previous developer used one and the current developer prefers another.

Editing one page on a typical agency-built WordPress site means knowing which paradigm that page was built in, then loading the right editor for that paradigm, then ignoring the other editors that are still in the admin bar. The editor is no longer a tool. It is a guessing game.

Statamic ships one editor. It is called Bard. Every page, every post, every collection entry uses it. Custom layouts use the same fieldtypes as the homepage. The mental model on a client's third edit is the same as the mental model on their first.

This is the single most underrated thing about Statamic. Consistency in the editor reduces the surface area where a client can get confused, ask a panicked question, or accidentally publish broken content.

Reason 4: Bard is a real block editor

Bard is not a knockoff Gutenberg. It is block-based, and the blocks are composed from the same fieldtypes you use everywhere else in Statamic: text, image, code, set, replicator. Want a custom block? You define a fieldset. No React. No JSX. No build step.

The dark-mode toggle post on this site uses code blocks with syntax highlighting, filenames, and copy buttons. Those blocks are a Bard set defined in a plain YAML fieldset. They look the same in the editor as they do on the published page. There is no edit-in-visual-editor versus edit-in-HTML toggle, because there is no HTML to edit.

The editing experience is the closest thing I have used to what-you-see-is-what-you-get that actually delivers on the promise.

Reason 5: it is a Laravel package, so the ecosystem is right there

Statamic is not a CMS that happens to be written in PHP. It is a Laravel package. You install it the way you install any Laravel package, and the rest of Laravel is right there.

When I needed to add reCAPTCHA, a contact form with custom validation, a honeypot, queued email through Mailgun, and rate limiting, I reached for the Laravel features I already knew: validation rules, mailables, queue jobs, throttle middleware. None of these were plugins. They were language features.

In WordPress, the equivalents are Contact Form 7, plus a reCAPTCHA plugin, plus an SMTP plugin, plus a custom action filter you copy-pasted from a Stack Overflow answer from 2017. Each of these is a separate codebase by a separate maintainer. Each has its own update cadence and its own security history. The chain breaks if any one of them stops being maintained.

I built the contact pipeline on this site in a single afternoon, in one codebase, in code I had written myself. That is not because I am fast. It is because the pieces compose.

Reason 6: content modeling without plugins

WordPress models content as posts. Anything that is not a post (a project, a service, a team member, a press mention) needs a custom post type. Custom post types are easy to register but need plugins (or hand-rolled code) to expose meaningful fields. The de facto standard is Advanced Custom Fields, which a huge percentage of WordPress sites depend on.

Statamic ships custom collections, custom fields, taxonomies, navigation builders, search, live preview, and real-time collaborative editing in core. The advanced custom fields feature is the editor.

If your site is more interesting than a blog with some pages, and most client sites are, that distinction is significant. You either pay the ACF tax (license plus complexity) on top of WordPress, or you get the equivalent for free in Statamic.

Reason 7: deploys are boring

Deploying a WordPress site is unfun. The database in staging differs from the database in prod. URLs are hard-coded into serialized post content. You need wp-cli search-replace to migrate a database to a new domain. Plugin updates need to be staged and tested. The platform makes the easy thing (changing copy in the admin UI) easy and the medium thing (deploying a redesign) hard.

Deploying this site is git push. Forge picks up the push, runs the build, reloads PHP-FPM, and we are done. There is no database to migrate because there is no database. There is no plugin update cascade because there are no plugins. The platform makes the medium thing easy.

The flip side of this is that the easy thing is now slightly less easy. A non-technical client editing copy still uses a control panel, but that control panel is shaped a little more like a developer tool. Which brings us to:

What I gave up

Three real things.

First, the plugin ecosystem. WordPress has a plugin for every conceivable feature, and most of them are free. Statamic's addon directory is small and growing. If you need feature X and Statamic does not ship it, you might be writing it. For a developer, this is sometimes a feature; for a client whose budget said buy a plugin, it is a cost.

Second, name recognition. No client has ever asked me about Statamic. Half my clients ask why I do not use WordPress. The conversation starts at what is Statamic instead of let us pick a Statamic developer. If a client wants to hire any random freelancer to update copy three years from now, finding a WordPress freelancer is trivial; finding a Statamic freelancer is a search.

Third, the cheapest hosting tier. WordPress runs on $5 a month shared hosting. Statamic runs on a $7 a month VPS, and you will outgrow $5 a month shared hosting anyway, but the optics matter to budget-conscious clients.

What clients actually care about

When I list those tradeoffs out, they sound serious. In practice, when I sit with a client and ask what they actually need from a website, the answer is some version of:

The site loads fast. I can update my own copy without calling someone. It looks like our brand. It does not get hacked.

Statamic clears all four. The site loads fast (no database queries on page load). The client can update copy from a clean control panel. It looks like the brand because the templates are just Blade and Antlers, no theme.php, no functions.php inheritance chain, no shortcode rendering. And the security story is much simpler when there is no database and no plugin attack surface.

None of this is a knockout argument against WordPress. WordPress sites also load fast, when configured right. Their clients also update copy without calling someone, when set up right. They look on-brand, when the theme is built right. They do not get hacked, when the plugin diet is disciplined.

The Statamic case is that all four of those things are easier to get right by default, and the failure modes of default are kinder.

The honest answer

I built D3 on Statamic because it is the stack I want to maintain for myself. I am a one-person studio. The maintenance cost falls on me. Statamic gives me a codebase I can hold in my head, deploys I trust, and an editor I do not dread opening.

For client work, the answer is more nuanced. If a client is a marketing team at a mid-sized company, hiring contractors regularly, expecting to swap vendors in a couple of years, WordPress is often the right call. The labor pool matters. The ecosystem matters. Familiarity is its own feature.

If a client is a smaller business that wants a site that lasts, that they will edit themselves, that will not get hacked when they forget to update a plugin for nine months, Statamic is a better fit than its market share suggests. I make that pitch on a per-project basis.

For D3 specifically, where the maintainer is me and the audience is people considering hiring me, the answer was easy. Statamic is fine for D3 because D3 is me.