Why we build e-commerce on headless Shopify, not a Shopify theme

"We build on Shopify" can describe two quite different things, and the difference matters more than it sounds like it should. Most small-business Shopify sites are themed: Shopify's own templating system renders every page a customer sees, and what you're customizing is a skin over a structure every other merchant on that theme also has. Ours are headless: Shopify runs the catalogue, the cart, the inventory and the checkout through its own APIs, and the storefront itself — every page a customer actually browses — is built on the same Next.js foundation as the rest of a WebStar site.

Why the distinction is worth having an opinion about

None of the reasons below are new arguments invented for e-commerce specifically. They're the same three things this site is built around everywhere else, applied to a store instead of a service page.

• A Shopify theme would be the first templated thing in a WebStar build. The whole point of building on our own foundation rather than WordPress or a page builder is that nothing is a reskinned version of something a thousand other businesses also run. A themed store quietly breaks that for the one part of the site most likely to be a customer's actual reason for visiting.
• One design system, not two. A themed store is usually a visibly different piece of software bolted onto the marketing site — a different rendering engine, different markup conventions, and often a jarring click-through moment between "your website" and "your Shopify store." Headless means a visitor never leaves the same design system going from a service page to a product page.
• The same structured-data discipline applies to product pages. Correct schema, server-rendered content, facts present in the initial HTML — the work that makes the rest of a site legible to answer engines depends on controlling markup and rendering directly. That's straightforward on pages we build. It's not fully controllable inside a general-purpose theme built to suit any merchant's customization needs.

What doesn't change: where the money actually touches

This is worth stating plainly, because it's the part most likely to get misread as a bigger, riskier build than it is. Headless means we build every page a customer browses. It does not mean we build checkout. That step still redirects to Shopify's own hosted, PCI-compliant checkout — exactly what a themed Shopify store does too. Our code never touches card data, headless or not. The customization is entirely in what happens before someone clicks "buy," not after.

We looked at going further — a fully proprietary cart and checkout, no Shopify at all — and specifically decided against it. The moment a website's own code handles card data directly, its builder takes on PCI-DSS compliance responsibility for every client running on it, which is a materially bigger risk than the browsing-and-cart experience is worth rebuilding from scratch. Redirecting to a payment processor's own secure checkout, rather than reinventing one, is a deliberate boundary, not a shortcut.

Why not headless WooCommerce, or something built from scratch?

Worth answering directly, because "headless" on its own doesn't say what's running behind it, and the choice of what's behind it matters as much as the decision to go headless at all.

• Headless WooCommerce is still WordPress. Decoupling the storefront doesn't remove the backend — WooCommerce is a WordPress plugin, running on WordPress core, typically alongside a handful of supporting plugins to expose a headless API at all. That's exactly the plugin-layer risk the rest of this site is built to avoid: 91% of disclosed WordPress vulnerabilities are found in plugins rather than in WordPress core, with 250+ new plugin vulnerabilities disclosed weekly and exploitation often starting within about five hours of disclosure, and WooCommerce specifically has had critical SQL-injection and remote-code-execution vulnerabilities disclosed in 2024–2025. Making the frontend custom doesn't change what has to be kept patched on the backend. This isn't a blanket refusal to touch WooCommerce — if a client already runs one, we'll tell them honestly whether keeping it is the right call — it's a reason not to choose it for something new.
• A fully custom cart and checkout, with no commerce platform underneath at all, is the proprietary-platform option already ruled out above — same PCI-DSS reasoning, just restated: the moment a business's own code handles card data, it's carrying compliance exposure a proven platform is built to absorb instead.
• Stripe-centric builds run into a specific, practical wall for this market: Stripe doesn't support Jamaica as a merchant country. A lot of "build your own commerce" tooling defaults to Stripe underneath, which makes it a non-starter here regardless of how good the frontend is.

That leaves other proven, hosted commerce platforms — BigCommerce is the obvious comparison — as a legitimate question we don't have a fully researched answer to yet. Shopify's specific fit for this market was evaluated in depth: its Caribbean-relevant payment gateway options (WiPay, Fygaro) and its Partner ecosystem economics were both looked at closely. Alternatives weren't independently evaluated to the same depth, so this is Shopify because it was the one actually vetted for a Jamaican small business, not a claim that it beats every alternative in the abstract.

The honest tradeoff

A headless build is more engineering work up front than pointing a Shopify theme at a domain, and it's priced that way — this is why it's an add-on stacked on a full site build rather than something bundled in for free. If a business genuinely doesn't need that level of customization — a straightforward catalogue, no strong opinions about matching a marketing site's design system exactly — a lower-cost, ready-made storefront is a better fit than paying for a custom build to solve a problem that isn't there. That's the honest answer, not the upsell.

Shopify Payments is not available in Jamaica, so a third-party gateway (WiPay or Fygaro) is involved either way, headless or themed, and carries its own fees. This is disclosed in every e-commerce proposal, not left for a client to discover on a first invoice.