WooCommerce vs Shopify at 500 Orders a Month: Where the Cost Sits

Every WooCommerce vs Shopify comparison I've read is written for someone choosing a platform for their first store. Fee tables, theme counts, a screenshot of each admin. That's a fine way to pick where to sell forty candles a month. It tells you nothing about the decision that lands on the desk of a brand doing 500 orders a month with three people in the business who touch the store.

We've built and run both. One WooCommerce store we maintain has taken more than 150,000 orders and over £5m in revenue, and it has almost never gone down. We've also migrated stores off WooCommerce because they'd become unmanageable. This is about where the money and the time go on each platform once you're past the point where the plan fee matters.

The fees are nearly a wash

Everyone wants to argue about the fees, so I'll start there.

Take a UAE store selling at an average of AED 200, doing 500 orders a month, with a third of customers paying on international cards. That's AED 100,000 a month through the checkout. Using Shopify's published UAE rates and Stripe's published UAE rates for the WooCommerce side, here's what each platform charges to process it.

AED 31 a month apart. You could move that gap either way by changing the hosting plan or the card mix, and neither platform would come out ahead by enough to notice against AED 100,000 of sales. If you present prices in the customer's own currency, both add a conversion charge on top of the card rate, Stripe at 1% and Shopify at its own published conversion fee, so a store selling abroad should model that line separately. It's still small next to the processing total.

Shopify Payments is the thing that can actually move this line. In the UAE it's still early access, enabled per store. Without it you're on a third-party gateway and Shopify charges its own transaction fee on top of the gateway's: 2% on Basic, 1% on Grow, 0.6% on Advanced. On our example store that's AED 1,000 a month on Grow, which is four times the plan fee. If you're comparing platforms in this market, find out whether Shopify Payments is available to you before you do anything else.

Plan tier moves it too, but only at much higher volume. At 500 orders the step from Grow to Advanced costs AED 844 a month more and saves 0.1% on processing, which is AED 100. That maths flips somewhere past 4,000 orders a month, and our fee calculator will find the crossover for your numbers. Below that, stay on Grow.

Owning the stack

On WooCommerce, you own a server. Even on managed hosting, where Kinsta or WP Engine patch the operating system and run the firewall, you still own what runs on it: WordPress core, WooCommerce, the theme, and every plugin. Each of those ships updates on its own schedule, and every update is a small decision about whether it's safe to apply. On a store doing real volume, that decision has a cadence.

In July, WP2Shell put an unauthenticated remote code execution chain into WordPress core, and public exploit code was circulating the same evening the patch shipped. A day after the patch, half of the organisations running WordPress that Wiz could see still had a vulnerable instance. The gap between a patch landing and it being exploited is now measured in hours, which means whoever owns your updates has an SLA measured in hours, whether or not anyone wrote it down.

On the stores we look after, that ownership work runs to a few hours a month when the store is well run: reading changelogs, applying updates on staging, checking the checkout still works, occasionally untangling a plugin conflict. On a store that isn't well run, it's a few hours a month of nothing followed by a bad week. Either way it's a line in your costs that no pricing page shows, and on our example store it's larger than the AED 31 gap between the two platforms' fees.

Shopify takes the server, the runtime, PCI scope, backups and patching off your desk, and you can't touch them. Apps run on Shopify's infrastructure rather than inside your store, so a badly written app is a broken feature, not a shell on your server. You pay for that with control: you can't audit what they fixed, you can't tune the server, and you can't run code where they haven't given you a place to run it.

I've written before that the two models fail differently rather than one being safer, and I still think that's the right way to look at it. What changed in 2026 is how expensive the self-hosted failure mode got, because the clock on it got faster.

Plugins at scale

The WooCommerce stores we're asked to look at almost always have the same shape: twenty to forty active plugins, several doing overlapping jobs because the developer who added the second one didn't know the first was there, a handful nobody can explain, and a core update cadence that's slipped because the last time someone updated WordPress a plugin broke the checkout and now everyone's nervous.

That stack accumulates on any open platform over three or four years of decisions made by different people. It isn't WooCommerce's fault, but it is the platform's shape that lets it happen, and at volume it costs you in fragility and in speed.

Every plugin is code running inside your store with database access, so a plugin author's mistake is your outage. The WordPress plugin supply chain had a bad year, with Wordfence's AI researcher finding 202 vulnerabilities by late July and one vibe-coded plugin turning up with a hundred distinct issues. A 30-plugin stack is 30 vendors whose testing you're relying on.

Shopify has a smaller version of the same problem. Apps inject JavaScript into your storefront, and an established store with 20 apps carries the weight of 20 vendors' scripts. Shopify's own answer was to deprecate script tags entirely, with a hard stop in March 2027, which I covered in August's changelog roundup. A bad Shopify app slows your theme or breaks a feature. A bad WooCommerce plugin can take the store offline or expose the database. Both need managing, but only one of them can hurt you in a way that needs a restore from backup.

Is WooCommerce slow?

Out of the box, on cheap hosting, with a page builder theme and thirty plugins, yes. That's the store most people are describing when they say it.

The platform itself can be fast, and that example is a stack problem. Managed hosting with server-level caching, a theme that isn't a page builder, a plugin audit that gets the count under fifteen, images sized properly, and a CDN in front of it all - we've built WooCommerce stores that load as fast as anything on Shopify. Every one of those items is a project with an owner and a budget, though, and they drift. The plugin count creeps back up, the developer who set up the caching leaves, and two years on the store is slow again and nobody's sure why.

Shopify's storefront runs on Shopify's CDN with Shopify's caching, so you don't get to make it slow at the server level. You can still make it slow with apps and a heavy theme (plenty of stores do), but the floor is higher and it holds without anyone maintaining it.

Team workflows

If I were deciding, this is where I'd spend most of my attention.

Shopify's admin is the same in every store, which sounds trivial until you're hiring. Someone who's run a Shopify store before can run yours on day one, and Shopify's own training material covers the admin your staff will use. Permissions are built in, the mobile app handles orders and inventory from a phone, and the order screen at 500 orders a month is the same order screen at 5,000.

A WooCommerce admin is WordPress plus whatever the previous developer bolted on, so every store is slightly different. Orders live in the WordPress admin alongside blog posts and media, and at volume the order screens used to crawl because orders were stored as posts. High-Performance Order Storage fixed most of that once WooCommerce made it the default, but a store built before then may still be on the old tables, and switching is a migration of its own. Roles and permissions come from WordPress, which was designed for publishing, so giving a warehouse person access to orders without access to everything else takes a plugin or custom work.

Where WooCommerce is better is content. If your business has an editorial side that does real work - a magazine, a recipe library, a learning hub that drives your acquisition - WordPress is still a better place to write and manage it than Shopify's blog, and having commerce and content in one system with one login matters to the people doing the writing. Shopify's answer is to run content elsewhere and link across, which works, and which every content person I've worked with dislikes.

The other place WooCommerce wins is custom logic: tiered B2B pricing, customer-specific catalogues, fulfilment rules that depend on inventory location, anything that lives in the database and runs on every order. On WooCommerce you write it and it runs. On Shopify you find an app that does most of it, or build a Function, or work around it. Shopify has closed a lot of this gap since 2023, with B2B on Plus and Functions for discounts, delivery and payment logic, but if your margins depend on unusual rules, scope them on Shopify before you decide, because the answer changes the budget.

Checkout

The checkout is the one structural difference that doesn't come down to maintenance, and I said the same thing in our migration guide.

Shopify's checkout is shared across every store on the platform, and Shop Pay recognises a returning buyer whether or not they've bought from you before. A shopper who paid with Shop Pay on someone else's store last month arrives at yours with their details ready. You can't replicate that on your own domain, however good your WooCommerce checkout is, because the network effect belongs to the platform rather than the store.

You customise Shopify's checkout through extensions in the places Shopify allows, and the old approach of editing the checkout template directly is gone. For most brands that's fine and the conversion gain outweighs the lost control. For a store whose checkout is doing something unusual, it's a scoping conversation.

On WooCommerce the checkout is yours entirely, which means you can do anything to it, and you also own every bug in it. Every abandoned cart it causes is on you to diagnose.

When WooCommerce is the right answer

We tell plenty of clients to stay where they are.

Stay on WooCommerce, or choose it, when content and commerce need to live together and the content side is real. When your business logic is unusual enough that Shopify would need three apps and a workaround to approximate it. When you have a developer who owns the stack properly and wants to, and the cost of that person is already in your numbers. When you need to audit what runs on your store, for compliance or because your board asks. And when you're small enough that the plan fee and the app subscriptions would be a meaningful share of your margin, which is roughly the point where a fee comparison starts to matter and this article stops applying.

A well-run WooCommerce store serving a large catalogue is a good asset. Replatforming one is expensive, disruptive and, done badly, costs you the search traffic that took years to build.

When it's time to move

Move when the ownership cost has become the store's biggest hidden line and nobody wants to own it. WordPress core updates get deferred because the last one broke something. Your marketing lead is the person who knows how the hosting works. Peak season means a conversation about server sizing rather than about merchandising. The plugin count only goes up. And the person who set most of it up doesn't work there any more.

Checkout is the other trigger. Once you've done what can be done on your own domain and conversion at the last step is still the constraint, the shared checkout is the one thing you can't build your way to.

If that's where you are, our Shopify migration page covers how we run the move: what carries over, what doesn't, the redirect work that protects your rankings, and the synchronised build we use for stores that can't stop taking orders while the new one is built. If it isn't where you are, keep the WooCommerce store, fund the person who owns it, and get the plugin count down.