I was running a niche electronics store — physical stock, not drop-shipped — and we initially went with Shopify. Because everyone around me did. Cool themes, fast launch, and their App Store honestly looked helpful at first glance. But once we hit about 300 SKUs across a few categories, the interface got sluggish. Not unusable, just… grindy. Bulk editing prices involved opening Google Sheets and praying the CSV upload didn’t burn down the tags. The real killer was when we wanted a custom product bundling setup — not the generic “Buy X, Get Y,” but a blend-and-choose model. Native Shopify couldn’t handle that. Plugins existed, sure, but they either broke the cart or cost more per month than my dog’s food bill.
Quirky observation? Shopify’s liquid-based templates sometimes just… skip rendering components if you mess up a loop scope. You won’t get an error. Your product grid just silently disappears. Learned that one at 2 a.m. when inventory decided it no longer wanted to be visible on mobile.
When WooCommerce Becomes a Maintenance Hobby
WooCommerce will absolutely let you do anything. And you’ll be maintaining every part of that freedom like an old Jeep. The plugin ecosystem is massive, the PHP hooks are friendly enough, and if you’ve got experience with WordPress templating it almost feels fun. For a few months, anyway. Then cron jobs stop firing, database calls balloon, and suddenly there’s a delay when a customer applies a coupon. Not every user notices it, but those who do, do it loudly — usually via support tickets with bad spelling but valid points.
One Sunday, the checkout button just vanished. Not grayed out, not non-functional. Gone. Turns out the PayPal plugin was auto-updated and silently added an extra div wrapper that broke the button’s parent element in the theme. Took two hours and a lot of inspect-element contortions to find it.
There’s also this annoying behavior where if a cached version of the cart is served after a session expires, prices reappear as zero. Not everywhere — only on the mini-cart widget. You better believe a couple customers screenshotted that and demanded honor pricing.
Use Woo if you love plugins and control. Just know you’ll wake up one day to a 504 and no clear starting point.
BigCommerce: Decent B2B Kit But Pricing Creeps Fast
BigCommerce showed promise for a client who needed decent API access and customer group pricing. They sold equipment to both hobbyists and distributors, which meant three tiers of pricing logic and strict shipping rules — welcome to B2B. BigCommerce handled customer segmentation cleanly, especially compared to the Frankenstein you’d need on Woo or Shopify. But beyond a certain usage threshold, their plans upgrade automatically. Without warning. We got bumped mid-month. It felt like someone turned gravity up without telling us.
Also, their template structure is more rigid than you’d think. Don’t let the Handlebars syntax fool you. When we tried injecting a custom React widget into the cart, it half-loaded and messed with form submission. Support couldn’t help since, technically, that wasn’t an approved integration pattern. Had to back it out fast.
Some oddities I ran into:
URL slugs sometimes auto-generate with random digits appended if the original exists, even if it was soft-deleted
Variant-specific images can take weirdly long to propagate globally (~10+ mins)
Inbound webhook payloads come in snake_case, but GraphQL returns camelCase. Ask me how I learned this.
Squarespace, Unless Your Store Sells One Type of Thing
Squarespace commerce looks slick if you’re selling coffee beans or T-shirts. Minimal config, beautiful on mobile, very WYSIWYG. But once you need SKU-level rules — like color + size + inventory per warehouse — things fall apart. The inventory UI simply cannot handle it. You’ll click 18 times before realizing you can’t disable a variant without re-uploading. I promise, someone in your org will ask “Can we just sell it through Squarespace until we get traction?” That’s bait.
They also do this thing where sales tax is configured per zone, but if your address fields don’t validate in their geocoder, the tax silently fails. I had a client in rural Canada where two buyers showed up with no GST applied. Digging through logs revealed nothing; it only surfaced when I dumped the form submission payload live.
Magento (Adobe Commerce) Will Punish Half-Baked Usage
Once upon a time, I inherited a Magento store with just over 50K SKUs, poorly categorized, caching disabled in staging and production, and a database hosting bill 9x too high. If you’re not willing to hire a Magento dev (or be one), don’t do it. Magento is extremely powerful but extremely uncompromising. XML-based layout instructions, service contracts, custom module injection — it was built for the kind of teams that diagram their Git branching strategy.
And yet, one night I found a helpful diagnostic buried in Magento’s system.log:
[2023-07-18 01:12:33] main.DEBUG: cache_invalidate: 3 block(s) and 2 page(s)
I realized a cronjob wasn’t clearing the checkout cache on inventory updates. That’s why stock mismatches were happening. No UI hint, just a log that quietly whispered the answer while I drank my third coffee.
If you’re going with Magento, set up a monitoring stack early. Log everything to something searchable. Cloudflare’s cache bypass headers can help, too — especially if your origin makes five DB calls to render breadcrumbs.
Commercetools, If You Want to Build It All
Commercetools is not a plug-and-play system. You build the frontend, the cart, the checkout logic — everything — and they give you an amazing API for it. One of our enterprise clients used it for a clothing brand with customization steps and fancy inventory routing. It worked, but they also had four engineers dedicated to the storefront. That says a lot.
The most annoying thing? Their sandbox environment doesn’t always mimic production performance. We built a personalization flow that tested fine in sandbox, but once we hit concurrency in staging, the first API call froze sequentially.
Aha moment: We noticed that the SDK bundled all mutation calls by default unless overridden — caused a bottleneck in checkout saving. You have to explicitly opt out of that batching logic in the JavaScript SDK.
Undocumented edge case: You can’t update a product’s masterVariant through the product update endpoint unless you reset all variant IDs manually. Otherwise, it errors with an untraceable “400 – invalid request” that won’t even show context.
Headless Setups Seem Fun Until You Debug Taxes
I get it — you want a Gatsby or Next frontend talking to a headless backend, maybe a CMS in the middle, some GraphQL, maybe even Stripe as your cart brain. It’s clean, imposes structure, and feels good to build. Now try handling local tax adjustments for zip+4 U.S. addresses. Or VAT edge rules when digital goods are sold from Ireland to Germany. Suddenly, your joy disappears in a sea of middleware functions named things like mergeLineItemsWithJurisdiction().
Real thing that broke us: authoritative tax wasn’t recalculating after upsell injection because cart timestamps were re-used. There’s no spec saying “always refresh tax if cart total changes via non-product SKU.” Had to force a per-line-item tax recalculation using a mutation call buried in the official SDK’s beta branch.
If you do go headless, bake these in early:
Synchronous checkout validation for price + tax delta
Server-side log of tax engine hits with response payloads
A test account with ridiculous rules: Alaska billing, Florida shipping, digital item + physical combo
Real coupon codes with fractional discounts to trap rounding bugs early
You either spend time building or debugging — headless makes it hard to know which one you’re in until it’s too late.
Weirdly Reliable: Ecwid for Simple Product Catalogs
I wouldn’t use Ecwid for a complex store, but for drop-ins on static sites where you’ve got fewer than a hundred SKUs and no variant logic, it’s been weirdly stable. I popped it into a Hugo-powered jamstack site and it just… worked. Inventory sycs were quick, embed scripts light, and PCI coverage handled via their built-in checkout.
Annoying quirk though — they don’t expose structured schema.org data unless you massage the embed code yourself. We had to write a little JS shim to inject proper meta tags for SEO, or else Google thought every product was “Product: null price.”
Also, their reporting UI rounds values in weird places. If you’re used to exact numbers down to cents, this’ll make you twitch.
But for a no-frills pop-up shop or seasonal promo catalog, it held up better than I expected.
