Headless or traditional e-commerce: choosing the architecture

OutsourcingVN is operated by Netbase JSC, which builds commerce projects on both the coupled and the headless route and earns its revenue from the engineering either one needs, so this comparison is not neutral by default; it is written to hold up anyway. For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred, so a headless build that reuses a Netbase module still leaves you holding everything built around it.

Contents

• What exactly is being compared?
• How do the two architectures compare?
• How do you decide?
• Worked scenario: a subscription retailer adding a mobile app
• What do Netbase records show about each route?
• Which questions should you ask a vendor or supplier?
• What goes wrong with each route?
• How this guide is sourced and where it stops
• Common questions
• Choose the architecture before the platform

What exactly is being compared?

A traditional, coupled commerce platform renders its own storefront: Magento, WooCommerce or another cart owns the catalogue, checkout, theme and every page a shopper sees, from one codebase and one release. A headless, API-first architecture splits that in two: the commerce engine still owns catalogue, pricing and checkout, but a separate front end, commonly built in Next.js, calls its API and renders every page itself, on its own schedule.

Magento and WooCommerce can run either way: coupled out of the box with their own themes, or as the commerce engine behind a headless front end. Choosing between Magento and WooCommerce themselves, rather than this architecture, is the Magento vs WooCommerce guide's question; this page assumes a platform is already chosen, or nearly so, and asks only whether to couple it to its own storefront or decouple the two.

How do the two architectures compare?

Score your own project against six criteria, and treat the middle two columns as real options, not a forced choice between two extremes.

A coupled storefront keeps every theme setting inside the platform's own admin screens, limited to the options the platform exposes. An API layer added on top calls the platform's API for the parts that need it, without a full rebuild. The platform's own SDK gives a managed front end that still has to be customised, with the front end's customisations and the data behind them hosted outside the commerce platform itself even though the platform supplies the SDK. A fully independent front end holds its own code, and that code and its data are fully yours to run, on your own release cycle.

Worked scenario: a subscription retailer adding a mobile app

A hypothetical subscription retailer runs a single coupled storefront today and wants to add a companion mobile app within the year, without rebuilding checkout. Mobile commerce apps scopes the app itself; this guide decides what the storefront underneath it should look like first.

• Milestone one keeps the storefront coupled and adds a documented API surface for the parts the app will need: catalogue, cart and order status.
• Milestone two builds the app against that API, independent of the storefront's own release train.
• Milestone three revisits the storefront itself only if a second channel or a redesign makes full decoupling worth its own front-end team.

The retailer never goes fully headless; it adds just enough API surface for the one new channel it actually needs, and keeps the reversal trigger written down.

What do Netbase records show about each route?

On the headless side, the clearest delivered example is the reward-shop platform for a Dubai-based loyalty and rewards company that is not named, built under an NDA: a Next.js storefront calls a Magento 2 Open Source engine that still owns the hybrid points-and-cash checkout and multi-vendor routing, delivered across four phases over 3.5 to 4.5 months. See the loyalty reward shop record.

A third pattern sidesteps the packaged choice entirely: building a custom commerce foundation instead of coupling to, or decoupling from, Magento or WooCommerce. Deyar Printing & Advertising's bilingual web-to-print platform runs its designer, pricing engine and print-ready PDF pipeline on a Laravel headless-commerce foundation built specifically for it; see the bilingual platform record.

On the coupled side, Netztech's Magento 1 to Magento 2 migration, 35 working days across 11 extensions, shows the operating cost of staying coupled to one platform's own release cycle: the whole extension list has to move with the core, because nothing runs behind a separate API. Reusing Netbase's own productised modules on any of these routes can cut development time by up to 60%, an upper bound tied to module reuse rather than a typical result on any one project.

Which questions should you ask a vendor or supplier?

• For either route: who owns the API contract once a front end is split out, and how is a breaking change on either side communicated?
• For a headless build: which parts of checkout, pricing and promotions stay in the commerce engine, and which move to the front end?
• For a coupled build: if a second channel arrives later, is an API layer realistic to add, or does it mean a rebuild?
• For either route: how many extensions or plugins does the current store depend on, and which would need to expose themselves through an API?
• For a build supplier: who owns the code? For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred.

What goes wrong with each route?

• Going headless for a channel that never arrives. Two deployments and two on-call rotations, paid for before the second channel exists.
• Treating the API as an afterthought. A contract written after the front-end team has already started tends to be rewritten once, expensively.
• Staying coupled past the point several channels are live. Every new channel gets bolted onto a storefront that was never built to serve more than one.
• Comparing routes on first-release cost only. A coupled build looks cheaper until the second channel or the first independent release is actually needed.
• Assuming an extension carries over unchanged. The Netztech migration above shows why: each one is re-proven, not assumed.

How this guide is sourced and where it stops

The architecture definitions and the criteria are editorial guidance, not a vendor claim. Netbase's evidence covers a delivered headless reward-shop platform, a bilingual platform built on a custom headless-commerce foundation, and a Magento migration that stayed on one coupled platform. No client, figure or partner is named beyond the linked records, and the durations above are the project's own, not a general benchmark.

Choose the architecture before the platform

Bring your channel list, your front-end skills and your extension count to a brief. Custom product engineering scopes a new build on either route, and legacy application modernization is usually the cheaper path when an existing coupled store only needs an API layer added rather than a full rebuild.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your channel list and extension count, and a person will reply with the architecture that fits.

Related services and solutions