How to Choose an Agency for Headless Commerce on Shopify or Magento (2026)

If you have already decided you want a custom, headless storefront on Shopify or Adobe Commerce (the platform most people still call Magento), the hard part is not finding agencies. It is telling the ones with real headless experience apart from the ones who will describe any custom website as "headless" because the word sounds impressive. This guide is deliberately narrow and platform-neutral: it does not rank companies, and it assumes you already know roughly why you want headless. If you are not sure headless is the right call for your business yet, our general guide to choosing an ecommerce development agency covers that earlier decision, including when a standard theme is the better choice. This guide picks up from there and goes deep on the architecture-specific questions that general guide does not cover.

What headless commerce actually means

Quick vocabulary, once, so the rest of this reads easily. Headless commerce means splitting the storefront (the pages, search, cart, and checkout screens a shopper sees) from the commerce engine (the backend system that manages products, orders, inventory, and payments). The two sides communicate through an API, a defined set of rules that lets one piece of software request data from another. In a normal store, the platform bundles both sides together in one theme system. In a headless store, you keep the platform's backend but replace the theme with a custom-built frontend, usually in a framework like Next.js, that pulls data through that API instead.

The appeal is control. A custom frontend can be faster, look exactly how you want without fighting a theme's built-in structure, and can serve more than one storefront (a different brand, region, or channel) off a single backend. The cost is real too: you are now maintaining two connected systems instead of one, and you need developers who understand both the frontend framework and the platform's specific API, not just general ecommerce experience.

Shopify's headless options: Hydrogen and the Storefront API

Shopify gives developers two related paths into headless, and any agency you talk to should be able to explain both clearly and tell you which one they actually use.

Hydrogen

Hydrogen is Shopify's own framework for building custom storefronts, built on React Router. Shopify's developer documentation describes it as providing "a set of components, functions, and utilities used for building custom storefronts" on React Router apps. It is opinionated, meaning Shopify-specific pieces (cart logic, checkout handoff, common storefront patterns) are already wired up for you, which can mean a faster start, at the cost of working inside Shopify's chosen structure rather than a fully open one.

The Storefront API

The Storefront API is the framework-agnostic path. It is a GraphQL API, a query language that lets the frontend ask for exactly the data fields it needs instead of receiving a fixed response shape, exposing product, cart, and checkout data. Per Shopify's own documentation, it lets a developer "build headless using the framework of your choice and Shopify's backend" , meaning Hydrogen is not required at all. Some agencies build fully custom Next.js storefronts directly against the Storefront API. Neither approach is inherently better; what matters is whether the agency in front of you has real, specific experience with the one they are proposing.

Adobe Commerce/Magento's headless options: GraphQL and PWA Studio

Magento was the platform's original name. Adobe acquired it in 2018; the paid, hosted version is now called Adobe Commerce, while Magento Open Source remains a free, self-hosted version of the core software. Most people, including most agencies, still say "Magento" for both out of habit, so it is worth clarifying which one a candidate actually means. The good news for headless buyers: the core technology for going headless is shared across both.

The GraphQL API

Adobe Commerce's own developer documentation states its GraphQL implementations "serve as the ideal foundation for building next-generation commerce experiences, including headless storefronts", letting a frontend request precise data instead of being locked into a fixed REST response. This GraphQL layer is part of the core Magento codebase, not an Adobe Commerce-only feature, so it is available on Magento Open Source too.

PWA Studio

PWA Studio is Adobe's toolkit for building a Progressive Web App (a website built to feel and perform like an app) storefront on top of that GraphQL layer. Adobe's documentation describes it as offering "the tools you need to develop a Progressive Web Application storefront for Adobe Commerce or Magento Open Source", bundling build tooling, a set of React hooks and logic, and a starter component library. It plays a similar role to Hydrogen on the Shopify side: a faster, more opinionated starting point, sitting on top of an API that also supports a fully custom build.

Why evaluating a headless agency is a different task

With a themed storefront, the platform has already made most of the hard technical decisions, so the agency's job is mostly design, configuration, and content. With headless, the agency is making architecture decisions from close to scratch: which parts of the API to call and when, how to cache data so pages stay fast without going stale, how product content and marketing content flow together, and how checkout still connects back to the platform's own secure payment flow. A generic question like "have you built ecommerce sites before" does not surface any of that. The rest of this guide is built around the sharper, architecture-specific questions that actually do.

Architecture depth: the first thing to check

This is the single best filter in this whole guide. Ask a candidate agency to walk you through a real example, not a summary: how did they decide what gets built ahead of time (pre-rendered) versus fetched live when a shopper loads the page? How does a product going out of stock show up correctly on a page that was built and cached earlier? How do search and filtering work when the storefront and the product data technically live in two different systems?

A team with real depth answers with specifics and trade-offs. A team without it describes only the outcome, something like "it's fast and modern," without ever naming the mechanism behind it.

Platform-specific experience, not general web skill

A Shopify Storefront API and an Adobe Commerce GraphQL API are built differently, expose different data shapes, and have different quirks around caching, checkout handoff, and rate limits. General React or Next.js skill, on its own, does not transfer that specific knowledge automatically. Ask directly how many headless builds an agency has shipped on your exact platform, not ecommerce in general, and ask them to name the specific API or SDK version they used.

This matters even more moving between platforms. Shopify's Hydrogen and Storefront API assume Shopify's own checkout and hosting patterns and are relatively opinionated. Adobe Commerce's GraphQL API and PWA Studio sit on top of a more open, self-hosted or cloud-managed platform with a typically more complex catalog structure, including multi-store views and B2B (business-to-business) pricing tiers. An agency strong in one is not automatically strong in the other. Ask for platform-specific proof for whichever one you are actually building on, not a portfolio that happens to include both.

How to test a headless case study

Ask what the storefront was actually built with: Hydrogen, a custom Next.js build against the Storefront API, PWA Studio, or a custom build against Adobe Commerce's GraphQL API. Ask what specific problem the headless approach solved that a theme could not have: a concrete page speed target, a design requirement the platform's theme system could not support, running multiple brands off one backend, or something else specific to that client's business.

Ask to see the live site if it still exists, and check it yourself on a phone. A vague answer, something like "we made it fast and modern," without naming the actual technical approach behind it, is a sign the case study is being described secondhand rather than by the people who actually built it. If the site no longer exists, that alone is not disqualifying, since storefronts do get rebuilt later by the client, but the team should still be able to describe the architecture in specific, technical language.

Ownership of code and data

You should own the code in every ecommerce engagement, but it matters more here because there is genuinely more custom code at stake. A themed Shopify or Adobe Commerce site can usually be handed to a new agency without much drama, since it still lives inside the platform's own structure. A custom headless frontend is a standalone codebase; if you do not own it outright, with full access to the repository, you can end up effectively locked into the agency that built it.

Get it in writing, before signing anything, that you own the complete frontend codebase, not just "the website." This is also where vendor lock-intends to appear on headless projects specifically: watch for a headless CMS or search tool chosen with proprietary, hard-to-migrate data formats, or technical documentation that exists only inside one developer's head instead of being handed over as a written deliverable.

A simple test: ask what would happen, concretely, if you wanted to move to a different agency six months after launch. A team confident in their own work will answer this directly. A team that gets evasive is telling you something about how the project is actually structured underneath the pitch.

Post-launch support for a custom codebase

On a themed store, most post-launch issues are theme or app bugs the platform's ecosystem has usually already seen. On a headless build, the agency is supporting custom code across more moving parts: the frontend itself, the API layer connecting it to the backend, and any headless CMS or search tool sitting in between. Ask specifically who is on call if the storefront goes down, how fast they respond, and what a defined support window after launch actually covers.

Also ask about the longer term. Shopify and Adobe Commerce both ship new API versions over time, and a headless frontend needs someone actively keeping its framework and integration up to date. Ask what an ongoing maintenance retainer covers for a headless build specifically; it is almost always a broader scope than maintaining a themed store, and an agency that treats it the same way is underestimating the job.

Cost transparency without a guessed number

You can absolutely get a fixed price on a headless project, but only after a real discovery phase, the structured research an agency does about your business, catalog, and integrations, happens first. Headless projects involve more architecture decisions than a themed build, so a price quoted before that research is a guess dressed up as a number.

Ask for a fixed-price milestone plan once discovery is complete, broken into stages you can check progress against: architecture and API integration, the frontend build itself, content and search setup if a headless CMS is involved, testing across devices, and launch. Just as important, ask what happens if scope changes partway through. Headless projects can uncover integration complexity once developers get into a platform's real data that nobody could have predicted from the outside. A written change-request process, agreed before work starts, protects both sides when that happens.

Red flags specific to headless projects

None of these alone is automatically disqualifying, since even a strong team might misspeak on a single question. But two or more of these together, on the same agency, is a real reason to keep looking, specifically for a headless project where the technical stakes are higher than a themed build.

One more general point worth remembering while you run this checklist: performance and checkout experience are not abstract concerns. Baymard Institute, an independent ecommerce UX research organization, has found in ongoing benchmarking of major ecommerce sites that roughly seven in ten shoppers abandon their cart, and that the large majority of sites they studied have a "mediocre" or worse checkout experience by their own usability criteria (Baymard Institute, checkout usability research). Headless does not fix that automatically. It only gives a competent team more room to get architecture and checkout flow right, which is exactly why the team you choose matters more than the label "headless" itself.

Where FactoryJet fits in this framework

This guide is meant to work the same way if you point it at us. Here is how we would actually run each step: we walk through real architecture decisions in detail, not just a finished result, because that is the fastest way for you to judge whether a team understands the mechanics of a headless build. We are upfront about which platform and API combination we have the deepest hands-on experience with rather than claiming equal strength everywhere. Every engagement ships with full client ownership of the frontend codebase on launch day. And a headless build gets a support plan sized for a custom codebase, not the lighter plan that fits a themed store. If you want a second opinion on your own architecture before committing to anyone, that conversation costs nothing.