Hand-Coded Websites vs WordPress: The Case for a Blank File
When I say this site is hand-coded, I mean the actual, literal thing: the file started empty and every line in it was written on purpose. No WordPress. No page builder. No theme somebody else made that I bent until it looked like mine. If you view the source of this page, you’re reading exactly what I wrote, and I’d argue that’s the single biggest upgrade you can make to a website in 2026.
That’s a big claim from a guy who spent years building WordPress sites for a living. So let me make the case properly, starting with what you’re actually buying when you buy the “normal” way.
What a CMS actually is
A content management system sounds like a filing cabinet. It isn’t. It’s a full software application (a database, a rendering engine, an admin panel, a login system, and a stack of third-party plugins) that rebuilds your page out of parts every time someone asks for it. You don’t have a website so much as a website factory, running around the clock, whose only product is the five pages you actually wanted.
And you become that factory’s maintenance department. Core updates, plugin updates, PHP version bumps, the plugin that breaks when another plugin updates: none of that is your content. It’s the overhead of avoiding HTML. I ran that treadmill for years, for myself and for clients, and here’s the part that finally got me: most of these sites changed a few times a year. We were maintaining a live factory to produce a brochure.
“But my developer hand-codes WordPress”
You hear this on sales calls, and it deserves a straight answer, because it's misleading. What a shop means by a hand-coded WordPress site is that they wrote the theme instead of buying one. That is real work, done by a real developer, and it is genuinely better than bending a purchased theme until it fits. It is also a very small slice of what actually gets served to your visitor.
Add up what ships on that page. WordPress core is hundreds of thousands of lines of PHP that nobody on your project wrote. Then the plugins: forms, SEO, caching, security, a slider, whatever else got activated along the way. Then a scripting language called jQuery, because plenty of those plugins require it. The custom theme sits on top of all of it, and it is the thinnest layer in the stack. A few percent of the code your visitor downloads was written for your site, if that. The rest arrived with the platform, and nobody on the project chose it.
That is the whole argument, and it does not care how well the theme was written. On speed, a perfect theme still ships a page that starts a database query, boots a plugin stack and loads stylesheets you never asked for. On security, every door is in a part nobody on your project wrote: the login page, the plugin whose author moved on, the core release you have not applied yet. Hand-writing the theme closes none of them.
So the honest version of the claim is “we wrote the theme by hand,” and that is a fair thing to sell. It is just not the same product as a site where the file started empty, which is what hand-coded website development means here: not a few percent written for you, all of it.
The weight nobody ordered
Open a page-builder site and view the source sometime. Forty divs deep before the headline, a CSS file for every plugin ever activated, three sliders’ worth of JavaScript for a page with no slider on it. None of it was chosen: it accumulated. And Google measures the result: how fast your page paints and how quickly it responds is a ranking signal, and the plugin stack is on the wrong side of it.
A hand-coded page inverts that. Every kilobyte is there because it does a job, which is why this site ships one CSS file, two small scripts, and pages that are mostly… words. I don’t optimize the bloat away. I just never invite it in.
Nothing to hack, nothing to patch
Here’s the quiet one that should be loud: the overwhelming majority of hacked small-business websites get in through the CMS: a stale plugin, a brute-forced admin login, a database injection. A hand-coded static site has none of those doors. There is no admin URL to guess, no database to inject, no Tuesday-night security patch you forgot. The server hands over a file, the same way it would hand over a photo. You can’t break into a filing cabinet through software the filing cabinet isn’t running.
“But how do you edit it?”
This is the objection the entire CMS industry is built on. Non-developers need to be able to edit their sites. The tradeoff is that WordPress, Shopify, Wix, pages builders, plugins etc. all need to work with as many situations as they can, so they can sell to as many people as possible. You end up storing all that code and using a fraction of it, and it all lives on your site whether you use it or not. When we build a CMS, it lives locally like any other app on your machine. The heavy lifting happens offline, and what's published is only what needs to be. The CMS only grows to support what the site needs instead of attempting to support everything.
The goal of a CMS was never the issue. The fact that they're built for EVERY site's potential capabilities and hosted online where they're vulnerable is the problem.
This is not a static-only pitch
One thing I want to be clear about, because “hand-coded” gets misheard as “small”: this is a starting point, not a ceiling. Every hand-coded website I build starts from nothing and adds only what the project actually needs, and if the job calls for a database, user accounts, a full CMS, it grows into that too. The contact form on this site is a serverless function; it existed the moment I needed it and not a day before. Most sites simply never need the rest, and paying for the rest anyway (in speed, in security, in monthly maintenance) is the thing I’m against. The full pitch lives on the web development page.
The proof, as always, is the site you’re on. Every page of it (including the themes I sell) came out of a blank file. If you want yours built the same way, you know where the door is. It’s the only one this site has.