Headless
commerce without limits

Headless commerce means splitting your commerce engine (products, pricing, orders, checkout) from the front-end your customers see. The two communicate via APIs. A single commerce engine can feed multiple front-ends: a website, a mobile app, a marketplace integration, a kiosk in a physical store. The benefit is flexibility and front-end performance. The cost is added complexity: two systems to maintain instead of one.

Headless makes sense when one of these is true: you need front-end performance beyond what classic Shopify or WooCommerce can deliver, you’re publishing to multiple channels and want a single source of truth for product data, your design needs go beyond what theme frameworks allow, or you’re planning to swap commerce engines later and want to decouple the front-end from that decision. For single-storefront stores that don’t have those pressures, classic Shopify or WooCommerce is faster to build, cheaper to maintain, and easier to find developers for. We’ll tell you which fits in discovery, not after launch.

The choice usually comes down to four questions. First, what does your front-end need to do that themes can’t handle? If “nothing material”, classic platforms win on cost and maintainability. Second, how many channels does the commerce data need to feed? One channel rarely justifies headless complexity. Five channels often does. Third, what’s your team’s operational maturity? Headless means more moving parts in deployment, monitoring, and incident response. Fourth, what’s your budget for ongoing development? Headless costs more to maintain because you’re maintaining two systems.

From our case work, most clients land on classic WooCommerce or Shopify because the four pressures above don’t all apply. Headless wins when at least two or three of them do. We’ve seen prospects pushed toward headless by an agency before understanding whether they actually need it, then end up with a stack that’s harder to maintain than the problem they were solving. We try not to do that.

Five main choices depending on the project. Next.js for most stores because the ecosystem is mature, server-side rendering is well-supported, and the Vercel deployment path is clean. Nuxt when the team prefers Vue and the same SSR and edge benefits matter. Remix when nested routing and progressive enhancement fit the project shape. SvelteKit for projects where front-end performance is the dominant requirement and the team can support a less common framework. Astro for content-heavy commerce sites where most pages are static or near-static.

We don’t push a fixed answer because that often becomes the wrong answer two years later. The deciding factors are your team’s existing JavaScript expertise (Next.js for React shops, Nuxt for Vue shops), your performance requirements, and which framework your hosting partner supports best. We document the choice in the architecture phase so the rationale is clear if you need to revisit it later.

For commerce engines: Shopify (via Hydrogen or the Storefront API) for stores that want the Shopify operational benefits with custom front-ends, WooCommerce (via REST and Store API) when WordPress sits next to the store and editorial flexibility matters, custom commerce engines built on Laravel or Node.js when off-the-shelf platforms can’t model the business logic. For specialised needs, we’ve also worked with Medusa as a self-hosted alternative, and we can integrate with enterprise platforms like commercetools or BigCommerce when those are already in place.

For headless CMS: Contentful for established commerce teams that value enterprise tooling, Sanity for projects where the content model is unusual and the editorial experience needs customising, Storyblok for projects where editors prefer a visual block-based interface, Strapi or Directus for self-hosted setups where data residency matters. Each has trade-offs around editor experience, pricing model, and integration capability. We pick based on your team and your content shape, not on which platform we’ve sold most recently.

SEO on headless commerce requires more deliberate setup than classic platforms because the front-end framework controls how pages are rendered for crawlers. Server-side rendering or static generation for product and category pages is non-negotiable. Structured data (Product schema, BreadcrumbList, Organization, FAQPage where relevant) gets generated from the commerce data automatically. Sitemaps generated dynamically from the catalogue so new products show up in search engines without manual updates. Time-to-first-byte and Core Web Vitals optimised from day one rather than as a post-launch project.

Common SEO failure modes we see on headless stores: client-side rendering on product pages that Google crawls slowly, structured data missing or implemented inconsistently across templates, sitemap not updated when products change, and migration losing URL equity because old URLs weren’t mapped to new ones. We handle these in the architecture and migration phases, not as last-minute fixes before launch.

Our hourly rate is €60-€65 across all roles (UX, frontend, backend, project management, QA), with our team split between Zwolle and Chandigarh. A focused Shopify Hydrogen build typically runs €20,000 to €50,000 for a single-storefront project, depending on catalogue complexity and integrations. WooCommerce headless builds sit in a similar range. Custom commerce engines with headless front-ends run €40,000 to €100,000+ depending on the business logic complexity. B2B and marketplace headless projects are usually at the higher end because of the catalogue and pricing complexity.

Timelines run from 10 weeks for a focused Shopify Hydrogen build to several months for custom commerce engines. The biggest scope variables are catalogue size and complexity, the number of integrations (ERP, PIM, marketing automation, fulfilment), multi-region requirements, and whether B2B or marketplace logic adds layers to the commerce engine. Schedule a discovery call to walk through what you actually need before any number gets put on paper.

After launch we offer ongoing support and maintenance through three packages: Care (4 hours per month, 24 working-hour response), Growth (8 hours per month, 8-hour response) and Partnership (16 hours per month, 4-hour response). Pricing starts at €240 per month, three-month minimum term, then monthly cancellable with one month notice.

Headless stores need more ongoing attention than classic platforms because there’s more surface area for things to break. Front-end framework updates, headless CMS version bumps, commerce engine API changes, dependency updates across both systems, performance tuning as the catalogue grows. For teams shipping continuously (new campaigns, seasonal launches, A/B tests, regional expansions), we run a dedicated-developer model where a fixed-capacity developer (40 to 160 hours per month) works as an extension of your team. Most of our long-running headless clients land on this model after the first three to six months.