The short answer: Choose Shopify when speed, predictable hosting, and a managed commerce core matter more than deep control. Choose WooCommerce when content and storefront flexibility matter and you can own the WordPress operating burden. Choose custom commerce only when a requirement that materially affects revenue or operations cannot be handled well by a platform, extension, or targeted integration.
The wrong way to decide is to compare a Shopify subscription with a WooCommerce plugin price and a custom-development quote. Those are three different slices of cost. The useful comparison is the same customer journey, order volume, integration scope, and service level over 36 months.
In our Shopify storefront work for 98 Degree North, the important engineering questions were product discovery, theme behavior, and mobile shopping. In the LoBecho commerce app, the product scope included vendor onboarding, catalog management, local payments, and order workflows. These public project descriptions illustrate a principle: a branded store and a multi-vendor commerce product are not the same problem. They should not be priced as if they are.
The decision in one table
| Decision factor | Shopify | WooCommerce | Custom e-commerce |
|---|---|---|---|
| Best fit | Standard to moderately complex retail, rapid launch, small operations team | Content-led retail, WordPress-centric teams, flexible integrations | Non-standard marketplace, pricing, fulfillment, or ownership requirements with a strong business case |
| Upfront build | Usually lower for comparable standard requirements | Moderate; theme, hosting, plugins, and QA add up | Highest; core flows, admin tools, testing, and operations must be engineered |
| Ongoing ownership | Platform manages core hosting; merchant owns apps, data quality, theme, and processes | Merchant or partner owns hosting, updates, backups, security, and compatibility | Merchant owns the whole product lifecycle or contracts it out |
| SEO control | Strong practical basics, with platform conventions and implementation constraints | Extensive control, but plugin/theme quality and server performance matter | Maximum potential control; also maximum scope for expensive SEO mistakes |
| Extension risk | App subscriptions, app data dependencies, and integration limits | Plugin conflicts, renewals, and patch responsibility | Custom code, specialist dependency, and operational continuity |
| Default recommendation | Start here if standard flows cover the business | Choose when its flexibility is valuable enough to operate | Prove why platform workarounds cost more than building and maintaining the exception |
None of the three comes with automatic rankings or conversions. A slow, confusing product page can be built on any of them.
What the platform prices do, and do not, tell you
As checked on October 15, 2026, Shopify’s US pricing page lists Basic at $29/month when billed yearly ($39/month monthly), Grow at $79/month yearly, Advanced at $299/month yearly, and Plus from $2,300/month. Geography, billing terms, payment provider, and feature requirements change the bill; verify the relevant local pricing and contract before budgeting.
WooCommerce’s pricing page says its core platform is free and open source, while hosting, paid extensions, payments, and implementation are separate costs. Its own page gives indicative hosting and extension ranges, not a promise that a production store is free.
A custom build has no universal sticker price. A quote needs a defined scope: catalog and variants, checkout, tax and shipping, customer accounts, refunds, fulfillment, integrations, admin permissions, search, analytics, observability, and support. A proposal that prices only the storefront misses most of the operating system behind it.
A plan fee is a line item. Total cost of ownership is a business model.
A 36-month cost model you can actually audit
Use this formula for each option:
36-month cost = one-time design/build/migration + 36 x monthly platform, hosting, app and infrastructure spend + 36 x ongoing operations and maintenance + payment and transaction fees + major feature changes + migration risk allowance.
Keep common costs common. If the same payment processor charges the same base fee under every option, show it in each column or exclude it from the comparison. If a platform imposes an additional fee for your chosen payment setup, include that incremental difference. Also include marketing, content, photography, and fulfillment only when their cost actually changes by platform.
Worked example: one hypothetical merchant, same requirements
Assume a single-market retailer with approximately 2,000 orders per month, a $75 average order value, a conventional catalog and checkout, one ERP sync, modest content publishing, and the same uptime/support expectation on all three options. Internal or agency operating time is valued at $75/hour. This is a planning scenario, not a Boxinall quote or a market benchmark. The higher custom build is deliberately included to show the price of buying control when the requirements do not yet demand it.
| Modeled cost, USD | Shopify | WooCommerce | Custom |
|---|---|---|---|
| One-time build, setup, integration, and launch QA | $15,000 | $22,000 | $80,000 |
| Monthly platform/hosting/apps/infrastructure | $699 | $500 | $1,300 |
| Monthly operating effort at $75/hour | 10 h = $750 | 18 h = $1,350 | 35 h = $2,625 |
| Monthly modeled run cost | $1,449 | $1,850 | $3,925 |
| Year 1, including one-time work | $32,388 | $44,200 | $127,100 |
| Year 2 | $17,388 | $22,200 | $47,100 |
| Year 3 | $17,388 | $22,200 | $47,100 |
| 36-month modeled base cost | $67,164 | $88,600 | $221,300 |
The table excludes payment processing, material feature expansion, tax, paid acquisition, and migration disruption because those depend on actual contracts and forecasts. It also does not assume that WooCommerce is always costlier than Shopify. Change the hosting, extension, app, support, and labor inputs and the order can change.
Here is why fees deserve a separate sensitivity test: at $1.8 million in annual sales in this example, an additional 0.5 percentage point on revenue would be $9,000 per year, or $27,000 over three years. That is a hypothetical fee difference, not a claim about any one platform’s current fees. Read the actual payment and third-party transaction terms, including country and plan restrictions, before entering this line.
Then model an upside and downside case: more orders, more apps, one failed integration, and a 30-day launch delay. A single confident-looking total is not a forecast.
The SEO trade-off is implementation, not a platform scoreboard
Shopify: It supplies a hosted commerce foundation and practical SEO controls, but you work within its URL conventions, theme architecture, app ecosystem, and platform behavior. A migration may change category/product URLs even when content appears identical. Check what your intended plan and theme actually permit before committing to a design.
WooCommerce: WordPress offers substantial control over content, templates, URLs, plugins, and hosting. That control is valuable only if someone maintains it. Duplicate archives, indexable filter combinations, slow plugins, incorrect canonicals, or weak hosting can erase the apparent SEO advantage.
Custom: You can design product data, URL structure, internal linking, rendering, and feeds around the business. You can also accidentally ship product pages without crawlable links or usable server-rendered content. Google explicitly recommends crawlable navigation and consistent canonical, sitemap, and internal-link URLs for e-commerce sites. See its guidance on site structure and e-commerce URLs.
Across all three, judge the implementation by the same evidence: indexed category and product URLs, useful descriptions, mobile experience, internal links, canonical consistency, product availability/price accuracy, and valid product structured data. Filters deserve special attention: uncontrolled combinations can create huge low-value URL spaces, as Google’s faceted-navigation guidance explains.
The question is not “Which platform has better SEO?” It is “Can this team preserve discoverability while operating this specific catalog at this level of complexity?”
The Boxinall commerce exception ledger
Platform demos show the happy path. Real margins disappear in the exceptions. Before selecting or replacing a platform, build a short ledger of the flows that can lose money, trust, or operational time. For each row, classify the solution as native, reliable extension/app, targeted custom integration, manual workaround, or unsupported.
| Exception to test | Evidence to request | Why it changes the decision |
|---|---|---|
| Partial refund after split shipment | One order and settlement trace | Refund and inventory states can diverge |
| Two customers buying the last item | Concurrency test | Overselling becomes a customer-service and margin issue |
| Failed payment callback or duplicate webhook | Retry and idempotency test | An order must not be charged or fulfilled twice |
| Mixed tax rules or cross-border returns | Actual jurisdiction and product examples | Generic tax demos hide operational edge cases |
| B2B tiered pricing or negotiated terms | Named customer/role scenario | App stacks may become brittle or expensive |
| Marketplace vendor payout and disputes | Settlement, commission, and reversal flow | A simple storefront checkout is not marketplace accounting |
| ERP or warehouse mismatch | Reconciliation sample | A sync that works 99% of the time can still create daily exceptions |
This is not a claim that Boxinall has measured every case for every merchant. It is a practical evaluation tool grounded in the difference between storefront work and deeper commerce operations. If every critical row is native or cleanly extensible, a custom platform needs a stronger justification. If multiple high-frequency, high-impact rows require permanent workarounds, the real cost of a “cheap” platform rises.
When should you switch? Use the friction-to-build test
Do not migrate merely because another platform has a new feature, lower headline fee, or louder marketing. First ask whether the present constraint can be removed with a theme improvement, one integration, a better plugin/app, cleaner data, or a revised process.
Consider switching when at least one of these is true:
- Critical customer or staff journeys remain unreliable after targeted fixes.
- Recurring workarounds consume measurable hours or cause documented lost sales.
- An unavoidable platform limitation blocks a strategic capability such as vendor settlement, complex pricing, or channel orchestration.
- Security, data-residency, or integration requirements cannot be met acceptably under the current architecture.
- The 36-month cost of staying, including exception handling and foregone opportunity, exceeds the cost and risk of moving.
A simple payback check: if a migration costs $36,000 and eliminates $1,500/month of net operating cost, simple payback is 24 months. If the new platform adds $500/month of maintenance, net benefit is $1,000/month and payback becomes 36 months. This example excludes revenue changes, tax, financing, and migration risk; it is a screening calculation, not an investment recommendation. Demand a measured baseline before claiming savings.
An expensive platform can still be the right choice when it unlocks profitable capability. A cheaper one can be wrong when staff spend every day repairing orders. The burden of proof belongs to the proposed switch.
The reversibility test: price the exit before you enter
Most comparisons score what a platform can do on launch day. Few ask how hard it will be to leave. Before signing or rebuilding, document:
- Exportable product, customer, order, and content fields, including historical status data.
- Ownership and portability of theme/code, app configuration, workflows, analytics, and domains.
- Payment-token portability and any processor restrictions; never assume raw payment data can simply be exported.
- URL patterns, redirect ownership, canonical behavior, and media-file access.
- App/extension contracts, renewal dates, termination fees, and data retention.
- A realistic handover path if the agency, developer, or key employee changes.
Call this exit cost, and add it to the decision. “No lock-in” is not a feature description; it is something you can demonstrate with an export, a contract, and a test migration.
The SEO parity gate before any platform cutover
Google’s site-move guidance says to map old URLs, test the new site, redirect changed URLs, update internal links, and monitor the move. We would turn that into a release gate, not a post-launch wish list:
- Inventory the current site. Export all indexable products, categories, editorial pages, top organic landing pages, backlinks, and their traffic/conversion baselines.
- Create a one-to-one URL map. Preserve high-value URLs where possible. For changed URLs, specify the closest relevant destination; avoid blanket redirects to the home page.
- Match content and signals. Check titles, descriptions, canonical tags, headings, product data, schema, images, variant behavior, sitemaps, and robots rules.
- Test representative journeys. Crawl mobile and desktop pages; verify product/category links, checkout, refunds, stock updates, feeds, analytics, and event tracking. Keep staging out of search.
- Reconcile real operational records. Compare sampled orders, payment states, tax, stock, and fulfillment between old and new systems in a controlled test. Use safe test transactions and idempotent import/replay procedures; never risk duplicate live charges.
- Only then cut over. Deploy and verify redirects, submit the new sitemap, inspect key URLs in Search Console, and monitor 404s, indexing, rankings, revenue, and order exceptions daily during stabilization.
Passing this gate cannot guarantee unchanged rankings. It makes avoidable losses visible before they become a surprise. Google’s documentation also notes that temporary search fluctuation during a move is normal.
Which option would we choose for these three businesses?
A new D2C brand with a standard catalog and two-person team: Start with Shopify unless a concrete requirement rules it out. Spend scarce effort on merchandising, product content, measurement, and customer service. Custom architecture is unlikely to be the highest-return first investment.
A publisher-led brand already strong on WordPress: Evaluate WooCommerce when content workflow and URL/content control are central and the team can fund reliable hosting, updates, security, and QA. Do not choose it because the core plugin is free.
A multi-vendor product with complex commissions, local payments, and unusual fulfillment: Model custom services or a composable architecture against a platform plus integrations. A custom component may solve the hard exception while retaining a proven commerce engine; “custom” need not mean rebuilding catalog, checkout, and payments from scratch.
Boxinall’s retail and e-commerce engineering scope spans storefronts, mobile commerce, integrations, and operational workflows. The commercially honest recommendation is the smallest architecture that reliably supports the differentiated part of the business.
Questions to bring to a platform assessment
Bring your current storefront URL, monthly order count, average order value, markets, required payment methods, existing apps/plugins, integration map, top organic landing pages, and the last three months of order exceptions. Then ask for four deliverables:
- A 36-month model with assumptions you can change, including payment-fee sensitivity.
- A commerce exception ledger ranking failure frequency and financial impact.
- A stay, improve, or switch recommendation with at least one lower-cost alternative.
- An SEO and operations cutover gate with an owner for every test.
That is a more useful output than a platform preference disguised as strategy. Talk to Boxinall about a commerce platform assessment grounded in your actual catalog, costs, and operating constraints.
Frequently asked questions
Is WooCommerce cheaper than Shopify over three years?
It can be, but the free core plugin does not settle the question. Compare hosting, extensions, development, security, maintenance, payment terms, and the time required to operate the store. The cheapest option changes with your requirements and team.
Does Shopify hurt SEO compared with WooCommerce?
Not inherently. Both can support discoverable commerce pages. SEO outcomes depend on content quality, site architecture, crawlable links, performance, structured data, and migration discipline. WooCommerce gives more implementation control; Shopify reduces some infrastructure work. Neither removes the need for an SEO owner.
When is custom e-commerce worth the cost?
When the high-value differentiator cannot be delivered acceptably through an existing platform or targeted extension, and its expected benefit covers build, maintenance, security, staffing, and exit risk. Validate the difficult workflow before funding an entire custom stack.
Can we move platforms without losing Google traffic?
There is no guarantee. A mapped, tested migration with relevant redirects, preserved content, consistent canonicals, crawlable navigation, and post-launch monitoring reduces avoidable risk. Expect some volatility and measure it against a pre-migration baseline.
Should we go headless to improve SEO and performance?
Not by default. Headless can help when multiple channels or presentation requirements justify it, but it adds frontend, rendering, integration, preview, and operational complexity. A well-built conventional storefront may be faster to ship and easier to maintain. Test the actual bottleneck first.
Final verdict
For most ordinary retail launches, buy the reliable commerce core and customize the parts customers notice. For content-heavy stores with a capable WordPress team, WooCommerce can be a strong fit. For unusual commerce operations, build only the differentiated capability you can justify with evidence.
The best platform is not the one with the longest feature list. It is the one that handles your expensive exceptions, protects your search equity, and leaves you with an operation you can afford to run for the next three years.
