Custom Ecommerce vs Shopify vs Headless in 2026: A Guide

For most European online stores, SaaS (Shopify, BigCommerce) is the right default in 2026: it launches in weeks, its total cost is predictable, and it keeps payments and compliance mostly off your plate. Custom ecommerce development pays off only when the business itself does not fit a template — complex pricing, product configurators, B2B contract logic, regulated products or unusual fulfilment. Headless sits between the two and is worth it when the storefront is the differentiator and you have a front-end team to own it.

The rest of this guide gives you the comparison table, the honest trade-offs of going headless, the migration and EU compliance checklist, and a decision list by revenue band.

The four ways to build an online store

SaaS. Shopify, BigCommerce and Wix host everything: storefront, catalog, checkout, payments, upgrades. You pay a subscription plus a percentage per transaction (Shopify charges extra when you do not use Shopify Payments, which matters in countries where it is unavailable). Customisation happens through themes, apps and, on Shopify, Functions and checkout extensibility. Shopify Plus and BigCommerce Enterprise add B2B features, higher API limits and multi-store.

Open-source, self-hosted. WooCommerce (WordPress), Magento Open Source / Adobe Commerce and PrestaShop give you the source code and the hosting bill. WooCommerce is cheap to start and fine for small catalogs, but scales through plugins of uneven quality. Adobe Commerce is the most complete monolith for B2B and multi-store, and also the most expensive to run: it needs experienced developers, tuned infrastructure and a serious upgrade discipline. PrestaShop remains popular in France, Spain and Italy for mid-size catalogs.

Headless / composable. A commerce engine exposed via API — Medusa (Node, open-source), Saleor (Python/GraphQL), commercetools (SaaS, enterprise), or Shopify with its Storefront API and Hydrogen framework — plus a storefront you build with Next.js, Remix/Hydrogen, Nuxt or a mobile app. Content usually comes from a separate CMS, search from Algolia or Meilisearch, and the pieces are wired together by your team.

Fully custom. Your own domain model for products, pricing, cart, orders and fulfilment, typically built on a framework such as Laravel, NestJS, Django or Spring, with a PSP for payments. Nothing comes for free; everything is exactly what the business needs.

Comparison table: SaaS vs open-source vs headless vs custom

Criterion	SaaS (Shopify, BigCommerce, Wix)	Open-source self-hosted (WooCommerce, Adobe Commerce, PrestaShop)	Headless / composable (Medusa, Saleor, commercetools, Hydrogen)	Fully custom
Total cost model	Subscription + % per transaction + apps; low upfront, grows with revenue	Hosting + developers + extensions; Adobe Commerce adds a licence tied to GMV	Engine (free or licence) + storefront build + hosting + integration work	Build cost upfront, then maintenance, hosting, on-call
Customisation ceiling	Theme and app boundaries; checkout limits eased by Functions on Plus	High in code, but core upgrades fight heavy customisation	High on the storefront; engine extensible via plugins or services	Unlimited
Performance and SEO control	Good defaults, limited control over rendering, URLs partly fixed (/products/, /collections/)	Full control, but PHP monoliths need caching to perform	Full control of rendering, URLs, Core Web Vitals	Full control
B2B features	Basic on standard plans; solid on Plus / B2B Edition	Adobe Commerce strong; WooCommerce via plugins	commercetools and Saleor strong; Medusa growing	Whatever you model
Integrations (ERP, PIM, WMS)	Large app ecosystems; deep ERP sync often via middleware	Mature connectors for SAP, Dynamics, Odoo	API-first, you write or buy connectors	You write everything
Ownership and lock-in	Data exportable, logic and apps are not	You own code and data	You own storefront and data; engine may be SaaS	Total ownership
Ops burden	Near zero	High: patching, scaling, PCI scope	Medium to high: two or more deployables	High
Time to launch	Days to weeks	Weeks to months	Months	Months to a year

The line that decides most projects is customisation ceiling versus ops burden. Every step to the right buys control and costs an operations capability you must staff.

When custom ecommerce development is justified

Custom is justified when the store's core logic cannot be expressed in a platform's data model without constant workarounds. The recurring cases:

• Complex pricing. Volume tiers by customer group, contract prices negotiated per account, currency- and country-specific price books, dynamic surcharges (metals, freight, energy). SaaS handles a few of these; combined, they push you into apps that do not talk to each other.
• Configurators and made-to-order products. Furniture, windows, industrial parts, custom apparel. A configurator needs rule engines, price calculation on the fly and often a 3D preview — see our guide to WebGL and Three.js 3D web applications. The cart line item is a specification, not a SKU.
• B2B commerce. Company accounts with buyers and approvers, purchase orders, net-30 terms, quotes that become orders, punchout catalogs, stock per warehouse from the ERP. A multi-vendor model raises the bar further; our B2B marketplace development guide covers that case in depth.
• Regulated products. Pharmaceuticals, medical devices, alcohol, tobacco, chemicals, firearms accessories. Age or licence verification, per-country sale restrictions, batch and serial tracking, mandatory documentation with the order.
• Unusual fulfilment. Subscriptions with mixed cadences, rentals, bookings tied to inventory, split shipments from multiple suppliers, pick-up in hundreds of stores with local stock, or products that ship from a partner's warehouse on your paper.

If none of these apply, the customisation you want is probably cosmetic, and a theme plus a few apps will get you there. A useful test: write down the five workflows that make your business different, then try to model them in a trial store. If you need more than two apps that must agree with each other on a single order, you are heading toward custom or headless.

Headless commerce: the trade-offs nobody puts in the pitch

Headless is often sold as "best of both worlds". It can be, with these costs stated clearly:

You now run a storefront application. A Next.js or Hydrogen front end is a product with its own deployments, monitoring, error budgets and dependency upgrades. Cart, checkout redirects, search, promotions display and 404 handling become your bugs. Shopify Hydrogen on Oxygen hosting reduces the hosting part; it does not reduce the code you own.

Two systems, one order. Pricing shown by the storefront must match what the engine charges. Stock must be fresh enough at checkout. Content in the CMS must not reference products that no longer exist. Each seam needs a contract, a cache policy and tests.

Apps stop working. Most of the Shopify app ecosystem injects into Liquid themes. With a headless storefront you reimplement reviews, upsells, size guides and consent banners, or pick apps that expose an API.

Costs shift, not disappear. You save on theme limits and gain on performance and SEO control, but you pay for a front-end team and for integration work that a monolith handled internally. commercetools is priced for enterprises; Medusa and Saleor are free to use but not free to run.

Where headless wins clearly: multiple storefronts (web, app, kiosks, marketplaces) on one engine, storefronts with heavy editorial content, sites where Core Web Vitals drive revenue, and companies whose competitive edge is the buying experience itself.

A minimal example of the seam you take on, using Medusa's store API from a server-side storefront:

// Storefront (Next.js server component) fetching a product from Medusa
const res = await fetch(`${process.env.MEDUSA_URL}/store/products/${handle}`, {
  headers: { "x-publishable-api-key": process.env.MEDUSA_PUBLISHABLE_KEY! },
  next: { revalidate: 60 }, // stale price for up to 60s — accept or shorten
});
const { product } = await res.json();

That revalidate value is a business decision about how stale a price may be, and it is now yours.

Migrating platforms without losing revenue

Migrations fail on three fronts: URLs, SEO signals and data.

URLs. Export every indexed URL from Search Console and your server logs. Map each one to its new address and ship a 301 for every change. Platform paths differ: Shopify uses /products/slug and /collections/slug, WooCommerce /product/slug, custom builds whatever you decide. Keep the old structure when you can; a redirect is a cost you pay on every crawl.

# Cloudflare / Netlify style redirects file
/collections/office-chairs   /en/category/office-chairs/   301
/products/ergo-chair-x1      /en/p/ergo-chair-x1/          301

SEO signals. Preserve titles, meta descriptions, canonical tags, hreflang between language versions, product structured data (Product, Offer, AggregateRating) and internal links. Regenerate the sitemap on launch day and submit it. Expect a few weeks of ranking noise; a drop that persists longer usually means dropped URLs or slower pages.

Data. Products and variants map cleanly. Customers, order history, gift cards, store credit and stored payment methods do not. Card tokens live at the PSP; if you keep the same PSP (Stripe, Adyen, Mollie) you can usually keep tokens, otherwise customers re-enter cards. Subscriptions are the hardest migration and deserve their own dry run. Treat the data move like any production data migration: rehearse it on a copy, measure it, and keep a rollback path.

Cut over in one step, after a full rehearsal on a staging copy with real data. Page-by-page migrations leave you running two platforms and split the SEO signals between them.

Payments and compliance in Europe

PSD2 and SCA. Card payments in the EEA require strong customer authentication, delivered through 3-D Secure 2. Your PSP handles the challenge and the exemptions (low value, low risk, trusted beneficiaries, merchant-initiated transactions for subscriptions). Your checkout must survive the redirect or the in-page challenge without losing cart state, and must handle the asynchronous outcome via webhooks rather than trusting the browser's return.

PCI DSS. Use hosted fields, a redirect or a PSP-hosted checkout so card data never touches your servers. That keeps you in the lightest self-assessment tier. A custom platform that renders its own card form with a PSP's JavaScript is still fine; one that posts card numbers to its backend is not.

VAT and the One-Stop Shop. Since the EU e-commerce VAT package, cross-border B2C sales above the EU-wide threshold are taxed at the buyer's country rate, reported through OSS in one return. Your platform must charge the right rate per destination and product category, store evidence of the customer's location, and issue reports by country. Shopify and BigCommerce have this built in; open-source and custom builds typically integrate a tax service or maintain rate tables with a defined owner. For B2B, validate VAT IDs through VIES and apply reverse charge.

GDPR. Consent for marketing and non-essential cookies, a lawful basis for order processing, retention periods for orders versus marketing data, data processing agreements with every processor (PSP, email, analytics, hosting), and the ability to export or erase a customer. SaaS gives you tooling; the obligations stay with you as controller. Our GDPR guide for European companies covers the engineering side, and the payment system development guide goes deeper on the PSP integration.

Accessibility. The European Accessibility Act applies to ecommerce services since 2025. Custom and headless storefronts must meet it in their own code; SaaS themes get you part of the way and no further.

Decision checklist by revenue band and complexity

Use annual online revenue as the first filter and complexity as the second.

Under about €1M online revenue

• Shopify or BigCommerce. WooCommerce if the site is already WordPress-heavy and the catalog is small.
• Do not build. Every euro should go to product, traffic and conversion.
• Exception: a regulated product or a configurator that no app supports; then a small custom module behind a SaaS storefront, not a full platform.

€1M–€10M

• Stay on SaaS (consider Shopify Plus or BigCommerce Enterprise) unless two or more of the "custom is justified" cases apply.
• Headless makes sense if you have an in-house front-end team and the storefront experience is the competitive edge.
• Adobe Commerce or a headless engine if B2B contract pricing and ERP-driven stock are central.

€10M–€50M

• Any option is affordable; the question is where you want to own risk.
• Headless on Shopify Plus, commercetools or Saleor when you need multiple storefronts or markets.
• Custom when pricing, fulfilment or compliance logic is the business, and you already run software in production.

Above €50M or marketplace models

• Composable or custom is the norm; SaaS platforms hit API limits, checkout constraints and transaction fee ceilings.
• Budget for a platform team, not a project. Read our post on what custom software costs in Europe before committing.

At any band, ask these questions:

1. Which five workflows make our business different, and can a trial store model them?
2. Who fixes the checkout at 3 a.m. on Black Friday?
3. What is the exit cost from each option in three years?
4. Do we sell to businesses with contracts, or to consumers with cards?
5. How many storefronts, countries and currencies will we run in two years?
6. Does the ERP own stock and prices, or does the store?

Recommendation

Default to SaaS and prove the need for anything else. Move to headless only when the storefront itself is where you compete and you can staff its operation. Choose fully custom when the checklist above returns at least two structural reasons — complex pricing, configurators, B2B contract logic, regulated products or unusual fulfilment — and the revenue justifies a permanent engineering team. At Arvucore we usually recommend a headless engine over a from-scratch build even in the custom case: model your pricing and fulfilment as your own services, and let Medusa, Saleor or commercetools handle carts, orders and the plumbing you would otherwise rewrite.