DesignSetGo vs headless WordPress

Headless WordPress has been the recommended architecture for fancy WP front-ends for about five years. Build the front-end in Next.js or Astro or Nuxt; talk to WordPress through REST or GraphQL; deploy each side independently; rejoice in the modern developer experience.

In practice, the engineering work that actually matters in a headless build (modeling content, designing the visual system, writing the templates) is a fraction of the total time. The rest is the headless tax: the auth bridge, the CORS configuration, the build cache, the preview environment, the third-party-cookie issues that break embedded video, the moment marketing asks why a publish took 15 minutes to show up. None of those problems are fundamental. All of them are rituals teams do because the architecture has put a wall between the two halves of the same product.

DesignSetGo Apps points at a different shape of answer. This post is the comparison. Headless wins on some axes; DSGo wins on others. The honest version of when each one is right is, I think, more in DSGo’s favor than the prevailing recommendation suggests, but you should pick based on your actual constraints, not on which one I prefer.

The headless diagram

A typical headless setup, at the architectural-diagram level:

• WordPress lives on its own host, serving the admin UI plus a REST or GraphQL endpoint.
• The front-end (Next.js, Astro, Nuxt) lives on a separate host (Vercel, Netlify, Cloudflare Pages).
• The front-end fetches content from WordPress at build time (for static pages) or at request time (for dynamic ones).
• A reverse proxy or DNS routing makes the two look like one origin to the visitor.
• Auth, if any, is mediated through tokens passed between the two halves.

Each piece of that diagram has a real cost.

Two hosts. Two bills, two deploy pipelines, two sets of secrets, two monitoring dashboards. If something breaks, you debug across both. When the team is one or two people, this is one or two people’s worth of mental overhead just keeping the lights on.

The CORS conversation. The front-end is on a different origin than the API, except when it’s behind the reverse proxy, except for the CDN edge cache, except for the authenticated requests, except for the preview routes. There’s a meeting where someone explains the CORS configuration. The meeting takes an hour. Three months later, someone changes a header and the configuration silently breaks for one type of request that nobody tests until the marketing director’s preview link doesn’t work.

The auth seam. The visitor is logged into WordPress, except the front-end doesn’t know that, because the cookie is on the WordPress origin and the front-end is on a different origin, so you implement an auth bridge: the front-end calls a WP endpoint with credentials, gets a token, stores it, includes it in subsequent calls, refreshes it on expiry. Each one of those steps has failure modes. Each one is something the team had to build instead of building product.

The cache invalidation conversation. The marketing team publishes a new post. The front-end’s static-build pipeline runs, but only on a schedule, so the post takes 15 minutes to appear. You add a webhook that forces a rebuild on publish. The webhook fires, but only on certain post types. You add another rule. The rules accumulate. Every rebuild takes four minutes. Marketing complains the site is slow to publish. Someone proposes ISR. The complexity goes up.

The development environment. Each front-end developer needs a way to run WordPress locally so they can test against real data. Each front-end developer reinvents the docker-compose file. The data drift between local and prod is a constant low hum of bugs.

None of these are fundamental. All of them are rituals you do because the architecture has put a wall between the two halves of the same product.

What DSGo does instead

DSGo Apps puts the front-end inside WordPress. The Astro bundle (or Next.js export, or hand-written HTML) is served by WordPress as a static asset under the existing hosting plan. The bridge is a same-window postMessage call; there’s no network hop. Auth is whatever the visitor already has with WordPress. The deploy is one command.

The diagram is one box.

• WordPress lives on its host.
• The DSGo App is a static bundle inside WordPress.
• The bundle calls the bridge for WordPress data.
• The visitor sees one origin, one site, one auth, one experience.

The headless rituals don’t exist because the architectural assumption that produced them isn’t there. There is no second host. There is no CORS conversation. There is no auth bridge. There is no separate deploy pipeline. There is no cache-invalidation rule list. The moments where headless’s complexity earns you something (independent scaling, framework freedom, edge TTFB) become the moments where DSGo’s simplicity costs you something. Same trade, opposite directions.

What you give up

I want to be honest about this. There are things headless gets you that DSGo doesn’t.

Independent scaling. A headless front-end can run on Cloudflare’s edge while WordPress runs on a single $20/month box. With DSGo, the front-end’s traffic shape is whatever WordPress’s hosting can serve. For most sites this is fine. For sites doing >10M pageviews/month, headless’s edge scaling story matters and DSGo’s “WordPress hosts everything” model has a ceiling.

Framework freedom. Headless lets you pick any framework. DSGo runs static bundles inside its iframe (or inline) runtime. Most modern frameworks compile to static bundles, so this is mostly a non-issue, but if you specifically want server-side rendering with framework features (Next.js dynamic routes with per-request props, SvelteKit’s load functions), you have to compile those down to static or accept that some parts won’t run.

Build-time vs request-time data. Headless’s static-build model lets you generate every page ahead of time, which is great for SEO and TTFB. DSGo’s bridge runs in the browser, so dynamic data fills in at view time. For SEO purposes, you’d want page-level signals (<title>, <meta>, headline <h1>) in the static markup, with the dynamic bridge data filling in after. The plugin’s dataset-injection feature gets some of the way there (substitutes {{title}} etc. into templates server-side), but it’s not the same as a full Astro Content Collections build. For sites where every page must be fully static, headless wins.

Multi-region origin. A headless front-end on Cloudflare or Vercel runs in 200+ regions. WordPress runs in one (unless you’ve gone to extraordinary lengths with multisite, replication, and DNS). The TTFB difference is real for global audiences. If 30% of your traffic is in Europe and your WordPress is in us-east-1, headless’s edge gives you a meaningful improvement that DSGo cannot.

The honest summary: headless wins on scale, framework power, and global TTFB. DSGo wins on simplicity, cost, time-to-ship, auth integration, and editor familiarity.

Where each one is the right call

Reach for headless when:

• You’re at scale where edge TTFB matters more than developer time. (If you don’t know whether you’re at this scale, you aren’t.)
• The front-end is a small subset of your overall product, and decoupling helps with internal team boundaries.
• You have a dedicated front-end team that genuinely wants to live in the modern JS world, and the team’s productivity actually improves with a separate stack.
• The site doesn’t need WordPress’s auth, comments, search, or other Core features (you’re using WP only as a CMS).
• You expect to migrate off WordPress eventually and want the front-end portable.

Reach for DSGo when:

• The site is small to medium scale, served from one origin, where the boring thing is the right thing.
• You want WordPress’s whole feature surface (auth, plugins, editor familiarity, sitemaps, comments, the works) to “just work” without building bridges to it.
• The team is one to three people and the cost of a glue layer dwarfs its benefit.
• The front-end is the front-end of a WordPress site, not a side project.
• The editor needs to keep using wp-admin (which, for most marketing-owned sites, is non-negotiable).
• You’d rather have one deploy and one bill.

For my own work, the DSGo path covers ~80% of what I want a “fancy WordPress front-end” to do, at a fraction of the engineering cost. Headless covers the remaining 20%, but the cost gap is large enough that I default to DSGo and reach for headless only when there’s a specific reason.

For client work, the gap widens. Most clients ask for “a fast modern front-end” without understanding what they’re trading. Headless looks better in the demo and worse on the second-year invoice. DSGo looks underwhelming in the demo (it’s just a WordPress site) and better on the second-year invoice. If you can sell the client on the second-year argument, DSGo wins; if you can’t, the client picks headless and you both relearn the lesson together.

The retrospective most teams have

A pattern worth flagging, which you’ll see in discussions of headless WordPress on Reddit, in agency retrospectives, and in conference talks from teams who’ve lived with these builds: the observation isn’t that the headless build was bad, it’s that the cost-to-value ratio over time was wrong, and what teams actually wanted was a polished WordPress site. The version of “polished WordPress site” that has a really modern front-end is now what DSGo Apps is for.

If those projects were starting today, many of them would be DSGo. The Astro template, root mounted, fetching from the WP REST API at view time, with the editor team doing whatever they do in wp-admin and not noticing the front-end is anything special. Faster to ship. Cheaper to maintain. Same end-user experience.

The unifying observation

Architectural fashion in our industry has a tendency to put walls between things, then sell us tools to build bridges across the walls. Microservices. Service meshes. Edge functions. Distributed monoliths. Each one has its place. Each one is also frequently overdeployed against problems that didn’t actually need walls in the first place.

Headless WordPress is, to me, an example of a wall that mostly didn’t need to be there. The original arguments for it (“WordPress is a bad front-end framework,” “the editor experience is best decoupled from rendering”) were once true and have been less true every year, especially since the block editor matured and especially since WP 7.0’s Connectors and AI Client made WordPress a viable platform for AI features. The architectural cost of headless is large; the engineering benefit is shrinking.

DSGo is a bet that the right answer for most sites is to keep WordPress as the platform, build the front-end you want as a static bundle, and use a thin permissioned bridge to span the small remaining gap. That’s not a revolutionary idea. It’s just a different stance on whether the wall is worth building.

Where to go next

• The Astro on WordPress post for the concrete walkthrough of “build it as Astro, ship it as a DSGo App.”
• The iframe-vs-inline post for what the runtime modes actually do.

Nealey