Every custom WordPress theme I build for clients starts from the same small foundation, a starter I maintain called Basic WP, and the reasoning behind it says a lot about how I think growing businesses should run their websites.
After 18 years of building, inheriting, and rescuing WordPress sites, the pattern I keep seeing is that sites fail slowly: a page builder here, a dozen plugins there, and five years later the “simple marketing site” is an unmaintainable knot that gets thrown away and rebuilt from scratch. My whole approach exists to break that cycle. The same architecture currently runs publishers doing daily editorial, credit unions under monthly security audits, B2B SaaS marketing sites, and this site itself.
What Basic WP Actually Is
Basic WP is a deliberately small custom theme skeleton, not a framework. The whole thing is readable in an afternoon:
basic-wp/
├── functions.php # a dozen require_once lines, nothing else
├── lib/ # one file per concern: enqueue, ACF, hooks, admin
├── views/ # layout, pages, partials, sections
├── config/ # ACF field groups as Local JSON
├── assets/ # SCSS source and compiled CSS/JS
└── template-flexible.php # section-based page composition
Templates route to views, views compose partials and sections, and every piece of business logic lives in a named file in lib/. Content fields are defined with ACF and committed to the repository as Local JSON, so the content model is version-controlled alongside the code that renders it. Styles are token-based SCSS compiled to a couple of small files. That’s the entire trick: boring, conventional structure applied consistently.
Built to Spec Means Fast by Default
Performance work on most WordPress sites is archaeology: digging through a theme framework, a page builder, and 30 plugins to find what’s loading 40 scripts. A built-to-spec theme never accumulates that layer. The site ships the CSS and JavaScript it needs and nothing else, markup is exactly what the design requires, and Core Web Vitals are a property of the build rather than a remediation project. When Bastille needed PageSpeed fixed, the answer was a rebuild onto this architecture, not another optimization plugin, and the scores followed.
Minimal Plugins, On Purpose
My production installs typically run fewer than ten plugins, and each earns its place: ACF Pro, an SEO plugin, a forms or security tool where warranted. Everything else, sliders, related posts, redirects, custom post types, integrations, is a small amount of code in lib/ that does exactly one job. Every plugin you skip is an update cycle you don’t manage, a vulnerability surface you don’t carry, a settings page your team doesn’t relearn, and a renewal you don’t pay. The plugin ecosystem is WordPress’s superpower and its failure mode; the discipline is using it for genuinely hard problems and writing twenty lines of PHP for the easy ones.
Redesigns Without Rebuilds
This is the argument I care most about for growing businesses. In this architecture, design lives entirely in the views and the SCSS tokens; content lives in the database and the version-controlled field definitions. A redesign, even an aggressive one, is new templates and a new stylesheet against the same content model. The eCommerce and lead infrastructure, the tracking, the integrations, the URL structure all survive untouched. I’ve carried client sites through multiple full rebrands this way, including a corporate blog that survived three separate rebrands and twelve localized domains on one codebase. Businesses on page builders don’t get this: their design and content are fused, so every rebrand becomes a migration.
AI-Friendly Is the New Maintainable
A conventional, small, version-controlled codebase has quietly become the single biggest productivity multiplier in WordPress work, because it’s exactly what AI coding agents are good at. Tools like Claude Code can hold all of Basic WP in context, follow its conventions, and ship real features: a section type, an integration, an accessibility pass, with a human reviewing diffs in Git. A CLAUDE.md file in the repository documents the conventions once and every future session inherits them.
Try that against a page builder site and the contrast is stark: the “code” is serialized blobs in the database that neither an agent nor a human can meaningfully diff, review, or test. Businesses choosing platforms today should weigh this heavily, because the cost curve of maintaining a real codebase is dropping fast while the cost of maintaining database-resident spaghetti is not. The website that AI tooling can safely work on is the one that gets cheaper to improve every year.
Rapid Iteration, Safely
The workflow around the theme matters as much as the theme: Git for everything, local and staging environments, scripted deploys, and content editors working in structured fields that can’t break layouts. New landing page sections ship as flexible-content blocks editors compose themselves, which is the useful half of a page builder without surrendering the codebase. When a client asked for a complete multi-brand platform on a three-week deadline, this stack is why crexo.com launched in 23 days, and why the fast version and the maintainable version were the same build.
Why This Wins for the Next Decade
WordPress in 2026 gets dismissed by people comparing headless startups against the page-builder mess, but a custom theme on this pattern is a different animal: an enterprise-grade content platform with the world’s most familiar editorial interface, no per-seat licensing, and portability across any host. It stays nimble enough to absorb redesigns, structured enough for AI tooling, small enough for any competent developer to pick up cold, and fast because there’s nothing to slow it down. That’s the bet behind every custom WordPress development project I take on, and after 18 years, it’s the one approach I’ve never had to apologize for later.