Most of the time the answer is somewhere between 40 and 400. And for that range, our honest recommendation — the one that costs us a smaller, less impressive-sounding project — is usually WooCommerce. Not because headless is bad architecture. Because for a catalog that size, the math rarely works out in the client’s favor.

What “headless” actually buys you

Headless commerce means separating the storefront — what shoppers see — from the commerce engine that handles inventory, cart, checkout, and orders, and connecting the two over an API. Instead of a WordPress theme rendering pages server-side, you get a frontend, usually Next.js, sometimes Remix or a native app, pulling product and cart data from a commerce backend like Shopify’s Storefront API, commercetools, Medusa, Saleor, or BigCommerce’s headless API. Shopify’s own flavor of this is Hydrogen, deployed on Oxygen.

The pitch is real: full control over markup and performance, no fighting a theme’s PHP templates, and the ability to build genuinely custom interactions — 3D configurators, native-app-and-web parity, sub-second page transitions — that are painful to bolt onto a traditional CMS-rendered storefront. None of that is marketing fluff. It’s just not what most 200-SKU DTC brands need in their first year.

The three costs that don’t make it into the pitch deck

You’re building two products, not one

A WooCommerce store is one codebase: WordPress, WooCommerce, a theme, and a handful of plugins, all rendering server-side. A headless store is at minimum two codebases — the commerce backend and the frontend application — that have to stay in sync as APIs version and business logic changes. Every feature, a new shipping rule, a bundle discount, a subscription option, has to be built or configured on the backend and then implemented again in the frontend’s UI. That’s not a one-time cost. It’s a permanent tax on every future feature request, paid by whichever team maintains the frontend.

Time-to-launch measures in quarters, not weeks

A competent WooCommerce build — theme customization, product import, a payment gateway like Stripe or a regional processor, shipping rules, tax configuration — typically ships in six to ten weeks for a catalog under 500 SKUs, and most of that time goes into design and content, not engineering. A comparable headless build means building product listing and detail pages, cart state management, a checkout flow, account pages, search, and filtering from scratch in the frontend framework, then testing all of it against the API. We’ve scoped headless rebuilds of stores that size at four to six months. That’s not a knock on headless engineering — it’s just more surface area, built new instead of inherited from a decade of plugin development.

The plugin ecosystem you walk away from

This is the cost clients underestimate the most. WooCommerce’s plugin ecosystem exists because thousands of developers have already solved problems you’re about to hit: subscriptions, points and rewards, product bundles, tax rules via Avalara or TaxJar, abandoned cart recovery, wholesale pricing tiers, deposits. Most of these plugins work by hooking into WordPress and WooCommerce’s own PHP rendering and checkout pipeline. Go headless and that hook either doesn’t fire, because nothing is rendering server-side the way the plugin expects, or its logic has to be rebuilt by hand in your frontend and, critically, revalidated server-side so a shopper can’t manipulate cart totals in the browser.

Here’s a small, real example. A common WooCommerce customization is a server-side surcharge, say a regional handling fee, added with a single hook:

add_action( 'woocommerce_cart_calculate_fees', function( $cart ) {
    if ( 'AU' !== WC()->customer->get_billing_country() ) {
        return;
    }
    $cart->add_fee( 'Remote Region Handling', 12.00, true );
} );

Six lines, ships in an afternoon, and it’s enforced server-side automatically because WooCommerce owns the checkout. A headless build doesn’t get this for free. You either replicate that logic against your commerce API’s fee or line-item hooks, if it exposes any, and re-render the result in the frontend cart UI, or you write custom middleware to intercept checkout and validate it yourself, because you can no longer trust anything the client sent. Multiply that by every “small” customization a growing store accumulates over a few years, and the maintenance gap compounds fast.

Where headless earns its cost

None of this means headless is wrong — it means it’s frequently sold to the wrong catalog size and team. We do recommend it, and build it, when one or more of these is actually true:

• The catalog is genuinely large, thousands of SKUs, with faceted search and filtering that needs something like Algolia or Elasticsearch tightly integrated into browsing, not bolted onto a plugin.
• You’re running multiple storefronts off one catalog — different regions, currencies, or brands — sharing a design system, where a single WordPress multisite setup gets awkward fast.
• The frontend isn’t really a “store,” it’s an interactive experience — a configurator, a marketplace, a subscription box builder — that a theme-based CMS was never built to render.
• You need real parity between a native mobile app and the web storefront off the same API, and you’re already committed to maintaining that app.
• You have engineering headcount to maintain a frontend indefinitely. Headless isn’t a launch-and-walk-away architecture, it’s an ongoing engineering commitment.

If you’re a five-person team without a dedicated frontend engineer, that last point alone usually settles it.

A pattern we’ve seen enough times to trust

A specialty foods brand came to us wanting a full headless rebuild before we’d scoped anything. A few hundred SKUs, mostly single-variant products, a two-person marketing team that runs seasonal bundles and promo banners every few weeks with no engineering support. We priced both options. WooCommerce launched in about two months on a customized theme with Advanced Custom Fields powering the seasonal landing pages; the headless quote for the same scope ran closer to five months and would have needed a frontend contractor on retainer afterward just to keep shipping promo pages. They went with WooCommerce. Their marketing team builds seasonal collection pages themselves now, the same afternoon they think of them, with no deploy and no ticket in our queue.

Compare that to an outdoor apparel retailer running three regional storefronts off a shared catalog, each with different currency, tax, and promotional logic, wanting eventual native app parity. That one we built headless, on a Next.js frontend against a commerce API, because the multi-storefront requirement alone would have meant fighting WordPress multisite the entire way, and the client already had budget for a frontend engineer post-launch. Same firm, same evaluation process, opposite conclusion, because the inputs were different.

How we actually make the call

Before we recommend a stack, we ask about catalog size and complexity, whether marketing or content teams need to publish without a developer on standby, what the real launch deadline and budget are, and whether there’s a specific, nameable reason the frontend can’t be a theme — not “headless feels more modern,” but an actual interaction or performance requirement a CMS genuinely can’t deliver. If nobody on the call can name that reason, that’s usually the answer by itself.

WooCommerce isn’t the right fit if you’re already running a dedicated headless CMS and commerce is just one piece of a bigger digital experience platform, or if you need several regional storefronts with independent design systems, or if page-load performance at global scale is a hard product requirement rather than a nice-to-have. For that work, we build headless, and we’re upfront about the timeline and team it takes to keep it running. But for most catalogs under 500 SKUs, with a small team and a real launch date, WooCommerce still gets you live faster, costs less to build and maintain, and hands you a plugin ecosystem that’s already solved problems you haven’t hit yet.

The post Why We Still Recommend WooCommerce Over Headless Commerce for Most Catalogs Under 500 SKUs appeared first on Softify Solutions.

The shape of the new system

Checkout.liquid let you edit the checkout page directly — HTML, CSS, inline script, all of it — but only if you were on Shopify Plus. Everyone else never had that access; the standard hosted checkout was always locked down to a logo and a couple of colors. Checkout Extensibility replaces that single editable template with three systems that barely overlap:

• Checkout UI extensions — React or plain-JS components you register at fixed injection points (“extension targets”) that Shopify defines. You don’t touch the page; you drop a component into a slot Shopify already built.
• Checkout branding — a design-token system (color roles, typography, corner radius, button and input styles, per-section color schemes) set through the CheckoutBranding API or the checkout editor’s Branding panel. No stylesheet, no selectors — you’re picking values from a schema.
• Shopify Functions — small, sandboxed server-side modules, written in TypeScript and compiled to WASM, or in Rust, that run during checkout to change discounts, shipping rates, payment method visibility, or reject the checkout outright with a validation error.

Add Web Pixels for anything that used to be a tracking script pasted into checkout.liquid, and that’s the whole surface. If what you need doesn’t fit one of these four buckets, it’s probably not happening — more on that below.

What you can actually change

More than the “you’re stuck with whatever Shopify gives you” crowd thinks, less than the “it’s basically as flexible as before” crowd tells clients. Concretely:

Visual branding is genuinely deep: accent, canvas, critical, and decorative color roles set independently per section — header, main content, and order summary can each carry a different scheme — plus a font picker pulling from Shopify’s library of a hundred-plus hosted fonts. If none of those match the brand typeface, custom font upload is possible too, via the CheckoutBranding API’s checkoutBrandingUpsert mutation, though Shopify’s own docs warn it costs render performance since the font has to download before checkout text can paint. Button fill vs. outline, corner radius, logo placement. This covers the “make it look like the rest of the site” work that used to eat half of every checkout.liquid ticket, and it survives Shopify’s redesigns instead of breaking on them.

New UI, at fixed points. A checkout UI extension can add a banner, a checkbox, a text field, a collapsible block, an image — Shopify’s own component library, not arbitrary markup — and place it at one of the defined targets: after the header, after the cart line list, before the shipping options, before the Pay Now button, on the Thank You and Order Status pages. The general-purpose block target alone has fourteen placements a merchant can drop it into from the drag-and-drop Checkout Editor. A gift-note field, an age-verification checkbox, a delivery-instructions box, a small “this order supports X” banner — all normal, well-supported work. Here’s roughly what that looks like for a bulk-order notice we’d actually ship:

// shopify.extension.toml
api_version = "2025-10"

[[extensions]]
name = "bulk-order-note"
handle = "bulk-order-note"
type = "ui_extension"

  [[extensions.targeting]]
  target = "purchase.checkout.block.render"
  module = "./src/BulkNote.jsx"

// src/BulkNote.jsx
import {
  reactExtension,
  Banner,
  useCartLines,
} from "@shopify/ui-extensions-react/checkout";

export default reactExtension(
  "purchase.checkout.block.render",
  () => <BulkNote />
);

function BulkNote() {
  const lines = useCartLines();
  const bulk = lines.some((line) => line.quantity >= 12);
  if (!bulk) return null;

  return (
    <Banner title="Bulk order" status="info">
      Orders of 12+ units of one item ship palletized, 5-7 business days.
    </Banner>
  );
}

Business logic moved into Shopify Functions, and this is the one place where extensibility is actually more capable than checkout.liquid ever was, because it runs server-side and deterministically instead of a client-side script racing the page render. Hide a shipping rate when the cart is under a weight threshold. Reorder payment methods for wholesale accounts. Block checkout entirely when a retail customer has a wholesale-only SKU sitting in the cart. Apply a discount that depends on combinations checkout.liquid could never evaluate reliably. It’s more code than the old inline-script approach, and it’s also a lot less likely to quietly break at 2am because Shopify shipped a checkout update.

What’s actually gone, not just moved

This is the part that gets glossed over, and the part that actually burned people. Some checkout.liquid behavior didn’t migrate to a new system — it just isn’t available anymore:

• Arbitrary DOM and CSS. You can’t select a specific native field and hide it, resize it, or move it with a CSS rule. If Shopify didn’t expose a target or a token for it, it isn’t reachable. A lot of “just nudge this field two pixels” tickets are now “that’s not adjustable, sorry” tickets.
• Raw script injection. Pasting a tracking snippet straight into checkout.liquid ended for good on August 28, 2025. Tracking now goes through the Web Pixels API, sandboxed in an isolated worker — no DOM access, no window.dataLayer, no arbitrary network calls, just a fixed catalog of events (checkout_completed, product_added_to_cart, and so on) via analytics.subscribe(). Several TikTok, affiliate, and CRO pixel setups we’ve inherited from clients had to be rebuilt from scratch, not reconfigured.
• Freeform field layouts. You get Shopify’s component set — TextField, Checkbox, Select, Banner, a handful of others — at Shopify’s targets. You cannot build an interaction pattern the component library doesn’t already offer, no matter how reasonable it seems.
• Flow restructuring. One-page checkout has been the default on every plan since 2023; the older step-by-step layout is still there as a toggle, not a design decision you get to make yourself. You’re not rearranging which fields appear on which step beyond what that toggle allows.

If your checkout.liquid did any of this, there’s no equivalent flag to flip. That work gets rebuilt a different way or it gets dropped, and pretending otherwise to a client just moves the bad news later into the project.

Where we disagree with the “you have full control” pitch

A lot of the migration content out there undersells how real this constraint is, because “don’t worry, extensibility covers everything” is an easier sentence to write than “some of what you had is gone for good.” We’d rather say the second one up front. Shopify traded raw flexibility for a checkout that can’t be broken by a merchant’s own script, that upgrades cleanly, and that Shopify can keep fast and PCI-compliant without auditing everyone’s custom Liquid. That’s a defensible trade. It just isn’t a free one, and treating it as free is how a fixed-bid checkout project goes underwater in week three.

We’ve also mostly stopped recommending the no-code “checkout customizer” apps that showed up once extensibility launched. Most of them are a thin admin UI wrapped around two or three of the same extension targets you can register yourself in an afternoon, for a recurring fee that outlasts the one-time dev cost within a year. If a client needs one field and one banner, we write the extension. If they need six apps’ worth of checkout behavior, that’s usually a sign to slow down and figure out how much of it actually needs to live in checkout at all, versus earlier in the funnel.

And if what a business genuinely needs is checkout behavior this system doesn’t expose — a custom split-payment flow across two processors is the one we hear most — we say so instead of stacking three Functions and a UI extension to fake it. That’s usually the point worth asking whether Shopify’s native checkout, specifically, is still the right fit for that one requirement. WooCommerce hands the checkout template back to you, at the cost of owning its security and upkeep yourself — a fair trade for a business whose checkout logic is genuinely unusual, and a bad one for a normal DTC store that just wants a checkout that stays up.

If you’re migrating now

Don’t port line by line. Audit what checkout.liquid was actually doing and sort it into four piles: pure styling goes to branding tokens, added UI goes to a UI extension, business rules go to a Function, tracking goes to Web Pixels. Whatever’s left after that sort is the genuinely unsupported pile — decide which of it matters enough to solve a different way, and which of it was a workaround for a problem that doesn’t even exist anymore. Budget for a rebuild, not a migration, and you won’t be the one explaining to a client in week four why the timeline just doubled.

The post What Shopify’s Checkout Extensibility Actually Lets You Customize appeared first on Softify Solutions.