Why I Refuse to Build Headless for Most Clients
The Headless Tax Nobody Budgets For
Last quarter, a prospective client brought us a brief that gave me immediate déjà vu. They were running a high-volume e-commerce operation on a monolithic WooCommerce setup that pulled about two million monthly unique visitors. Their in-house team had spent the prior six months trying to decouple the frontend into a Next.js SPA talking to a headless WP/WooCommerce GraphQL endpoint. Their motivation? Better performance, modern tooling, and separation of concerns.
The reality on the ground was starkly different. Their infrastructure bill had tripled from four hundred dollars a month to over twelve hundred. Their core feature velocity had flatlined because frontend engineers and backend engineers were now permanently bottlenecked by schema alignment meetings. The site's Time to First Byte had actually degraded due to complex edge-rendering waterfalls, and their conversion rate had dropped by 1.8% because of subtle hydration mismatches on mobile safari.
When they asked us to parachute in and finish the migration, my answer shocked them: I told them to throw the Next.js frontend away, return to a monolithic PHP architecture, and invest those engineering hours into database indexing and object caching instead. They looked at me like I had proposed building their checkout form in COBOL.
The Fallacy of the Decoupled Silver Bullet
Software engineering has a recurring habit of prescribing architectural complexity to solve organizational problems. We see this constantly when teams jump to microservices or headless setups. They assume that because Netflix or Shopify uses a distributed stack, their mid-market retail brand or custom SaaS platform needs one too. It's a fundamental misunderstanding of operational overhead.
When you build a headless WordPress or WooCommerce implementation, you aren't just building a website. You are building two separate applications, maintaining two deployment pipelines, debugging CORS issues across staging and production, managing dual caching layers (Varnish/Redis plus CDN edge caches), and forcing your content editors to preview content in a completely disconnected environment.
Let's look at the concrete failure modes we see when teams decouple prematurely:
- The Authentication Maze: JWT token management, cookie syncing across subdomains, and session expiration edge cases add thousands of lines of fragile boilerplate code just to keep a user logged in.
- The Preview Problem: Editorial preview functionality—which comes completely out of the box in WordPress—now requires custom webhook orchestration, preview tokens, and secondary rendering paths.
- The Hydration Tax: Client-side JavaScript bundles bloat, pushing Total Blocking Time up on mid-tier mobile devices where your actual buyers live.
During a recent modernization project for a Fortune 500 apparel brand, the stakeholder push for a headless SPA was intense. We ran a strict proof-of-concept sprint: one team on a decoupled stack, the other on a tightly optimized monolithic Laravel and WordPress architecture with advanced server-side caching. The monolithic approach beat the headless build on every single Core Web Vitals metric, cost one-fifth to host, and shipped three weeks ahead of schedule.
When Headless Actually Makes Sense
I am not anti-headless. We build applied-AI micro-frontends and decoupled systems regularly when the problem domain genuinely demands it. For instance, when we built our internal auto-learning MLB stats engine (Diamond AI) or our multi-model equities ensemble (Vantage AI), a decoupled architecture was mandatory because the ingestion pipeline, the analytical calculation engine, and the UI had entirely different scaling characteristics and deployment frequencies.
If you are building an offline-first mobile application wrapper, or if your engineering team is split into distinct squads with zero overlap who need to deploy React components hourly without touching the CMS database, headless is the correct choice. But if you are a 15-person company trying to ship features faster than your competitors, running a distributed SPA architecture is architectural cosplay.
How to Push Back on Complexity
As senior engineers and technical leaders, our job isn't to pick the shiniest tool in the ecosystem; our job is to minimize cognitive load and maximize shipping velocity. When an executive or a lead developer insists on a headless migration because it's what they read about on Hacker News, force them to quantify the operational cost in writing.
Ask them: What is our exact projected infrastructure cost at peak load? How many hours will our content team lose to broken preview links each month? What is the rollback plan when the GraphQL layer throws a 500 during Black Friday traffic?
Most of the time, the answers reveal that the complexity isn't solving a technical problem—it's just a resume-driven development exercise.
If your monolith is slow, fix your database queries, tune your PHP-FPM pool, implement object caching with Redis, and optimize your assets before you double your engineering headcount just to maintain two codebases.
Never adopt a distributed architecture to solve a discipline problem.
At Champlin Enterprises, we build production systems that balance modern performance with sane operational overhead—learn more about how we approach our engineering services.