Where WooCommerce earns the work
- B2B distribution + wholesale with tiered pricing, NET-30 invoicing, customer-specific catalogs.
- Subscription commerce with WooCommerce Subscriptions + custom logic for box / membership models.
- Multi-region inventory synced from an ERP (NetSuite, SAP B1, custom).
- Content-heavy stores where the editorial side matters as much as checkout — ingredient pages, founder stories, seasonal campaigns.
Where I’d push you to Shopify instead
Standard D2C, sub-300 SKUs, single region, no B2B requirements, marketing team owns the store, you want apps for everything — Shopify ships faster and costs less to operate. Woo earns its complexity when the requirements get genuinely complex.
The WooCommerce stack I actually use
Foundation: WordPress + Woo, custom block theme (no Storefront, no Astra, no Avada). B2B layer: Wholesale Suite or custom roles + ACF, BookBuy or Sliced Invoices for terms. Performance: Redis object cache, FlyingPress, ShortPixel, Cloudflare with full-page cache. Integrations: ERP via REST + nightly cron sync, Klaviyo, Stripe / Authorize.net, ShipStation. Hosting: Rocket.net or Cloudways Vultr HF — never shared.
Common questions
Can WooCommerce handle 18,000 SKUs?
Yes — done it more than once. The trick is Redis, proper indexing, and not stuffing the catalog through 47 plugins. A well-configured Woo install with object caching handles enterprise catalogs comfortably.
Will it survive Black Friday traffic?
Yes if it’s hosted properly. Page cache + Redis + Cloudflare absorbs the spike for catalog and content pages. Checkout is the part that needs the most attention — typically I run that through a load test 30 days out, then again 7 days out, and pre-warm the cache the morning of.
Why not headless WooCommerce?
Sometimes yes — Woo + Next.js + WPGraphQL is excellent for catalog-heavy stores where content velocity matters. But for 90% of Woo engagements, the marginal gain isn’t worth the operational complexity. I’ll tell you which side of the line you’re on during scoping.
