Why We Still Recommend WooCommerce Over Headless Commerce for Most Catalogs Under 500 SKUs

Every few months a founder gets on a call with us already sold on headless commerce. They’ve read the case studies, they’ve seen a competitor’s storefront load fast, and they want the same stack — usually before they’ve picked a payment processor, sometimes before they’ve finalized the product catalog. Our first question is almost always the same: how many SKUs are you actually launching with?

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.