June 26, 2026 · 5 min read
Why I Chose Headless WordPress + Next.js Over Showit, Webflow, and Framer in 2026
The platform decision that took longer than the build.
When you’re building a site for a client, the platform choice is a recommendation you make based on their needs, their budget, and how much technical overhead they can absorb. When you’re building your own site, it becomes something different. Every limitation is yours. Every workaround is your workaround. The wrong choice doesn’t inconvenience a client. It inconveniences you, indefinitely.
I went through four platforms before landing on headless WordPress with a Next.js frontend. Here’s what I actually evaluated and why each one ended up being the wrong answer for what I was building.
What I Was Actually Building For
The site has to do a few things that most portfolio sites don’t. It needs a real blog infrastructure — not a page with a few posts on it, but an actual publishing system with categories, tags, SEO metadata, and clean URLs I control. It needs to eventually support IDX real estate listings pulled from a live MLS feed. And it needs to be the proof-of-concept for a service I’m building for other businesses — which means the stack has to be something I can replicate efficiently for clients without rebuilding it from scratch each time.
That last requirement is the one that eliminated most of the options immediately.
The Platforms That Didn’t Make It
GoDaddy’s website builder was never a real contender. It’s a fine product for a business that needs a presence and nothing else. It is not a foundation for anything.
Showit is where I spent the most time before walking away. I’ve built client sites on Showit and I understand its appeal — the visual control is genuine, the output is beautiful, and designers can work quickly inside it. But Showit is a closed, proprietary builder that has no meaningful path to AI integration, no real content API, and no way to extend the system beyond what Showit decides to support. In 2026, that ceiling is too low. I’ll write more about this separately because it deserves its own post, but the short version is: Showit is optimized for a way of working that is becoming less relevant, not more.
Webflow I considered seriously. It has a content API, it produces clean code, and the CMS is thoughtfully designed. What it doesn’t have is a clean separation between content and presentation at the level I needed. The CMS is tightly coupled to the Webflow rendering layer, which means the IDX integration I need later would require working against the platform rather than with it. That’s a long-term problem I’d rather not inherit.
Framer is the right answer for a portfolio that lives mostly in animation and interaction design. My site is content-heavy and data-driven. Framer is not built for that and doesn’t pretend to be.
Ghost is close. It’s a genuinely good publishing platform with a clean API, fast rendering, and strong SEO defaults. If this site were only a blog, Ghost would have been the choice. It’s not only a blog.
Every platform I evaluated was the right tool for something. None of them were the right tool for everything this site needs to do.
What Headless WordPress + Next.js Actually Gives You
The architecture is straightforward once you understand the separation. WordPress lives at a subdomain and handles content only. Posts, pages, media, taxonomies. It exposes all of that through the REST API. Next.js, hosted on Vercel, handles the frontend entirely. It fetches content from WordPress at build time or on request, renders it however I want, and serves it at the primary domain.
WordPress never touches the frontend. The frontend never touches the WordPress admin. They communicate through an API, which means I can change either side without breaking the other.
What that gives me in practice is total design control on the frontend combined with a content management system that every writer, editor, and client already knows how to use. No training required. No learning curve. They log into WordPress, write a post, and it appears on the frontend the next time the page is requested.
The IDX integration fits cleanly into this architecture. SimplyRETS returns JSON. Next.js consumes JSON. Building listing pages in Next.js with SimplyRETS data is exactly what the stack is designed for. There’s no plugin to install, no template to override, no platform restriction to work around.
The stack doesn’t have an opinion about what you build with it. That’s the point.
The Tradeoff Worth Making
Headless WordPress with Next.js is not the easiest setup. There’s no drag-and-drop builder. The initial configuration requires real decisions about DNS, hosting, environment variables, and deployment pipelines. If something breaks, you need to know where to look.
For a designer who has never touched a terminal, this is not the right starting point. For someone building a service business around web development, it’s exactly the right foundation — because the same stack that runs this site will run every client site that follows, with the same infrastructure, the same deployment process, and the same design system adapted for their brand.
The replication value compounds over time. The first build takes the longest. Every build after that gets faster because the architecture is already solved.
That’s why this was the right choice. Not because it was the simplest option. Because it was the one that would still be the right choice in three years.
Thinking through your own stack? Reach me directly.