Headless commerce development services, and when to skip headless.

What headless commerce development is#

Headless commerce development means building the storefront as its own application while the commerce platform runs everything behind it. Shopify's headless docs put it in one line: "Headless commerce separates your storefront's frontend from its backend."

The platform keeps the catalog, prices, cart, checkout, orders and customer accounts. The storefront is a Next.js app that asks for that data through the platform's API and renders the pages shoppers and search engines read. The two halves ship on their own schedules, which is the whole point and the whole cost. The APIs in play:

• Shopify: the Storefront API, a versioned GraphQL API, plus the Customer Account API for sign-in, orders and addresses. Hydrogen is Shopify's toolkit on top.
• BigCommerce: the GraphQL Storefront API, which its own Next.js storefront, Catalyst, is built on.
• Adobe Commerce and Magento Open Source: two GraphQL implementations. Open Source and Adobe Commerce on cloud or on-premises share the core schemas. Adobe Commerce as a Cloud Service runs a supergraph whose service-based catalog queries "are not backward compatible with the core queries," and doesn't support Luma.

Content usually comes from a headless CMS. Make every piece a separate service and you get "composable" commerce, which most stores don't need.

The head, the body and the API in between

The headNext.js storefrontPages, search, cart, CMS content

queries

In betweenStorefront API or GraphQLThe contract between the halves

reads + writes

The bodyCommerce engineCatalog, prices, checkout, orders

Should you go headless? The decision matrix#

Usually not as the first fix. A headless commerce development company that only sells headless always says yes; we'd rather show you when the platform's own fast option wins.

Go headless when:

• The catalog or content model outgrows the theme: spec-heavy ranges, buying guides, trade portals the platform's own B2B features can't hold. See headless for B2B catalogs.
• Several back ends sit behind one site.
• Your team can run two systems, each with its own deploys and upgrades.

Stay native when:

Platform facts below link to each vendor's docs. Operating cost is counted in work, not dollars.

Headless Shopify: Hydrogen or Next.js#

The honest answer, as of 2026-10-16: both. Shopify's docs say that starting with version 2026-10, "Hydrogen is a toolkit that you add to your framework, instead of a framework of its own," and it works with Next.js and React Router. Older Hydrogen builds on Remix or React Router face a migration.

That changes what a headless Shopify agency should ask: what does your theme stop you from doing? If the answer is "nothing, it's just slow," you need a Shopify theme build instead. If it's a content model, a second back end or a trade storefront the theme can't hold, we build Next.js on the Storefront API, add Hydrogen's helpers where they save work, and deploy to Vercel or another Next.js host. Oxygen, Shopify's own hosting, runs Worker builds such as Shopify's React Router template.

Checkout stays on Shopify either way: the cart's checkoutUrl "redirects customers through Shopify's web checkout," and the hand-off is ours to get right.

Headless BigCommerce with Catalyst#

Catalyst is BigCommerce's own Next.js storefront, and it ships more than a starter. BigCommerce lists faceted search on category and brand pages, full-text search, product pages, a cart, customer accounts and "an optimized one-page redirected checkout on our hosted SaaS environment to simplify PCI compliance." It runs on React Server Components and the GraphQL Storefront API, and visually it's "a 'blank sheet of paper' that you style to match your brand."

The buried part is ownership. Catalyst is code you keep: the repository's default canary branch "may not be stable," so we pin a stable release, and upgrades are 3-way merges that leave conflicts "for you to resolve." It deploys to Vercel or another Next.js host; BigCommerce's own Native Hosting was in closed beta as of 2026-10-16.

Headless Magento, PWA or Hyvä#

Magento and Adobe Commerce have four serious front-end routes. Three are headless, and one of those runs on Adobe Commerce only.

Hyvä is "the open source Magento 2 frontend, built with Tailwind CSS and Alpine.js instead of Knockout, RequireJS, and LESS," free under OSL3 and AFL3 since November 10, 2025. One system to run; full Adobe Commerce support is sold as Hyvä Enterprise. For speed alone, Hyvä is our default.

PWA Studio, Adobe's toolkit with the Venia reference store, works on Open Source and PaaS. For the Cloud Service, Adobe recommends Edge Delivery Services as the starting point. On cloud or on-premises, that storefront needs Adobe Commerce 2.4.8 or later: "Magento Open Source is not supported for this storefront path."

Next.js on GraphQL works on both editions. The cost hides in extensions: any module that only renders through Luma templates has no GraphQL schema or resolvers until someone writes them. That work is part of Magento development, including Hyvä.

Headless ecommerce development on Next.js#

As a headless ecommerce agency, we default to Next.js on the App Router, because it gives shoppers and crawlers the same thing: HTML from the server. In the App Router, "layouts and pages are Server Components" by default, which Next.js says lets you keep API tokens off the client and "reduce the amount of JavaScript sent to the browser."

What that means in a build:

• Catalog pages prerendered for anonymous shoppers, then refreshed with Incremental Static Regeneration, which updates "static content without rebuilding the entire site." Signed-in and trade prices render per request, outside the shared cache.
• Content from a headless CMS, with Draft Mode so editors see unpublished pages "without waiting for revalidation."
• Search and filters rendered on the server, with crawl rules for every filter URL.
• Cart in a small client component. Checkout handed to Shopify's or BigCommerce's hosted checkout, or built on Magento's GraphQL order flow.
• Structured data, canonicals and sitemaps generated from the same data as the page, so the markup matches what shoppers see.

This site runs on Next.js: App Router, Server Components, static HTML. View source and judge the work. Frameworks don't make stores fast; engineering does, and we've done it: server response times cut from seconds to milliseconds.

What goes wrong, and how we prevent it#

Headless builds rarely fail in the framework. They fail in the seams, in five places:

1. Rendering and SEO. Google renders JavaScript, but pages wait in a render queue that "can take longer" than a few seconds, and Google calls server-side or pre-rendering "still a great idea." For products it's blunter: "dynamically-generated markup can make Shopping crawls less frequent and less reliable." We put price, stock and structured data in the server HTML.
2. Editor preview. Marketers lose the theme editor when the theme goes. We wire a CMS with Next.js Draft Mode, or Makeswift on Catalyst, before launch.
3. Checkout ownership. Shopify, and BigCommerce's default redirected checkout, run the payment page, but the hand-off must still carry the cart, the customer session and analytics. On Magento, checkout is yours to build. When the payment provider supplies the card fields, card numbers stay off your servers, but the checkout page itself is in your PCI scope. We write down who owns each step before the build.
4. Integrations maintained twice. Theme app extensions "integrate with Online Store 2.0 themes," and a headless storefront has none, so reviews, upsells and pixels become code. Shopify adds that "scripts that you load separately need their own consent handling." We inventory every app: keep, rebuild or drop.
5. Two systems to run. Self-host Next.js on several instances and "the default file-system cache is per-instance," so one revalidation can leave other servers showing the old price. We add a shared cache handler, monitor both systems and name an owner for each.

Moving to headless with every URL accounted for#

A new front end touches every template; that's where rankings go missing. Google's site-move guide is plain: "It's important to map your old site's URLs to the URLs for the new site," with server-side permanent redirects kept "for as long as possible, generally at least 1 year." The checklist:

• URL parity: a headless storefront owns its routes, so keep every old URL you can and redirect the rest one to one, never in bulk to the home page. Keep the platform's own links, like Shopify's /products/:handle, resolving.
• Structured data and canonicals carried over template by template and checked in the rendered HTML.
• Core Web Vitals measured before and after on field data, against Google's thresholds: LCP within 2.5 seconds, INP at 200 milliseconds or less, CLS at 0.1 or less, at the 75th percentile.

Tens of thousands of redirects mapped for a zero-downtime replatform: that's the job. More on our migration method, URL by URL.

How the engagement runs#

Our headless commerce development services start as a project: we audit the theme, the apps and the integrations, and you get a written recommendation, headless or not and on which back end, before any build. After launch, a retainer keeps both systems patched, monitored and fast, API version upgrades included. Agencies can hire us white-label as their headless commerce agency: we build under the agency's name, invisible to its client. More on how an engagement runs.

We don't publish prices. What moves the number is in the FAQ below. Our guide to what an ecommerce website costs covers typical market rates, with sources.