Headless ecommerce separates the part of your store that shoppers see from the part that runs the business. Built for the right store, it can give you a faster, fully custom storefront. Built for the wrong store, it gives you a second system to pay for and maintain. This guide explains what headless means, when it earns its cost, and what a custom ecommerce development project on Next.js covers.
What headless means in plain English
Headless means the storefront and the commerce engine are two separate pieces that talk to each other through an API. The engine, such as Shopify or WooCommerce, keeps the catalog, cart, orders and payments. A separate application you control, in this case one built on Next.js, builds the pages shoppers browse.
In a standard setup the platform does both jobs, and a theme controls how the pages look. Shopify's Storefront API is built for the headless approach: it is a GraphQL API that lets developers build a storefront on any platform, covering products and collections, the cart and checkout. WooCommerce has a counterpart in its Store API, which provides public REST endpoints for cart, checkout and product functionality. On Shopify, checkout itself does not move: the cart hands shoppers a link to Shopify's own web checkout.
When headless is worth the cost
Headless is worth the cost when the storefront itself is part of what you sell, you need something a theme cannot deliver, and you have developers to look after the result. If none of that is true, a standard theme is the better call. Shopify's own guidance agrees: it describes headless as a fit for brands that want experiences their current platform cannot deliver and have the development resources to support it, and it warns that the work "isn't nearly as easy as it's often advertised." The extra cost tends to be justified in four situations:
- You need content and commerce in one site, such as guides, editorial pages and product pages that share one design and one content system.
- Your layout or the path from product page to cart cannot be built inside a theme, even a deeply customized one.
- You serve more than one front end, such as a website and an app, from one catalog.
- You have, or will pay for, ongoing development, because custom code needs an owner after launch.
When a standard Shopify or WooCommerce theme is the better call
A standard theme is the better call when you sell a normal catalog through a normal buying flow and nobody on your team writes code. Shopify handles hosting, payments and security, and a theme can be customized deeply. That covers most stores. WooCommerce remains reasonable for a store already on WordPress with a small catalog.
A theme gives you page templates, cart behavior, search and filtering out of the box. Going headless means a developer builds or connects each of those, and then maintains them. Shopify also notes that a business doing well on a traditional architecture may not be worth the financial and time cost of switching. The test is simple: write down what your current theme cannot do. If the list is empty, stay where you are.
What custom headless development covers
A custom headless build covers the storefront application, the connection to the commerce platform, and every piece a theme used to supply. For Shopify stores, GrossiWeb's ecommerce service includes headless commerce on Next.js with the Storefront API, alongside standard Shopify builds and migrations. GrossiWeb quotes ecommerce builds after a scoping call and does not publish a starting price, because catalog size, integrations and custom checkout logic move the figure more than page count does.
- The storefront: product, collection, search and cart pages built in Next.js and TypeScript.
- The platform connection: pulling products, prices and cart data from the Shopify Storefront API.
- A content layer: a headless CMS, so editorial pages and product pages live in one site, though staff who edit pages today will need to learn it.
- Integrations: shipping, accounting and marketing tools connected to the store.
- Search plumbing: supporting Shopify's standard product URL format, or a server-side redirect to it, which Shopify's Hydrogen guidance recommends, plus page titles, descriptions and structured data.
- Hosting and upkeep: the Next.js storefront needs its own hosting, billed at cost, on top of the platform subscription and app fees, which the store owner pays directly. GrossiWeb's maintenance and support plan starts at $250 a month for updates, monitoring and routine changes; new features are quoted separately.
Shopify offers its own framework, Hydrogen, built on React Router and hosted on its Oxygen platform, and says you can instead use any framework, tooling or hosting. Next.js suits stores that want one codebase for the store, the content and the rest of the site, as described in our post on Next.js versus WordPress.
What headless changes for speed
Headless can make a storefront faster because you control how each page is built and cached, but it does not make a slow store fast by itself. Next.js can prerender pages ahead of time and cache the results, so future requests are served without repeating the work, and its documentation says a prerendered page shell can be served directly from a CDN. Caching also means a price or stock change must clear the cached page, so ask how the build refreshes product pages when the catalog changes.
Speed matters to search because Google measures loading, interactivity and visual stability through Core Web Vitals, and says these align with what its core ranking systems seek to reward. They are one signal among many, not a switch. Heavy third-party scripts, oversized images and slow data calls will hurt a headless store as much as a themed one, which is why our post on why a slow site is usually not a hosting problem applies here too.
What headless changes for SEO
Headless does not improve SEO on its own. It moves responsibility for the technical details from the platform to your developers. Google can render JavaScript pages, but its guidance still calls server-side or pre-rendering a great idea because it makes a site faster for users and crawlers, and not all bots can run JavaScript.
Next.js renders pages on the server by default, and in its newer Cache Components mode its documentation says crawlers are sent the fully rendered page. It also warns that if part of a page depends on data that only exists at build time, a page that loads for a person can fail to render for a crawler.
Moving a live store to a new front end is also a migration. Every old URL needs a mapped destination, and titles, descriptions and structured data must carry over. SEO is the separate work of deciding what the store should rank for and measuring whether it does.
What to do this week
Spend a week on the decision before you spend anything on the build, and finish with a written answer to one question: what does a custom storefront do for this store that a theme cannot? Each step below is a check, not a commitment.
- List what your current theme cannot do, and what each gap costs you in orders or in staff time. If the list is empty or the costs are small, stay on the theme.
- Measure your best-selling product pages on a phone and write down what slows them before blaming the platform.
- List everything your theme and apps do today that custom code would have to replace, including search, filtering, reviews and email capture.
- Decide who owns the code after launch. If the answer is nobody, headless is the wrong choice for now.
- If the case still holds, ask for a scoped quote that separates the build, the platform fees and the monthly upkeep.