Headless commerce — when the storefront needs to do what the theme can't.
1Dot Digital builds headless commerce storefronts: a custom Next.js front end over your platform's API, with the platform still running catalog, cart and checkout. We build headless only when there's a reason, and we tell you when there isn't.
- Shopify Storefront API
- Hydrogen
- BigCommerce
- GraphQL Storefront
- WooCommerce
- Store API
- By design, not by plugin
- Core Web Vitals
- Storefront front end
- Commerce integration
- Content layer and previews
- Search and merchandising
- Performance and operations
Architecture
What headless commerce means
Headless commerce separates the storefront from the commerce platform behind it. The platform (Shopify, BigCommerce or WooCommerce) still manages products, carts, customers and orders. A separate front end, usually built with Next.js and React, requests that data through an API and renders every page. Composable commerce goes one step further and swaps individual back-end pieces, such as search, content, product information or order management, for separate best-fit services. Both add flexibility and add systems to run, which is why this page starts with whether you need it.
Honest framing
Headless is a trade, not an upgrade
It buys you freedom on the front end and costs you a codebase to own. These are the signs it pays off — and the signs it will not.
Headless is right when
Build it- The same catalog has to feed several front ends: web, app, in-store kiosk, marketplace.
- Content and commerce have to live together — editorial-heavy brands, publishers that sell.
- The design or interaction can't be expressed in a theme: configurators, 3D, complex B2B ordering flows.
- Performance is a revenue lever and the theme is still the bottleneck after images and apps are cleaned up.
- You have an engineering team, or will retain one, to own the front end after launch.
Stay on a theme when
Save the money- A well-built theme would already do the job — most stores are here.
- Nobody on your side can own a codebase, and you don't want to rent one indefinitely.
- The real need is checkout customisation: on Shopify, Checkout Extensibility covers it without going headless.
- The budget would move revenue further as conversion work and content.
- You need to launch in weeks, not months.
What we build
Everything between your platform and the shopper
A headless build is six systems, not one. We scope each of them explicitly, so nothing is assumed to come "for free" from the platform.
Storefront front end
Next.js App Router with React Server Components, streaming and incremental regeneration, so pages are fast without being stale.
Commerce integration
Storefront API or GraphQL for products, collections, cart and customer accounts, a clean hand-off to the platform checkout, and ERP, PIM and OMS connections where catalog and order data need them.
Shopify development →Content layer
Headless CMS or WordPress over GraphQL, with live previews and localization, so marketing edits pages without a deploy.
WooCommerce development →Search & merchandising
Algolia, Typesense or the platform's own search, with facets, synonyms and merchandising rules your team controls.
Performance architecture
Edge caching, an image pipeline, a script budget and Core Web Vitals monitoring from field data, set before the first page is built.
Speed optimization →Operations
CI/CD, preview and production environments, error tracking, runbooks and a documented handover to whoever runs it next.
Platform options
Which headless route fits your platform
| Route | Best for | Checkout | Hosting | Trade-offs |
|---|---|---|---|---|
| Shopify Hydrogen + Oxygen | Shopify brands that want Shopify's own headless framework | Shopify checkout; customise it with Checkout Extensibility on Plus | Oxygen, Shopify's hosting for Hydrogen | Tied to Shopify and its framework; not Next.js, so the wider Next.js ecosystem does not apply |
| Shopify Storefront API on Next.js | Content-heavy Shopify brands, or teams standardising on Next.js | Hand-off to Shopify checkout from the cart | Vercel or any Node host | Cart, customer accounts and analytics are yours to build; theme app blocks do not carry over |
| BigCommerce GraphQL Storefront (Catalyst or custom Next.js) | Large catalogs, B2B and multi-storefront set-ups | BigCommerce's optimized one-page checkout | Vercel (Catalyst, BigCommerce's Next.js storefront) or your own | B2B features need wiring into the front end; some checkout changes stay inside BigCommerce |
| WooCommerce Store API | Content-led stores already on WordPress | WooCommerce checkout, or one built on the Store API | Next.js host plus the WordPress host | Cart sessions, nonces and customer auth need care; plugins that render PHP templates do nothing headless |
| commercetools / Medusa (custom) | Complex catalogs, many regions, unusual business rules | Built by you on a payment provider | Your cloud, or the vendor's managed hosting | The most control and the most to build, test and run |
Process
How a headless engagement runs
Fit check
A week deciding headless or theme. You get a written recommendation either way.
Architecture
Data flow, cache strategy, checkout hand-off and the content model, agreed in writing.
Build
Storefront, integrations, content models and a design system, released to previews as we go.
Launch
Performance budget met, redirects in place, monitoring and alerts live before cutover.
Operate
A retained team for upgrades, fixes and monthly Core Web Vitals reports.
What it costs to run
Headless adds operating cost. We quote it before you commit.
A theme lives inside your platform subscription. A headless storefront is a second system with its own bills and its own maintenance. That is fine when the front end earns it — we put the running cost next to the build cost so you can decide with both.
Hosting
Vercel or Oxygen for the front end, billed on traffic and usage, on top of your platform plan.
Monitoring
Uptime, error tracking and Core Web Vitals from real visitors — tools a theme mostly gets for free.
Framework upgrades
Next.js, React and API versions move several times a year; someone has to keep up.
Developer time
New features are code changes, not app installs. Budget for a developer, ours or yours.