§
§ · wordpress development

WordPress development, without the plugin bloat.

A pagebuilder-exit WordPress practice for content-heavy brands past $1M a year. Custom themes and Gutenberg blocks, WooCommerce, headless Next.js, plus the plugin diet that cuts your 47-plugin site to a lean twelve.

§ 01 · plugin sediment

The average WordPress site runs twenty-three plugins. Most aren't earning their weight.

We audit WordPress sites every week. The sediment is consistent. A page builder (Elementor or Divi) shipping 600 KB of render-blocking JavaScript. Three caching plugins fighting each other. Two backup plugins, one that last ran in 2023. An SEO plugin (Yoast or Rank Math), which earns its place. A form plugin that loads on every page instead of just the contact one. A membership plugin left over from an abandoned course launch. That stack made sense at each individual install. Put together, it is why Core Web Vitals are red, why editors take forty minutes to ship a new page, and why the security surface is a walk-in closet.

reality 01

23 plugins, average.

Median plugin count across the sites we audit in 2026. Healthy sites we ship run 8 to 12. Past 25 plugins, you are paying plugin tax.

reality 02

600 KB pagebuilder payload.

Typical Elementor or Divi build ships 400 to 800 KB of render-blocking JavaScript before the theme adds anything. That is why LCP sits above three seconds on mobile.

reality 03

40 minutes per page.

Pagebuilder sites average 45 to 90 minutes for a non-developer editor to ship a net-new page. A well-built Gutenberg block library cuts that to 8 to 15.

reality 04

Security surface, hidden.

Each plugin is a possible CVE. Patchstack tracks over 4,000 WordPress plugin vulnerabilities a year. Abandoned plugins are the most common entry point.

§ 02 · four layers of WordPress

Four places WordPress code lives. Most agencies work in two.

Every WordPress site is four nested layers. Core, which you never edit. Must-use plugins, always-on with no admin toggle. Plugins, the big zone where bloat and security both live. And the theme, where performance is won or lost. A mature development practice separates what belongs in each. Most agencies conflate plugin logic with theme code and pay for it at upgrade time.

Editorial cross-section schematic of the four WordPress code layers: core, must-use plugins, plugins directory, and theme. Each layer labeled with its /wp-content/ file path and an amber marker on the core layer indicating the layer that is never manually edited.
Fig. 1 · the four layers · where WordPress code lives and where bloat hides
layer 01 · core

Never edit.

/wp-admin/ and /wp-includes/. The open-source WordPress engine, governed by the WordPress Foundation. Updated through the admin or via WP-CLI. If your agency is editing core files, find a new agency.

layer 02 · must-use plugins

Always-on, no UI toggle.

/wp-content/mu-plugins/. Cannot be deactivated by site editors. The right place for security hardening rules, admin-side logging, and essential helpers that should not be toggleable. Used correctly, this layer eliminates class of editor-caused outages.

layer 03 · plugins

Active, dormant, conflict.

/wp-content/plugins/. The layer where both bloat and security surface live. Active plugins load their assets on every page that matches their scope. Dormant plugins still take disk space and sometimes still run hooks. Conflict plugins actively break each other.

layer 04 · theme

Where performance lives.

/wp-content/themes/. Parent theme, child theme, or modern block theme with theme.json. Template hierarchy, enqueued assets, block patterns. A well-built theme ships 40 to 120 KB of render-blocking JavaScript. A bad one loads jQuery across every page.

§ 03 · the plugin tree, in motion

Grow, audit, prune, ship.

Twelve seconds. Twelve branches grow from a core trunk. Each branch is a plugin category: SEO, cache, backup, forms, Woo, ACF, security, payments. Three branches fail the audit and get pruned. The remaining stack is what we ship. This is what the Plugin Diet looks like in one frame.

Fig. 2 · the plugin tree · grow, audit, prune, ship
§ 04 · the Plugin Diet

Ten checks before we touch a single wp-config line.

The Plugin Diet is our two-week pre-engagement diagnostic. Ten checks, cross-referenced against the Patchstack vulnerability database and Core Web Vitals field data. Written report plus a 90-minute walkthrough. The fee is refundable against any engagement that follows. Deliverable is yours even if you hire someone else.

01 · plugin count

Active plugin inventory.

Every installed plugin measured against named purpose. Median 23; target 8 to 12.

02 · payload

Bytes per plugin.

Top 10 heaviest plugins profiled for render-blocking JS and CSS weight.

03 · CWV snapshot

LCP, INP, CLS.

Mid-tier Android over throttled 4G. Homepage, product, top blog post. Biggest blocker for each metric.

04 · security

Vulnerability surface.

Known-CVE plugins, XML-RPC status, 2FA coverage, REST rate limits, wp-config perms.

05 · theme debt

Theme code quality.

Inline styles, jQuery reliance, CPTs stuck in plugins, orphaned parts. Graded A-F with tickets.

06 · editor velocity

Minutes per page.

Time a non-developer editor needs to ship net-new. Pagebuilder 45-90 min; Gutenberg 8-15 min.

07 · hosting

Tier fit + Redis.

Current host vs tier with named alternative. PHP 8.2+, object cache, WAF, CDN status.

08 · database

DB bloat scan.

wp_options autoload risk, post revisions, transients, spam. Queries per page load.

09 · Gutenberg

FSE readiness.

% rendered through block patterns vs legacy. theme.json, centralized design tokens.

10 · SEO

Continuity + schema.

Article + Breadcrumb schema, canonical integrity, sitemap health, hreflang, link depth.

Deliverable is a 30-page PDF with named plugins, measured numbers, and a ticketed 90-day remediation roadmap. Contact for quote on the audit itself; fee refunded against any engagement that follows.

§ 05 · gutenberg · classic · headless

Three ways to build on WordPress. Pick the one your team runs daily.

Every WordPress build picks one of three paths. Gutenberg block theme with Full Site Editing. Classic theme with a template hierarchy. Headless WordPress feeding a Next.js frontend through WPGraphQL or Faust.js. The decision is rarely technical. It is a question of editorial workflow and who edits what.

  Classic theme Gutenberg + FSE Headless (Next.js)
render model PHP templates PHP + block JSON React on Vercel edge
editor control classic editor, developer-led full visual editor, block-composable WP admin, preview via revalidation
dev team needed PHP + CSS PHP + JS + block.json React + TypeScript + GraphQL + PHP
speed ceiling good if disciplined excellent with lean blocks best available, at engineering cost
editorial velocity low, every change needs dev high, editors compose from patterns moderate, preview loop is slower
best for legacy sites being refactored 80% of modern content-heavy builds commerce, portals, app-shared code
wrong for editor teams without dev support teams needing non-WP cart logic editorial sites with daily updates

Eight of every ten custom WordPress builds we ship are Gutenberg block themes. Headless is the exception we talk most brands out of.

§ 06 · the pagebuilder exit

Moving off Elementor, Divi, Bricks, Oxygen. Before it breaks you.

Pagebuilders got your brand to launch. Past $1M in revenue, they usually stop earning their place. Our exit playbook is a rebuild as a native Gutenberg block theme, with a before-and-after performance report and a documented editor training. Timeline is 8 to 14 weeks depending on how much of the source site is salvageable. We have done this for brands moving off each major pagebuilder; here is the decision framework and the shape of the work.

signal 01

Core Web Vitals red on mobile.

If a Lighthouse audit traces your waterfall back to the builder's render-blocking assets as the biggest blocker, the builder is the problem and no amount of caching will fix it.

signal 02

Editors slow to ship pages.

If a non-developer editor cannot ship a new page in under 20 minutes because every template has drifted from the brand system, the builder's editor is no longer saving time.

signal 03

Subscription plus plugin tax.

When the pagebuilder subscription plus the plugin stack it requires costs more per year than a one-time custom theme rebuild would amortize, the math has flipped. Usually happens around 3 years in.

the migration shape
  1. Week 1: source-site crawl, URL map, content inventory, block pattern library design
  2. Weeks 2-4: Gutenberg block theme built with theme.json, 20 to 40 custom blocks via ACF Blocks or native block.json
  3. Weeks 5-8: content migration, URL-by-URL 301 map, SEO continuity pass
  4. Week 9: Core Web Vitals remediation, image optimization, critical-path inlining
  5. Week 10: editor training, pattern library walkthrough, handoff Loom
  6. Weeks 11-14 (if needed): buffer for edge cases, membership integration, WooCommerce rewiring
§ 07 · wordpress vs shopify

Not every brand belongs on WordPress. Here is the honest test.

We run both platforms. Shopify wins when commerce is the entire business. WordPress wins when content is the reason people visit. The honest test is where your editorial team spends their week. If their hours live in product pages, metafields, and merchandising, stay on Shopify. If they live in long-form articles with commerce modules inside them, WordPress wins. The comparison is outcome-based, not feature-based.

dimension WordPress + Woo Shopify + Plus
content ops native long-form, custom post types, taxonomies product pages first, blog an afterthought
SEO surface area unlimited URL structure, full control constrained, handled by theme
checkout WooCommerce or plugin stack, you build trust checkout is Shopify's moat, battle-tested
total cost to own hosting + plugins + dev time monthly fee + app stack + transaction fees
dev velocity infinite flexibility, infinite responsibility fast inside the guardrails, slow outside them
portability your files, your database, your choice checkout and orders lock you in

Use Shopify if commerce is the full business. Use WordPress if content is. Use both (WordPress for content, Shopify headless for checkout) if you genuinely need both engines.

§ 08 · hosting decides 40% of speed

WordPress performance starts at the host, not the theme.

We have a named opinion for every revenue tier. PHP 8.2 or later, Redis object cache, Cloudflare in front. Below those three, no theme build matters. The migration off a bad host is frequently the biggest first-week win we deliver.

tier revenue band our pick why
starter under $1M / year Kinsta or Rocket.net PHP 8.2+, Cloudflare Enterprise included, Redis object cache, staging
growth $1M to $10M / year WP Engine or Pantheon proper dev / stage / prod workflow, global CDN, enterprise support
scale $10M to $50M / year Pantheon Gold or WP Engine Premium dedicated database, Elasticsearch on Pantheon, uptime SLAs
enterprise $50M+ / year, Fortune publishers WordPress VIP SOC 2, Fastly CDN, enterprise support, VIP GO stack

We set up the stack we recommend as part of every engagement. No referral fees, no affiliate arrangements with any hosting provider. Our picks are based on what ships fast and stays up.

§ 09 · twelve-point hardening pass

Every new site ships with twelve security checks. Written down.

Patchstack tracks over 4,000 WordPress plugin vulnerabilities a year. Most breaches come from abandoned plugins, weak admin passwords, and XML-RPC still enabled in 2026. We run the same twelve-point hardening on every WordPress build and every inherited site. None of this is novel; almost no site we audit has all twelve in place.

01Disable XML-RPC (or restrict to allowlisted IPs)
02Lock wp-config.php permissions to 600 or 440
03DISALLOW_FILE_EDIT in wp-config (kills in-admin code edits)
04Enforce 2FA on admin and editor roles
05Rotate admin URL away from /wp-admin
06Rate-limit REST API endpoints (especially /users)
07Remove inactive user accounts quarterly
08Enforce password policy (14+ chars, no reuse)
09WAF active at Cloudflare or Wordfence Premium
10Scheduled malware scans (daily on Plus-tier sites)
11Plugin vulnerability alerts via Patchstack or WPScan
12Automatic minor-version WP core updates on (6.x.y patches)
§ 10 · Core Web Vitals as a launch gate

Real numbers. In writing.

Every WordPress build ships with a published Core Web Vitals SLA. Mid-tier Android over throttled 4G. The Chrome User Experience Report as referee. If numbers land over target at launch, we fix at no additional cost. Representative before-and-after numbers from a 2025 pagebuilder-exit migration below.

metric before (Elementor) after (Gutenberg custom) target
LCP 4.8 s 1.7 s < 2.5 s
INP 420 ms 135 ms < 200 ms
CLS 0.31 0.03 < 0.1
Lighthouse mobile 38 94 > 90
JS transfer (homepage) 780 KB 92 KB < 150 KB
plugins active 34 11 8 to 12

Fig. 3 · representative pagebuilder-exit numbers · anonymized client, 2025 Q4

§ 11 · woocommerce, when it fits

WooCommerce wins where Shopify doesn't.

WooCommerce is not a weaker Shopify. It is a different engine for a different use case. Content-heavy publishers with a merch arm. Professional-services firms selling digital products. Membership sites with commerce modules inside articles. Course platforms with long-form lesson pages plus a checkout. The question is never "Shopify vs Woo" as an abstract comparison; it is "where does the editorial team live."

Woo wins when
  • Content is the brand, commerce is a revenue layer inside it
  • Digital products, courses, memberships, licensed content
  • Custom checkout logic that Shopify Plus cannot express cleanly
  • Brand wants to own payment processing relationship directly
  • International tax logic more flexible than Shopify Markets
Shopify wins when
  • Commerce is the entire business (DTC brands, pure retail)
  • Checkout optimization is the daily job
  • High SKU counts with complex variant logic
  • You want checkout to be someone else's problem
  • Team is not comfortable with hosting and server operations
§ 12 · proof

Three shipped builds, three different shapes.

A short field note from three WordPress engagements in the last 18 months. Numbers are real. Brand names anonymized to respect client NDAs; full named references available on request.

content-heavy wellness publisher

Elementor-to-Gutenberg exit with WooCommerce merch.

11 weeks · pagebuilder exit

Editorial wellness brand on a heavily-customized Elementor build shipped 780 KB of JavaScript on the homepage, LCP at 4.8 seconds, 34 plugins active. Rebuilt as a custom Gutenberg block theme with 28 custom blocks via ACF Blocks, WooCommerce for a digital-product merch arm, migrated to Kinsta with Cloudflare in front. Cut JavaScript payload by 88%, plugin count to 11, editor time from 62 minutes per page to 11. Six-month post-launch organic traffic up 34% without any content changes.

4.8 → 1.7 s
LCP mobile
34 → 11
plugins active
+34%
organic traffic
B2B SaaS marketing site

Headless WordPress on Next.js with editorial preview.

14 weeks · headless

SaaS marketing site needed React-level interactivity for an embedded product demo plus long-form editorial. Built headless on Next.js 14, WordPress as the content backend via WPGraphQL, Vercel deployment with ISR caching, editorial preview routing so editors see changes before publish. Lighthouse 98 mobile, editor training included a pattern library of 22 custom blocks.

98
Lighthouse mobile
22
custom blocks
ISR
revalidation caching
professional-services firm

Plugin Diet + custom theme on inherited multisite.

7 weeks · audit + rebuild

Legal-services firm on a WordPress multisite network (28 sites, shared theme) with 41 active plugins, the top 4 all conflicting. Ran the Plugin Diet audit in week one, cut plugin count to 14 across the network in weeks 2-3, rebuilt the shared parent theme as a Gutenberg block theme with theme.json design tokens in weeks 4-7. Individual child sites kept their content without migration. Post-launch CWV green across every site in the network.

28
multisite networks
41 → 14
plugins network-wide
green
CWV every site
§ 13 · the fit check

We turn down WordPress briefs regularly.

WordPress work against the wrong brief harms both sides. A custom theme build for a brand that needs a pagebuilder exit costs six weeks of wasted trust. Here is the honest filter we run on every intro call.

we're right for you if
  • Content is the reason people visit your site
  • Current site is on Elementor / Divi / Bricks / Oxygen and Core Web Vitals are red
  • Revenue between $1M and $50M a year
  • Editor team willing to move to Gutenberg blocks
  • Willing to prune plugins, not just add custom code on top
  • Decision-maker available for weekly reviews
we're wrong for you if
  • ×Commerce is the entire business (use Shopify)
  • ×Want to stay on Elementor / Divi "just prettier"
  • ×Looking for the cheapest WordPress freelancer
  • ×Want a clone of a competitor's WordPress site
  • ×Expect a custom theme ship in under four weeks
  • ×Treat Core Web Vitals as a post-launch task
what we commit

You own the theme, the plugins, the repository, and the hosting account on day one and on exit. Private GitHub repo under your organization. Documented editor training, Loom walkthrough, 30-day support tail at close. We do not gate access to force retention.

§ 14 · four shapes of WordPress work

Four shapes of engagement.

Pick the shape that matches the moment. We confirm fit on the intro call and send a scoped quote within 48 hours. Scope moves the price, not the conversation.

audit

Plugin Diet audit

2 weeks

10-point diagnostic: plugin inventory, payload, CWV, security, theme debt, editor velocity, hosting, DB, Gutenberg readiness, SEO. PDF + walkthrough. Refundable against any engagement.

for · brands scoping a rebuild
custom theme

Custom Gutenberg build

6–9 weeks

Gutenberg block theme with theme.json design tokens, 20 to 40 custom blocks via ACF or block.json, editor training, pattern library. CWV SLA included.

for · new builds, content-heavy brands
most picked
exit

Pagebuilder exit

8–14 weeks

Migration off Elementor, Divi, Bricks, Oxygen, Breakdance. Rebuilt as native Gutenberg block theme. Before-and-after CWV report. Editor training included.

for · brands past the bloat wall
headless

Headless WordPress

10–16 weeks

Next.js or Remix frontend, WPGraphQL or Faust.js layer, Vercel or Cloudflare deployment, ISR caching, editorial preview. For brands that need React interactivity.

for · SaaS, portals, app-shared code

Quotes sent within 48 hours of an intro call. Hosting + plugin + licensing costs billed by you direct to vendors; we never hold those accounts.

§ 15 · questions

Twelve answers.

How much does custom WordPress development cost in 2026?

Mid-market WordPress work in the US and UK runs $125 to $185 per hour for senior engineers at boutique agencies, with mid-market Indian agencies around $75 to $125 per hour for senior work. Project shape drives total cost more than hourly rate. A custom Gutenberg theme build typically runs 6 to 9 weeks. A pagebuilder-exit migration runs 8 to 14 weeks. A headless build on Next.js plus WordPress runs 10 to 16 weeks. The Plugin Diet audit runs 2 weeks and is refundable against any engagement that follows. We send a scoped quote within 48 hours of an intro call; scope moves the price, not the conversation.

Is WordPress dead in 2026?

No. WordPress powers 43% of all websites and roughly 63% of known-CMS websites as of early 2026 (W3Techs). What is dead is the era of 40-plugin builder stacks held together by custom CSS overrides. The active path forward is Gutenberg with theme.json design tokens, custom blocks via block.json or ACF Blocks, and sparing use of plugins. Headless WordPress on Next.js through WPGraphQL or Faust.js is a valid path for brands that need React-level interactivity with WordPress as a content backend.

Should we migrate off Elementor, Divi, or Bricks?

Only when one of three signals lights up. First signal, your Core Web Vitals are in the red on mobile and the pagebuilder is the biggest blocker (confirmed by a Lighthouse audit that traces waterfall to the builder's render-blocking assets). Second signal, editors cannot ship a net-new page in under 20 minutes because every template has drifted from the brand. Third signal, the maintenance cost of the pagebuilder subscription plus the plugins it requires is exceeding the annualized cost of a custom theme rebuild. Without one of those, keep what you have. The migration we run rebuilds as a native Gutenberg block theme with a before-and-after performance report.

When should I use headless WordPress on Next.js?

Headless WordPress wins when you need React-level interactivity (app-like dashboards, real-time personalization, heavy client-side state), when the site shares a codebase with a mobile app or a React product, or when editorial content needs to feed multiple properties through one API. Headless loses when the site is primarily editorial, edits happen daily, and the editorial team expects to preview exactly what the visitor sees. Classic Gutenberg with theme.json is the right default for content-heavy sites. We turn away more headless briefs than we accept; the extra engineering overhead is only justified when the interactivity or reuse demands it.

WordPress vs Shopify — which is right for a content plus commerce brand?

Shopify wins when commerce is the entire business, checkout optimization is the daily job, and content is in service of the storefront. WordPress with WooCommerce wins when content is the reason people visit and commerce is a secondary revenue stream (publishers with a merch arm, professional-services firms selling digital products, course platforms, membership sites). The honest test is where the editorial team spends their week. If they live in Shopify's product pages and metafields, stay on Shopify. If they live in long-form articles with commerce modules inside them, WordPress wins. We run both platforms; see our Shopify development page for the counterpart.

Gutenberg vs Elementor vs Bricks — which is fastest in 2026?

Native Gutenberg wins the Core Web Vitals comparison for almost every site we have benchmarked. A well-built block theme ships 40 to 120 KB of render-blocking JavaScript on the homepage. Elementor and Divi typically ship 400 to 800 KB before your theme adds anything. Bricks and Breakdance are closer to Gutenberg on speed but lose on interoperability (their markup is proprietary and they lock you into their editor). Our default recommendation for a new build is Gutenberg plus ACF Blocks, with theme.json design tokens and a custom pattern library the editorial team can compose from.

How many plugins is too many on a WordPress site?

The question is not plugin count, it is payload weight and security surface. That said, the sites we audit average 23 plugins; the healthy sites we ship run 8 to 12. A brand-new content site should launch with under 10. A publisher running WooCommerce plus membership plus editorial plugins should sit between 15 and 20. Past 25, you are almost certainly paying plugin tax (duplicate features across three plugins, abandoned plugins still active, trial plugins never removed). Our Plugin Diet audit names each plugin's weight, overlap, and status so the pruning decisions become clear.

What hosting should I use for WordPress in 2026?

By tier. For sub-$1M revenue marketing sites, Kinsta or Rocket.net gives you modern managed WordPress with Cloudflare Enterprise, Redis object caching, and PHP 8.2 for $35 to $115 per month. For $1M to $50M brands with traffic spikes, WP Engine or Pantheon offers staging, global CDN, and a proper development workflow. For Fortune 500 and publishers, WordPress VIP is the defensible answer despite the cost. We set up the stack we recommend; migration off bad hosting is usually the single biggest performance win we deliver in week one.

How do we secure a WordPress site against the common attack surface?

A twelve-point hardening pass every new build runs through. Disable XML-RPC, lock wp-config.php permissions to 600, disable file editing via DISALLOW_FILE_EDIT, enforce 2FA on admin and editor roles, rotate the admin URL away from /wp-admin, rate-limit REST API endpoints, remove unused user accounts, enforce strong password policy, install a WAF at Cloudflare or Wordfence Premium, set up malware scans on a schedule, subscribe plugin vulnerability alerts through Patchstack or WPScan, and keep automatic background updates on for minor WordPress core releases. We ship this checklist with every engagement.

How long does a custom WordPress theme take to build?

Six to nine weeks for a standard 20 to 60 page custom block theme with ACF Blocks, theme.json, a pattern library, and editorial training. Ten to sixteen weeks for a headless WordPress build on Next.js with WPGraphQL. Eight to fourteen weeks for a pagebuilder exit migration (more or fewer depending on how much of the source site is salvageable versus rebuilt). The Plugin Diet audit adds 2 weeks before code and is refundable against the build that follows. Rush timelines are possible but we refuse to compress editorial QA; the timeline moves, not the standard.

Can you migrate a Drupal, Squarespace, Webflow, or Shopify site to WordPress without losing SEO?

Yes. We run every migration with the same three-layer safety net. A full source-platform URL crawl, URL-by-URL 301 map built in a spreadsheet the client reviews, and redirect chain length capped at one hop. A structured-data preservation pass so Article, Product, and BreadcrumbList schema survives the move. And a 90-day post-launch ranking watch in Google Search Console where any URL that drops more than 5 positions gets a same-week remediation pass. 99% URL preservation is the target we publish on every migration. Short-term volatility in weeks 1 to 4 is normal; long-term loss is a process failure, not a platform limitation.

What happens on day one and on exit — who owns the WordPress site?

You do. The theme and any custom plugins live in a private GitHub repository under your organization from day one. The hosting account is on your billing. The WordPress admin is on your domain under your user, with DH engineers added as named users that you remove any time. Design assets (Figma, brand library, screenshots) ship to a shared workspace you own. On exit, we transfer the repository, hand off a documented editor training, record a Loom walkthrough for your team, and leave a 30-day support tail for questions. We do not gate access to force retention; if we are the right partner, you will renew because the work is good, not because the code is hostage.

Start with a Plugin Diet.

Two weeks, ten-point scorecard, written report. You leave knowing exactly what a custom build, pagebuilder exit, or headless move would change. Scoped quote in 48 hours.