The WooCommerce plugin is free. The store it turns into is billed annually.

The WooCommerce plugin is free and open source, and that part is not marketing. There is no licence fee, no monthly platform charge, and no percentage taken from your sales. What costs money is everything a working store needs around it. Managed WooCommerce hosting runs $30 to $100 a month because a store runs database queries on every page view and cannot be served from a simple cache the way a brochure site can. A commerce-capable theme is $59 to $129 a year, renewed. Extensions are where the real number lives: WooCommerce Subscriptions, Bookings, Memberships, Product Add-Ons, Table Rate Shipping and AutomateWoo are annual subscriptions in the $49 to $249 range each, and a store running six to ten of them pays $600 to $1,500 a year. Add setup labor and a realistic five-year total lands between $8,000 and $20,000. The plugin is free. The store is not.

No, and this is a real advantage worth stating plainly. WooCommerce takes no cut of your revenue. You connect Stripe, PayPal, Authorize.net, or whatever gateway you have negotiated rates with, and you pay that processor's rate and nothing else. There is no platform middleman skimming a half point or two points off every order the way Shopify does on merchants who are not using Shopify Payments. WooPayments, the first-party gateway, charges standard card-processing rates with no platform surcharge on top. On this specific dimension WooCommerce and a custom store are identical: both connect directly to a processor, both pay processor rates only, and neither takes a percentage of your business. If transaction fees are the thing pushing you off a hosted platform, WooCommerce solves that problem completely. The reasons to look at a custom build instead are about speed, maintenance, and the subscription tail, not about fees on sales.

Caching fixes part of it and structurally cannot fix the rest. WooCommerce adds roughly thirty database tables to WordPress and asks the database questions on nearly every page view: what is in this visitor's cart, what is this product's stock level, which of these variations are still available, does this coupon apply. Product and category pages can be cached, so those get fast. Cart, checkout, and account pages cannot be cached, because the content is different for every visitor. Those are the three pages where a slow response costs you the actual sale. On top of that, the cart fragments feature fires a background request on page loads across the site to keep the cart total current, and every active extension adds its own code to every page. A typical WooCommerce store on decent managed hosting shows its main content on mobile in three to six seconds, and the pages that stay slowest are the ones nearest the money. A custom store builds the cart and checkout as lean, purpose-written code with no plugin layer underneath, and holds under one second across the whole funnel.

Six to ten for an established store, and the bill is annual rather than one-time. WooCommerce core covers a catalog, a cart, a checkout, simple shipping, coupons, and basic tax. Nearly everything past that is a paid extension with a yearly renewal: Subscriptions around $199 a year, Bookings around $249, Memberships around $199, Product Add-Ons around $49, Table Rate Shipping around $99, AutomateWoo around $99, plus a review platform, an advanced search or filtering tool, and a shipping-carrier integration. That is $600 to $1,500 a year for a store that is not doing anything unusual, and $4,500 across five years at the middle of that range. Let a renewal lapse and you keep the code but stop getting security patches and compatibility fixes, which on a store handling payment flows is not a saving. On a custom build those same behaviours are written into the codebase once, and they carry no renewal date, no vendor to outlive, and no annual invoice.

Yes, and the gap is larger on a store than on a brochure site because the stakes are higher. WordPress is the most-probed platform on the internet, and a WooCommerce install inherits all of that plus a database holding customer names, addresses, order history and payment metadata. The exposure is not WooCommerce core, which is well maintained and audited; it is the surface area. Every extension is code from a separate vendor running inside your store, and the standard disclosure process publishes a flaw on a fixed timetable whether or not the vendor has shipped a patch. A store running ten extensions is running ten bets that each vendor patches quickly, that the patch is compatible with your setup, and that somebody installs it before automated scanners reach you. A custom store has no admin login page for bots to hammer, no third-party extension code, and no plugin update cycle. Maintenance is keeping the server software current and making sure the code handles submitted data safely. That is a materially smaller target for a store that holds real customer data.

Yes, and this is the one place where the honest answer requires a distinction. WooCommerce hands you the WordPress admin for free: a product editor, variation management, stock levels, coupon creation, and order processing, all self-service and all included the moment the plugin is installed. A custom store gets a purpose-built admin covering the same operations, but it is scoped and built as part of the project rather than arriving free with the platform. The practical difference is what it covers. The WooCommerce admin covers everything WooCommerce does, including a lot you will never touch. A custom admin covers what your store actually does, with no unused screens and no settings tabs belonging to plugins. If your catalog turns over weekly and non-technical staff run it, name that in the brief and the admin gets built for it. If your catalog is stable and changes a few times a quarter, the Care or Priority hosting tiers cover those edits inside the monthly fee without an admin at all.

Close to it, and this is where WooCommerce clearly beats every hosted platform. WooCommerce is open source and self-hosted. You hold the files, you hold the database, you can move to any host that runs PHP and MySQL, and nobody can switch your store off for non-payment of a subscription. That is real ownership and it deserves credit, because it is the single biggest structural difference between WooCommerce and Shopify or BigCommerce. The asterisks are about dependency rather than possession. Your store runs only on top of WordPress core, a compatible PHP version, a theme, and a set of extensions at matching versions, each with its own vendor and renewal date. Change any layer without testing and things break. An extension whose vendor walks away becomes a piece of your store that nobody will ever patch again. A custom store has one dependency: a standard PHP web server. Any competent developer can read the code, and there is no compatibility chart to keep in sync.

The code keeps working until something around it changes, and then you are on your own. Extensions stop being maintained for ordinary reasons: the vendor sells the business, the developer moves on, the product stops earning enough to justify support. Nothing breaks the day that happens. The problem arrives at the next WordPress major release, the next PHP version bump on your host, or the next WooCommerce update that changes a hook the extension relied on. At that point the store either throws errors or silently stops doing something, and there is no patch coming. The options are all bad in their own way: freeze WordPress and PHP at old versions and accumulate security debt, pay a developer to fork and maintain someone else's code, or rip the extension out and rebuild the feature. Stores commonly discover this during an emergency rather than on a planning calendar. On a custom store the equivalent feature is your own code, in your repository, and the person who maintains it is whoever you hire.

Six to ten weeks for most stores, and the WooCommerce side of it is easier than migrating off a hosted platform because you have direct access to the database rather than a limited export file. Products, variations, categories, customers and order history come across as a scripted import rather than a spreadsheet round trip, which removes a lot of the manual reconciliation that a Shopify or BigCommerce migration involves. The work that takes real time is rebuilding whatever your extensions were doing, mapping the catalog into a structure that suits your customers rather than one a plugin imposed, and making sure every product and category address that Google indexed forwards to its new home before launch rather than after. Stores with subscription billing, complex variant matrices, or a live integration with a fulfilment provider need more planning up front. The existing store stays live and taking orders until the new one is finished and tested, so there is no trading downtime, and rankings generally hold and often improve because the new store is faster.

For most stores yes, but it depends entirely on your extension bill, and the honest version of this answer needs your numbers rather than an average. Take a representative store: $2,500 in setup labor, $50 a month for managed WooCommerce hosting, a $99 a year theme renewal, and $900 a year in extension subscriptions. That is $10,495 over five years. A custom build at $2,800 with $60 a month Core hosting is $6,400 over the same five years, a difference of $4,095, and the custom side of that figure stops growing once the build is paid for. Change one input and the conclusion moves. A store running two extensions on cheap shared hosting can come in under a custom build and stay there. A store on the $100 Care or $180 Priority hosting tier gives back part or all of the advantage. Add up your last twelve months of hosting, renewals, extension invoices and developer hours, multiply by five, and compare that to a quote. That is the only version of this calculation that means anything.

When the WordPress side of the site is doing real work, when your feature set maps cleanly onto extensions that already exist, or when self-service catalog management by non-technical staff is a daily requirement. A business publishing several articles a week with a store attached gets genuine value from having both in one system with one login and one content model. A store whose needs are exactly WooCommerce Subscriptions plus WooCommerce Bookings is buying two mature products for a few hundred dollars a year rather than commissioning them. A team where three people who cannot touch code add products every day is using the admin hard enough to justify it. There is also a replaceability argument that deserves respect: the WooCommerce developer pool is enormous, so you can fire your developer on a Friday and hire another on Monday. The case for moving is strongest when the store is a catalog and a checkout, the extension renewals keep climbing, and the pages nearest the money are the slowest ones on the site.