You know that moment when you’re buying a computer on a tight budget and you tell yourself: “I’ll get the good motherboard so I can upgrade later”? You feel smart. Responsible. Future-focused.
Then three years pass. You finally have money to upgrade.
And let’s be honest: you don’t want to just swap in some new RAM. You want the whole new system. The faster processor. The better graphics card. The new case with proper cooling. Everything has evolved, and piecemeal upgrades feel like putting a band-aid on yesterday’s technology.
Plus, half your components aren’t even compatible anymore. That motherboard you paid premium for? It can’t handle the new processor generation. Your RAM slots use the old standard. Your power supply can’t deliver what modern cards need.
You realize the extra money you spent for “upgradeability” would’ve just bought you a better computer when you actually needed it.
So you buy a whole new system. Like you were always going to.
I’ve been building websites for over 20 years, and I see this exact pattern playing out with headless WordPress architecture. The promise sounds amazing: decouple your frontend from WordPress, gain ultimate flexibility, never get locked into a platform. Freedom!
But after watching countless “revolutionary” approaches come and go, I’m betting my business on WordPress blocks instead. Here’s why.
The Headless Promise
Let me be clear: I understand the appeal. The pitch makes perfect sense on paper.
Go headless and you can:
- Switch CMSs without rebuilding your entire site
- Use whatever frontend framework you want
- Deploy the same content to web, mobile apps, kiosks, whatever
- Avoid “vendor lock-in” with WordPress
- Get better performance with a modern JavaScript framework
The logic is sound. The developers advocating for it aren’t wrong about the technical possibilities. And for certain projects, it’s absolutely the right choice.
But here’s what I’ve learned: the best intentions don’t always lead to the best outcomes.
The Migration Myth
The centerpiece of the headless pitch is portability. “When you want to move away from WordPress, you’ll just plug your frontend into a different CMS!”
Except… when does that actually happen?
Think about it. When you finally decide to move platforms, what are you really doing? You’re not carefully lifting your pristine frontend and setting it gently onto Contentful or Sanity. You’re rebuilding because:
Your site is years old by then. Whatever React patterns you used are outdated. Best practices have evolved. That component library seemed like a good idea but now it’s technical debt.
You want to improve things, not just port them. Given the chance to rebuild, you’re not recreating the old site. You’re fixing the navigation that never quite worked. Adding features you’ve wanted. Implementing new design patterns.
The new CMS won’t be apples-to-apples anyway. Content models differ. APIs work differently. Plugins and integrations aren’t the same. You’re adapting, not transplanting.
It’s the same reason nobody does clean WordPress theme migrations. Sure, you could move all that content from Divi to Gutenberg block by block. But why would you? When you rebuild, you rebuild.
The Cost Nobody Mentions
Let’s talk numbers for a moment.
A well-built WordPress site with custom blocks: $15,000 – $30,000 The same site, headless: $40,000 – $80,000
That’s not because agencies are price gouging (well, not always). It’s because you’re paying for:
- Initial architecture complexity
- Custom API development for features WordPress gives you free
- Ongoing maintenance of both frontend and backend
- Developer expertise in multiple technologies
- Hosting infrastructure for separate systems
And here’s the kicker: while you’re spending that premium for “flexibility,” WordPress keeps adding features. The Block Editor keeps improving. Performance keeps getting better. Full Site Editing becomes more capable.
Meanwhile, you’re paying developers to recreate commenting systems, user management, media handling, SEO tools, and a thousand other things WordPress just… does.
The Moving Target Problem
Remember that computer motherboard? By the time you were ready to upgrade, the technology had moved on.
The same thing happens with headless architecture, but faster.
You spend $60,000 building a headless site with React and a hosted CMS. Three years later:
- Your React patterns are outdated
- Your CSS-in-JS solution fell out of favor
- That promising headless CMS raised prices 300%
- The APIs you built against have new versions
- WordPress added features you’re now paying to maintain custom code for
That money you “saved” by avoiding vendor lock-in? It would’ve built you two or three WordPress sites over those years, each one better than the last, each one using current best practices.
When Headless Actually Makes Sense
I’m not anti-headless. I’m anti-cargo-cult.
Headless is the right choice when you:
- Need true omnichannel content delivery (web + native apps + kiosks + IoT devices)
- Operate at genuine scale (think millions of page views, not thousands)
- Have unique performance requirements that require custom optimization
- Have a development team that can actually maintain it
- Have a budget that treats this as the premium solution it is
If you’re building the next Airbnb? Sure, go headless.
If you’re a home builder showcasing your communities, or a contractor explaining your services, or a local business trying to generate leads? You don’t need it. You need something that works reliably, costs appropriately, and can be maintained without a specialized dev team.
Here’s the test: If you have to ask whether you need headless, you probably don’t.
It’s time to stop chasing architectural trends because they’re trendy and start focusing on solving problems with the right solution. Not the most exciting solution. Not the solution that looks best on a developer’s portfolio. The one that actually serves the business.
Why I’m Betting on Blocks
I’m launching a WordPress block framework in a few weeks. That’s a weird choice if headless is the future, right?
But here’s what I’ve seen in my 20+ years: boring technology that solves real problems beats exciting technology that solves theoretical problems. Every time.
WordPress blocks give my clients:
- A visual editor they can actually use
- Reliable hosting that doesn’t require DevOps expertise
- A plugin ecosystem that solves problems without custom development
- Built-in SEO, performance optimization, and security
- Total cost of ownership they can afford
Is it sexy? No. Will it let them deploy to a smart fridge? Also no. Does it solve their actual business problems? Absolutely.
And when they outgrow WordPress? They’ll rebuild. Just like they would’ve rebuilt a headless site. But they won’t have spent an extra $40,000 getting there.
The Wisdom of Boring Technology
There’s a reason successful businesses often use “old” technology. It’s not because they’re unsophisticated. It’s because they’ve learned what actually matters.
Build what works today, at today’s prices, with today’s tools. When you actually outgrow it – not when you theoretically might someday – rebuild with whatever makes sense then.
That future-proofing computer motherboard didn’t save you money. It cost you extra for flexibility you never used. The smart move was buying a good computer for your current needs, then buying a new one when your needs actually changed.
Same with websites.
Look, I’m probably going to get roasted for this take. The developer community loves debating architecture decisions, and I’ve just planted a flag.
But if you’ve successfully migrated a headless site to a new platform and it actually saved you time and money, I genuinely want to hear about it. If you’re running headless and it’s been worth the investment, tell me what I’m missing.
Maybe I’m wrong. Maybe I’m just old and set in my ways.
Or maybe I’ve just been around long enough to recognize when we’re collectively overthinking things.
What’s your experience?