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.

1. Snapshot what’s active before you touch anything

Before deactivating a single plugin, get an exact record of what was running when the bug happened — not “I think it was the SEO plugin and maybe the page builder,” an actual list with versions attached. The fix six months from now depends on knowing precisely which combination broke and which one didn’t.

wp plugin list --fields=name,status,version --format=csv > snapshot.csv
wp theme list --fields=name,status,version
wp cli info

wp cli info also hands you the PHP version, which matters more than people expect. We’ve closed out a “plugin conflict” ticket that turned out to be a plugin that simply didn’t support PHP 8.1 yet — no second plugin involved at all.

2. Reproduce it off production, with every debug flag on

Never binary-search on the live site. Clone it — most hosts worth using give you one-click staging; if not, a wp db export and a duplicate install takes ten minutes. On the clone, turn every debug constant on:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set SCRIPT_DEBUG true --raw

SCRIPT_DEBUG is the one people forget, and it’s the one that matters for JS conflicts. It loads the unminified .js files instead of the bundled .min.js, so a browser console error points at an actual line in an actual file instead of plugin.min.js:1.

3. White screen already? Reach for –skip-plugins before FTP

If the conflict is a hard fatal and wp-admin won’t load at all, the instinct is to FTP in and start renaming plugin folders. That works — WordPress deactivates any plugin whose folder disappears — but it’s blunt, and it’s slow over SFTP on a cheap host. Try this first:

wp plugin deactivate suspect-plugin-slug --skip-plugins

--skip-plugins is a global WP-CLI flag that boots WordPress without loading any plugins, so the fatal never fires during bootstrap and the deactivate command actually gets to run. It’s the most useful flag nobody mentions in “how to fix a white screen” articles. Keep the folder-rename trick in your back pocket for the rare host that blocks WP-CLI entirely, but check for CLI or SSH access before you touch FTP.

4. Binary search, not one-at-a-time — with a caveat that actually matters

On the reproducible staging copy, deactivate everything and bring plugins back in halves instead of individually:

wp plugin deactivate --all
wp plugin activate plugin-a plugin-b plugin-c plugin-d plugin-e

Reproduce the bug. If it shows up, the fault lives in that half; if not, it’s in the other half. On a site with forty active plugins that’s six rounds, not forty. Here’s where we actually disagree with the standard advice: one-at-a-time reactivation only ever proves that a single plugin, alone, causes the bug. A good share of real conflicts are pairwise — two plugins that are each fine on their own and only break together, usually because they’re hooking the same filter, registering the same script handle, or writing to the same custom table. One-at-a-time will never catch that, because neither plugin alone reproduces anything. Binary search does catch it, as long as you’re deliberate about splitting suspicious pairs into different halves on the next round instead of always cutting the list down the middle.

5. No clean split? Stop guessing and read the hook order

Sometimes deactivating either half “fixes” it, which usually means the bug depends on load order rather than on which plugins are simply active — two plugins hooking the same action at the same priority, and whichever loads second wins. Dump the actual callback list for that hook instead of guessing:

wp eval 'global $wp_filter; print_r( $wp_filter["template_redirect"]->callbacks );'

That prints every callback registered on template_redirect, grouped by priority, with the exact class or function name attached. It turns “these two plugins don’t get along” into “Plugin B unhooks a canonical redirect that Plugin A depends on, both at priority 10, and B happens to load second” — a bug you can patch with a one-line priority change in a small must-use plugin, instead of a support ticket asking two vendors to make up.

6. Grep the log — but know some fatals never make it there

wp-content/debug.log is the first place to check, and grepping it beats scrolling it:

grep -i "fatal error" wp-content/debug.log | tail -20

The gap people hit: a fatal that happens while a plugin file is loading, before WordPress finishes bootstrapping and evaluates your WP_DEBUG_LOG constant, sometimes never reaches debug.log at all. It goes to the server’s own PHP error log instead. If debug.log is suspiciously quiet during a known white screen, that log is next, and it’s worth running php -l path/to/plugin-file.php to rule out a plain syntax error before assuming you’re dealing with a runtime conflict.

7. Enqueue collisions are a different animal from PHP fatals

Plenty of “plugin conflicts” are pure JavaScript — two plugins registering the same script handle at different versions, or each loading its own copy of Select2 or Slick with jQuery in a different mode. A PHP fatal log won’t show this; the browser console and an enqueue dump will:

wp eval 'global $wp_scripts; foreach ( $wp_scripts->queue as $h ) { echo $h . " => " . $wp_scripts->registered[$h]->src . PHP_EOL; }'

If the same handle name is registered from two different plugin directories, or the same library loads twice under two different handles, that’s the conflict — and the fix is usually one wp_deregister_script call in a small mu-plugin, not the removal of either plugin.

8. Rule the theme out before you keep blaming plugins

We’ve watched a client’s dev spend an afternoon deactivating plugins for a bug that was sitting in the theme’s functions.php the whole time. Before going further down the plugin list, switch to a default theme and see if the symptom survives:

wp theme activate twentytwentyfour

If the bug disappears, no amount of plugin deactivation was ever going to find it. The fault is in the child theme, not in any plugin, and everything above needs to point at theme code instead.

9. Query Monitor earns a temporary seat, not a permanent one

Once things are narrowed down this far, Query Monitor is worth installing — it shows hook execution, HTTP API calls, and database queries per request without hand-rolling wp eval dumps for everything. Our actual opinion: pull it back off once you have your answer. A debugging plugin left active “just in case” on a production site is exactly the kind of unaccounted-for plugin that kicks off the next conflict investigation.

10. Write the incompatibility down

Once you’ve found it, one line in a shared doc — plugin X plus plugin Y plus theme Z on PHP 8.2 produces this symptom — saves the next person, possibly future you, from re-running this entire process on the same combination six months from now.

To be honest about it: this whole workflow is overkill for a three-plugin hobby blog. On a site that small, just deactivate them one at a time — it’ll take five minutes and binary search buys you nothing. The staging clones, the hook dumps, the --skip-plugins trick — those earn their keep specifically on the client sites where guessing costs real hours: the ones running thirty, forty, sixty active plugins where nobody fully remembers what half of them are for anymore. That’s most of the WordPress and WooCommerce builds we get called in on, which is exactly why this list exists as a checklist and not a one-off blog post we wrote and forgot about.

The post A WordPress Plugin Conflict Debugging Checklist We Actually Use appeared first on Softify Solutions.