Why I Wouldn't Build Fully Custom WordPress Themes for Most Clients in 2026

Most agencies lose money rebuilding things that already exist. The "we always build fully custom themes from scratch" stance was defensible in 2014. In 2026, it usually means the agency is leaving 30-50% of its margin on the table for the satisfaction of writing the markup itself. I am a custom-development-first engineer by temperament, and even I would not start a typical client project with a from-scratch theme today. The economics do not justify it for most of the work.

Jump to:

• Where I am coming from on this
• What "fully custom theme" actually costs
• What reusable systems give back
• The maintenance over five years
• When fully custom is still the right call
• The middle path that actually scales
• What this looks like in client conversations

Where I am coming from on this

I have built fully custom WordPress themes for the last twenty years. From hand-rolled header.php, footer.php, single.php, archive.php files. Custom-built page templates per design. Custom CSS. Custom JavaScript. The whole bespoke craft of "this site is hand-coded from scratch and reflects no other site's DNA." I am not arguing against that craft as a craft. I am arguing against it as the default economic choice for client work.

The argument is operational, not aesthetic. A bespoke custom theme is a beautiful artifact and a five-year liability. A reusable system is a less beautiful artifact and a five-year asset. Most agencies should choose the asset.

What "fully custom theme" actually costs

Let me put numbers on it. A typical small-business marketing site built from a custom theme:

• Initial build: 60-100 developer hours, plus 20-30 design hours, plus 10-15 PM/QA hours. Total team time: ~100-150 hours. At blended $120/hr, that is $12,000-$18,000 in delivery cost.
• Six-month maintenance ticket flow: ~8 hours, mostly for small content edits the client cannot easily make themselves.
• Two-year refresh: a "minor redesign" typically becomes a full rebuild because the custom template structure was tied to the original design choices. Another 40-60 hours.
• Five-year fate: usually rebuilt entirely on a new agency's stack because the custom theme conventions did not survive a team transition.

The same site built on ACF Flexible Content plus a reusable component template library:

• Initial build: 40-60 developer hours, plus 20-30 design hours, plus 10 PM/QA hours. Total: ~70-100 hours. ~$8,400-$12,000 in delivery cost.
• Six-month maintenance: ~3 hours. Client makes more edits themselves via the Flexible Content interface.
• Two-year refresh: usually a CSS-only change to existing templates because the data shape is stable. ~15-25 hours.
• Five-year fate: still running, still maintainable by the next agency that touches it.

The custom-theme path costs 1.4-1.7x more to build and is 2-3x more expensive to maintain. The agency pockets the difference as margin if they price normally; the client benefits if the agency passes the savings through. Either way, the math favors the reusable system.

What reusable systems give back

When I say "reusable system" I mean specifically: an ACF Flexible Content registration with a fixed set of layouts (hero, CTA, stat row, testimonials, pricing, content grid, FAQ, etc.), plus a matching template-parts directory of PHP partials. Same registration on every client project, restyled per design. Covered in Why Many Agencies Still Prefer ACF Over Gutenberg in more detail.

What this gives back:

• The first project pays for the system. From the second project onward, the system is essentially free.
• Onboarding is faster. New developers learn "the ACF layouts" once. They do not relearn the page structure on every project.
• Content can move between projects. Copy a populated page from one site to another via wp post and wp meta commands and you get a reasonable layout immediately. Useful for client portfolios and proof-of-concept work.
• AI-generated content fits the schema. Because the data shape is standard, AI tools can produce layout data that conforms to it. Covered in Using Claude CLI to Manage WordPress Sites.
• Refreshes are CSS-only. The data shape stays put; the visual treatment changes.

The "loss" is that two sites built on the same system feel structurally similar under the hood. Visually they look totally different (because the front-end implementation is custom). But the editor experience is the same, and the data is the same. For 90% of clients, that is not a problem. They cannot see the schema; they only see their site.

The maintenance over five years

This is the underrated argument. Most agencies massively underestimate the cumulative maintenance burden of custom themes built years apart.

A custom theme from 2019 has:

• jQuery patterns that were idiomatic then and look quaint now.
• A build setup (Gulp / Webpack v4 / Browserify) that the current team does not use.
• CSS architecture (BEM, atomic CSS, ITCSS) that may not match what the team uses today.
• WordPress hook usage that may have been deprecated.
• Plugin integration code for plugins that have since been replaced.

When a 2019 site needs work in 2026, the team has to remember (or re-learn) all of the above before making the change safely. The cumulative cost across a portfolio of 30 client sites, each with their own bespoke conventions, is substantial. Multiplied across years, it becomes the agency's largest hidden expense.

Reusable systems do not suffer from this because the conventions are the same across the portfolio. Updating one site teaches you how to update them all.

When fully custom is still the right call

There are projects where I would push for a fully custom theme:

• Brand publishers whose visual identity is the product. A magazine or fashion-publication site where the editorial design is the differentiator.
• Sites with unusual content models that do not fit any standard component library (an interactive scrollytelling site, an experimental art project).
• Sites with hard performance budgets beyond what a Flexible Content stack can deliver (every byte counts).
• Sites with specific accessibility requirements that demand pixel-precise markup control.
• Sites that the client team has actual engineering capacity to maintain alongside their own development.

For everything else (small business marketing sites, professional services sites, niche industry sites, agency portfolios, restaurant sites, real estate sites, course platforms, SaaS marketing sites), the reusable-system path wins on economics.

The middle path that actually scales

Most successful agencies in 2026 are running some version of this:

• A starter theme the agency maintains in-house, used as the parent theme on every new project.
• A canonical ACF field group registration that ships with the starter theme, defining the Flexible Content layouts the agency supports.
• A template-parts library of partials that the front-end developer restyles per client.
• A handful of ACF Blocks for components the editor needs to drop into long-form Gutenberg body content.
• WP-CLI scripts for onboarding a new site (provisions the database, sets up the user, configures the basic options) covered in Using AI with WP-CLI for Faster WordPress Operations.

The starter theme is the agency's IP. It compounds in value with every project. The fully custom theme, by contrast, was IP that lived and died with the one client.

What this looks like in client conversations

The client will not ask "did you build my site from scratch or on a reusable system." They will ask "does my site look unique and does it work well." The honest answer for the reusable-system approach is: "Yes, it looks unique because we restyled it for your brand specifically. The underlying architecture is something we have refined across many client projects, which is why we can deliver this quality in eight weeks instead of fourteen."

Most clients understand and respect that framing. The ones who insist on a from-scratch build (and are willing to pay for it) are usually doing so for valid brand reasons. Those projects are real and worth taking; they are just not the default.

The "everything custom from scratch" stance made sense when there were no good reusable patterns. We have had ACF Flexible Content as a mature pattern for a decade. We have had Gutenberg as a mature pattern for years. The "fully custom theme by default" position is now a luxury choice, not a default one. Treating it as a default is what causes small agencies to be unprofitable.