Child Themes vs Custom Themes: A Decision Guide for Agency Buyers

Here is the short answer to whether you should use a WordPress child theme or commission a custom theme. Use a child theme when you are making minor visual changes to a well-maintained parent, when the project budget is under five thousand dollars, or when the site has a known short shelf life. Build custom in almost every other situation, especially if the parent is a page-builder framework, the site needs to live longer than three years, or the customizations touch custom post types, custom blocks, or third-party integrations.

That answer will annoy a lot of people who treat child themes as universal best practice, so let me explain why we walk every WitsCode client through five questions before we recommend a path. The child theme pattern was correct in 2014, when premium parents were lean and updates were rare. In 2026 most premium parents are bloated frameworks, block themes have changed what a "theme override" even means, and a child theme on the wrong parent is a debt trap that costs more over five years than building custom from day one.

What a Child Theme Actually Inherits

A child theme is a separate theme folder whose style.css declares a parent in the Template header. WordPress then loads the parent first and lets the child override files by precedence and behavior by hooks. If the child has a header.php, it wins. If the child has a functions.php, it loads alongside the parent's, not instead of it. Block-theme children behave similarly, but the override surface shifts to theme.json, the templates folder, and the parts folder.

That sounds clean. The problem is what comes along for the ride. When you child-theme a premium parent like Avada, Divi, Bricks, or Astra Pro, your ten percent of customization sits on top of one hundred percent of the parent. You inherit every shortcode, every options panel, every asset that the parent enqueues, every dependency on the parent's page builder, and every architectural decision its authors made. Your child is small. Your runtime is not. We have audited sites where the child theme had eight files and the parent loaded forty-three CSS and JavaScript assets on every request, most of them unused.

That bloat is the first invisible cost. The second is coupling. Every override you write is a contract with the parent's current internal structure. When the parent renames a function, restructures its template hierarchy, changes hook priorities, or moves logic from header.php into a get_template_part call, your overrides quietly stop working or, worse, keep working in a broken way. We see this every time a major parent ships a release.

Where Child Themes Quietly Become Technical Debt

The update breakage patterns are predictable once you have lived through enough of them. A parent migrates from a classic theme to a partial block theme, and child template overrides no longer apply because the templates have moved. A parent bumps its minimum PHP version, and a managed host that lags by one major version breaks the staging environment. A parent vendor stops shipping security updates, and the child cannot be moved to a different parent because every override is hand-shaped to the original.

The license question compounds it. ThemeForest's GPL split means your support and update entitlement on the parent has to stay current, which means you are paying an annual license tax on a product you are mostly hiding behind your child overrides. If the parent goes dark or pivots, the child becomes a fossil. We have inherited two sites in the last year where the parent theme was discontinued and the only realistic path forward was a full rebuild, because the child had absorbed enough parent assumptions that decoupling cost more than starting over.

Debugging also doubles. Every issue is now a question of whether the bug lives in the child, the parent, the interaction between them, the parent's bundled plugins, or a hook ordering accident. Senior engineers can chase that down. Junior engineers and freelancers usually cannot, which is why so many child-themed sites accumulate hard-coded workarounds that make the next bug harder to find.

When Child Themes Are Still the Right Call

None of this means child themes are wrong. They are still the right answer in three situations, and we recommend them without hesitation when the situation fits.

The first is a small, brand-level customization on a lean, well-maintained parent. Astra, GeneratePress, and Kadence are honest themes built by teams that ship reliably and avoid framework bloat. If a client needs a different color palette, a tweaked header, and two custom page templates, child-theming one of these parents is fast, durable, and cheap. The maintenance burden is real but small.

The second is a short-lived site. Campaign microsites, event pages, and one-quarter promotional builds do not need to amortize a custom theme's cost. Spinning up a child of a stable parent gets the site live and lets it die gracefully when the campaign ends.

The third is an internal tool, staff portal, or knowledge base where the visual surface barely matters and engineering budget is genuinely tight. Function over form, ship fast, accept the maintenance.

The block-theme version of the same logic applies. A child of a well-built block parent like Twenty Twenty-Four is much less coupled than a child of a page-builder parent, because most overrides happen in theme.json and template files rather than in PHP that depends on the parent's internal structure. If you are going to child-theme in 2026, child-theme a block parent.

How Block Themes and Style Variations Changed the Math

A lot of the historical reasons to reach for a child theme have been absorbed by features that did not exist when the pattern was invented. Style variations let you ship a new look as a single JSON file in the styles folder, no child theme required. Global styles, block patterns, and theme.json handle the majority of customizations that used to need a functions.php override. Hybrid themes let a classic theme opt into block templates one piece at a time. Full Site Editing means a non-developer can change colors, typography, and layout without touching code at all.

The practical effect is that the use cases for a child theme have narrowed. If a client's needs can be expressed in theme.json, you do not need a child theme. You need a style variation, and you can ship it in a fraction of the time and with none of the parent coupling. We default to style variations for any visual change that can live inside the design system, and we only escalate to a full child theme when the work requires real PHP, a custom block library, or a custom post type integration that the parent does not provide.

The Five Questions We Walk Every Client Through

When a prospect calls and asks whether they should child-theme an existing parent or commission a custom build, we run the same five questions every time, and we want to share them as a sequence of judgments rather than a checklist, because that is how the real decision works.

The first question we ask is whether the parent in question is a lean theme or a page-builder framework. If it is something like Astra, GeneratePress, Kadence, or Twenty Twenty-Four, child-theming is on the table. If it is Avada, Divi, Bricks acting as a framework, or any parent whose value proposition is a page builder and a hundred shortcodes, we are already leaning toward custom, because the bloat and coupling costs will dominate over the project's life.

The second question is how long the site is expected to live. A campaign that wraps in six months can absorb almost any architecture. A flagship marketing site that the client expects to run for five years needs to amortize its build cost across that horizon, and a custom theme almost always wins on five-year total cost of ownership once you count the parent license, the update breakage, and the inevitable rebuild that a child theme on a discontinued parent will eventually force.

The third question is the shape of the customization. We count the custom post types, the custom blocks, the third-party integrations, and the bespoke templates the client actually needs. If that count is under three and the rest is styling, a child theme or a style variation is probably right. If the count is over three, the child theme is going to accumulate technical debt fast, because each integration becomes a fight against the parent's assumptions, and each fight leaves a scar in functions.php that the next engineer will have to read.

The fourth question is who is going to maintain this. If the client has an in-house WordPress engineer who is comfortable in the parent's hook ecosystem, a child theme is maintainable. If the client plans to hand the site to a marketing team and a freelancer queue, a child theme will quietly degrade, because freelancers tend to add overrides without understanding the parent's architecture, and the site becomes a layered cake of conflicting assumptions within a year. A custom theme that the agency continues to maintain is much easier to hand off cleanly.

The fifth question, and the one that usually decides borderline cases, is whether the customizations are theme-level or product-level. Theme-level work is colors, fonts, spacing, header layout, the visual surface of the brand. Product-level work is custom workflows, custom blocks that encode business logic, integrations with a CRM or LMS, anything where the theme is expressing something specific to the client's business. Theme-level work belongs in a style variation or a small child theme. Product-level work belongs in a custom theme, because the parent's assumptions will fight you every time the business logic needs to evolve.

If the answers to those five questions point clearly at child theme, we ship a child theme and we tell the client honestly that this is the right call. If they point at custom, we recommend a custom block theme on a clean starter, and we plan the build accordingly.

The Honest Cost Comparison Over Five Years

Child themes look cheaper on day one and are usually more expensive by year three. A child theme on a premium parent costs the parent's annual license, engineering hours to chase update breakage twice a year, the performance tax of inherited assets, and a rebuild somewhere between year four and year six when the parent has drifted far enough that maintenance no longer pencils out.

A custom block theme costs more in week one. It costs almost nothing in maintenance, because there is no parent to drift away from you. The performance is whatever you choose to ship, not whatever the parent loaded. The handoff to a future agency is a single codebase, not a two-codebase puzzle. Over five years the custom theme is usually cheaper in total dollars and almost always cheaper in client frustration.

That is the calculus we run with every WitsCode client, and it is why we offer a theme architecture audit as a fixed-fee engagement before any rebuild conversation. We look at the existing site, count the customizations, evaluate the parent's health, and tell you honestly whether your current child theme is salvageable or worth a clean rebuild as a custom block theme. If you are staring at a child theme that has gotten away from you, a two-week audit is a much smaller commitment than another year of patching.