Every few years, a new wave of WordPress tooling promises to make handwritten code obsolete, whether it's drag-and-drop builders, theme-of-themes systems or "no-code" plugin stacks. The pitch is always the same: faster to ship, easier to maintain, fewer specialists required.
We've looked closely at most of them, and we've inherited and rescued sites built on most of them. We still build WordPress sites by hand, because for business sites that need to last, hand-built code ages best.
This post explains what we mean by "build by hand" in 2026, and why we stick with it.
What "by hand" means now
By hand doesn't mean writing every line from scratch like it's 2008. WordPress in 2026 has a mature stack that makes custom builds much faster than they used to be, without giving up portability.
Our default stack:
Block themes. Native block-based theming with modern templates, the Site Editor for content owners who want it, and full PHP control where that helps. There's no proprietary template engine and no "lifetime license" you lose access to if you cancel.
ACF Pro. Advanced Custom Fields for structured content, which keeps editing sane. Custom post types, field groups, repeaters and flexible content are all rendered through your own theme code rather than someone else's templates.
Modern PHP. PHP 8.x with real type hints, dependency management via Composer where it makes sense, and a normal file layout that any WordPress developer can read, with no bespoke framework on top of the framework.
Clean front-end. Hand-written CSS (often Tailwind), minimal JavaScript, lazy-loaded images and properly responsive layouts, which keeps page weight low enough to defend in a code review.
It's not a glamorous stack, but it's what the fastest, longest-lived WordPress sites we run are built on.
Why the alternatives feel productive, and what goes wrong later
Page builders feel productive on day one. You drag, drop, save and publish, and early progress is fast.
The cost shows up on day 200. Pages get heavy because every block ships an inline style block and a few hundred lines of JavaScript, and the site starts to feel sluggish. A content editor tries to add a section and finds the builder won't let them do what they need. The fix is "buy this add-on plugin" or "find a contractor who knows this builder."
By day 800, the site is a liability. The team that built it is gone, and the builder has shipped four major versions in the meantime, each of which broke older content in small ways. The "redesign" turns into a rebuild because untangling the builder's HTML costs more than starting over.
We see this pattern in most of the rescue projects we take on. Builders are good at what they were designed for: prototypes, internal tools, and marketing landing pages with a 12-month lifespan. They're the wrong choice for a business website that has to keep earning for a decade. Why page builders hurt sites that need to last goes deeper on this.
What hand-built buys you
The benefits build up over time rather than showing up on day one.
Performance you can defend. A hand-built page can ship with only the HTML, CSS and JavaScript that page needs, not 800KB of builder runtime because the home page uses a tab block. The Core Web Vitals difference usually shows up for anyone running Lighthouse and, more importantly, for real visitors. We covered the underlying mechanics in why your website feels slow even when hosting looks fine.
Maintainability another developer can pick up. If we get hit by a bus, your next developer opens the theme folder, sees a normal WordPress block theme with ACF, and is productive within a day. There's no proprietary builder language to learn, no license to inherit, and no "you need this developer's account to access the original files."
SEO and AI visibility that holds up. Clean, semantic HTML, Schema.org JSON-LD where it's useful, and page weight that doesn't get penalized in Core Web Vitals. The same fundamentals that make a site fast also make it more likely to be cited by AI engines, as covered in modern SEO, AEO, AIO, GEO explained.
Editorial freedom. Content owners get blocks built for the things they need to do, instead of a generic toolbox with 80 options that mostly don't apply. Fewer, better-fitting options make editing faster.
Portability. You can take the site to any host and hand it to any developer who has worked with WordPress. There's no proprietary layer that needs us in particular to keep it running.
When a builder is the right call
We're not against builders in general. There are cases where they're the right tool.
A marketing site that will run for 6-12 months and then be replaced. Internal-only tools where editing speed beats page weight. A one-person business that can't afford a custom build and needs to edit everything themselves. A landing page that will be A/B tested aggressively and needs visual changes nightly.
For most of those, we'd recommend a builder, and we'd tell you up front what you're trading for the speed.
How this shows up in a project
A typical build with us starts with a scoping conversation and a content and structure review, then design that fits how your team will edit the site, then a build using the stack above. We stage everything, migrate carefully, and keep hosting the site after launch.
Because the same person builds, hosts and maintains the site, we build with the long-term running cost in mind. We don't ship 12 plugins that each "do one cool thing" and each add maintenance, or build things that impress at the launch demo and are painful to update six months later.
If you're planning a new WordPress site, a redesign, or a major addition to a site you already have, our Design & Development service is built around this approach. Or start a conversation and tell us what you have. We'll give you a straight opinion on the right next step, even if it isn't us.
