Open Source Ecommerce Is Not Free: A Practical Total-Cost Model

Why a free licence does not mean a free store

WooCommerce, Magento Open Source, PrestaShop and Shopware ship under licences that grant free commercial use, modification and resale with no fee gate to remove. WooCommerce inherits GPLv3 from WordPress core (opens in a new tab); Magento Open Source uses the Open Software License 3.0 (opens in a new tab); PrestaShop’s core is OSL-3.0 with modules under AFL-3.0 (Academic Free License 3.0); Shopware 6’s core is MIT. None of them charge to unlock functionality.

nopCommerce is the exception, and it gets its own section below — its licence carries an attribution obligation the other four don’t have.

“Free” licence answers one line of a much longer budget. Running any of these five platforms in production means paying for hosting, extensions, maintenance and upgrade labour, PCI compliance, and the staff to keep all of that patched. This article treats those as six separate line items — licence/attribution, hosting, extensions, maintenance/upgrades, security/compliance, staffing — and prices each one independently.

flowchart LR
    A[Free / permissive licence] -->|covers| B[Software acquisition cost]
    A -.->|does not cover| C[Hosting]
    A -.->|does not cover| D[Extensions & modules]
    A -.->|does not cover| E[Maintenance & upgrades]
    A -.->|does not cover| F[PCI / security compliance]
    A -.->|does not cover| G[Staffing]

The common failure pattern is a project budget with a single “$0 — platform” line. Six months later, the actual spend across hosting, extensions and a contractor patching security releases runs to several thousand dollars a month, and nothing on the original budget predicted where it came from.

You should now see: why “free licence” and “free to operate” are different claims, and the six categories this article uses to price the difference.

Compare the licence terms across five open source platforms

Read the licence from the project’s own repository, not from marketing copy — the difference matters the first time a client asks whether a “Powered by” link is negotiable.

Shopware’s shift matters if the evaluation is based on old information: Shopware 6’s core dropped the AGPLv3 dual-license model that Shopware 5 used, which required publishing source changes under the same copyleft terms. The current core ships MIT instead.

nopCommerce is the one platform here where the licence itself is a budget line. The “Powered by nopCommerce” link is mandatory on every UI screen unless the store buys a separately priced copyright-removal key. Treat that key as a real cost if the client won’t accept the attribution link, not as an afterthought.

The recurring pitfall is a finished store that ships with an unagreed attribution link, traced back to the licence being read from a marketing page instead of the LICENSE file in the actual repository. Read the file before quoting a build.

You should now see: the exact licence obligation for a given platform, and whether attribution removal is a real line item to budget.

Price hosting from unmanaged compute to managed WordPress

Hosting cost is a function of traffic and site complexity, not which of the five platforms was chosen. A Magento store and a WooCommerce store at the same traffic level land in the same hosting bracket; the platform name on the box doesn’t change the bill.

DigitalOcean’s Basic Droplet tier (opens in a new tab) runs from $4/month (512 MiB RAM, 10 GB SSD) up to $96/month (16 GiB RAM, 320 GB SSD). That price buys the virtual machine only — no backups, patch management, WAF (web application firewall) or on-call response at any tier.

WP Engine’s Essential-tier managed WordPress hosting (opens in a new tab) — the direct WooCommerce use case — runs from $30/month for one site at 25,000 monthly visits (Startup) up to $276/month for 30 sites at 400,000 monthly visits (Scale). WP Engine states these are first-year promotional prices for new customers on annual billing, not a flat ongoing rate.

The gap between the two numbers is the labour the merchant no longer does themselves. Unmanaged compute leaves patching, backups, a WAF and on-call to the reader, either as their own time or as a separate line in the maintenance and staffing sections below. Managed hosting folds a chunk of that labour into the sticker price, which is why comparable compute costs more per month there.

You should now see: where expected traffic and site count land on both an unmanaged and a managed price curve.

Add extension and module costs before they compound

WooCommerce’s own pricing page (opens in a new tab) lists individual extensions at $29 to $299 a year each. A store that needs several commonly bundled capabilities — subscriptions, memberships, bookings, advanced shipping — can end up spending more per year on extensions alone than on hosting.

That cost is recurring, not one-time. A $600-a-year extension stack in year one is $600 again in year two, and again in year three; a budget that prices extensions as a single upfront figure understates every year after the first.

The same open-marketplace dynamic — a free core plus a paid ecosystem of add-ons — applies to Magento, PrestaShop and Shopware, even though the anchor numbers above come specifically from WooCommerce’s published page.

List the extensions the store actually needs, multiply by the $29–299/year range, and carry the total into the worksheet in the last section, before treating “extensions” as a rounding error next to hosting.

You should now see: a realistic annual extension budget, built from the store’s actual feature list rather than a guess.

Separate PCI compliance cost from the platform decision

PCI DSS (Payment Card Industry Data Security Standard) compliance cost tracks business size and checkout architecture, not which open source platform runs the storefront. Stripe’s published guidance (opens in a new tab) puts it at roughly $1,000–$10,000/year for small businesses, $10,000–$50,000/year for midsize companies, and $50,000–$250,000/year for large enterprises.

That cost exists whether the storefront runs WooCommerce, Magento Open Source or nopCommerce. Swapping platforms doesn’t move this bill; swapping checkout architecture does.

flowchart TD
    A[Checkout design] --> B{Does cardholder data touch the merchant's own servers?}
    B -->|No - hosted or redirect checkout| C[Cheapest SAQ tier]
    B -->|Yes - custom checkout on own infra| D[Higher SAQ tier, wider scope, higher cost]

Routing cardholder data through the merchant’s own servers instead of a hosted or redirect checkout moves the store off the cheapest self-assessment questionnaire (SAQ) tier defined by the PCI Security Standards Council (opens in a new tab) and onto a materially more expensive one. That single design decision can be the difference between the bottom and the middle of Stripe’s published bands.

Keep cardholder data off the merchant’s own infrastructure — a hosted field or a redirect-based checkout — and the store stays on the cheapest self-assessment tier by design, not by luck.

You should now see: which compliance cost band the store’s size falls into, and which checkout architecture keeps it on the cheapest tier.

Budget the maintenance and upgrade labour line

Someone has to apply security patches and run version upgrades, and that person’s time has a market rate. The US Bureau of Labor Statistics (opens in a new tab) puts the median annual wage for web developers at $90,930 (May 2024), with the lowest 10 percent under $48,560 and the highest 10 percent over $162,870.

Treat that figure as a sizing reference for in-house or contractor patching capacity, not as a direct platform cost. The actual maintenance bill depends on how many hours a month the platform’s release and security-bulletin cadence demands, multiplied by an hourly rate somewhere in that wage band.

sequenceDiagram
    participant V as Vendor
    participant M as Maintainer
    participant S as Store
    V->>M: Security bulletin published
    Note over M: Maintainer has left, role never backfilled
    M--xS: Patch not applied
    Note over S: Vulnerability sits unpatched for weeks

The failure pattern is specific and recurring: the one person who knew how to run upgrades leaves, and a critical vulnerability sits unpatched for weeks because maintenance was never priced as a recurring role in the first place.

Convert the platform’s actual patch and upgrade cadence into a fractional-FTE (full-time equivalent) or contractor-hours-per-month estimate, and put it in the worksheet — not into an unstated assumption that “someone will handle it.”

You should now see: an estimated monthly staffing cost, derived from the platform’s patch cadence and the wage bands above.

Spot open-core pricing before it gates a launch requirement

Open-core vendors differ from plain open source in one structural way: specific production features are deliberately withheld from the free tier and sold as a paid plan. Shopware’s published pricing (opens in a new tab) starts Rise from EUR 600/month and Evolve from EUR 2,400/month, each gating features such as B2B components, advanced search and dynamic access.

Shopware’s top Beyond tier is quote-based with no published price, tied to gross merchandise value. Adobe Commerce (opens in a new tab), built on the same Magento codebase as the free Open Source edition, is also quote-based with no published price at all.

flowchart TD
    A[Proof of concept on free tier] --> B{Does the launch roadmap need a gated feature?}
    B -->|No| C[Free tier remains viable]
    B -->|Yes - B2B quoting, advanced search, multi-inventory| D[Paid tier or enterprise quote required]

The pitfall follows a predictable shape: a proof of concept runs cleanly on the free tier, then a launch requirement — B2B quoting, advanced search, multi-inventory — turns out to need the paid tier or an undisclosed enterprise quote. By then the store is already built on the free edition’s assumptions.

Check the vendor’s feature-gating list against the store’s actual roadmap before treating the free tier as a long-term plan — not after the proof of concept has already shaped the architecture.

You should now see: whether the store’s required feature list is covered by the free tier, or whether it lands on a gated feature that changes the budget.

Build a six-category worksheet and compare it against Shopify

The six categories above sum into one monthly figure: licence/attribution, hosting, extensions (annualised and divided by twelve), maintenance/upgrades, security/compliance (amortised monthly), and staffing. The worked example below is illustrative only — a hypothetical small store, not a prediction of any real store’s bill.

Category                                    Monthly (illustrative)
----------------------------------------------------------------
Licence / attribution                                        $0
Hosting (managed, mid traffic)                              $110
Extensions (annualised, ~$600/yr stack)                      $50
Maintenance / upgrades (fractional contractor)               $300
Security / compliance (PCI, small-business band, amortised)  $150
Staffing (store operations, fractional)                      $600
----------------------------------------------------------------
Monthly self-hosted TCO                                    $1,210

The staffing line here is store operations — order processing, catalogue upkeep, customer support — kept separate from the developer maintenance line above it, since they’re usually different people at different rates.

Look up the SaaS side yourself rather than taking a number from an article, including this one. Shopify’s pricing page (opens in a new tab) serves prices in the visitor’s local currency based on IP address, and a ?country=us parameter switches the page locale without switching the currency. Read from India on 28 July 2026, it quotes Basic at ₹1,994/month on monthly billing (₹1,499 on annual), Grow at ₹7,447 (₹5,599), Advanced at ₹30,164 (₹22,680), and Plus from ₹175,000/month.

The widely cited US figures — Basic $39, Grow $105, Advanced $399 — could not be confirmed from this location, so treat them as secondhand. That is not a footnote about method: it is the same trap as the rest of this article. A comparison built on a plan price you did not read, in a currency the vendor did not quote you, is exactly the kind of assumption that makes the “$0 platform” line look convincing.

The structural point survives whichever currency you price it in. A $0 “platform” line set against any real SaaS plan is an omission, not a comparison, and the illustrative $1,210 monthly total lands between the mid and upper tiers of Shopify’s range rather than below all of them. A free licence is not automatically cheaper once every category is filled in.

Re-run the worksheet with the store’s own traffic, extension list and compliance tier rather than reusing the numbers above.

You should now see: a worksheet template with all six categories present, ready to be repopulated with real numbers to compare against a SaaS quote.

What this cost model does not cover

No number here is a measured operating cost. Every figure is a published price or a wage statistic read at one point in time, not an invoice from a store this article has run for a year. A real TCO comes from your own hosting bills, extension renewals and contractor hours; this model tells you which lines to look for, not what they will say.

Three specific gaps worth knowing before you lean on anything above:

• Shopify’s USD tiers are secondhand. Covered above: the vendor prices by IP, so the dollar figures could not be read from where this was written.
• Adobe Commerce has no published price at all. Its pricing page did not load during this research, and Adobe quotes rather than lists. Any Adobe Commerce range you find, including the six-figure ones commonly cited, is a consultancy estimate and not a vendor figure — check that distinction before it enters a budget.
• WP Engine’s $30–$276 range is promotional. WP Engine’s own plans page marks it as first-year pricing for new customers on annual billing. Year two is the number that matters for a TCO model, and it is not the one on the page.

Verify each price against the vendor’s own page on the day you build your budget. Prices in an article age badly, and a cost model built on stale figures fails in the same way as one built on no figures.

This model doesn’t price migration cost, custom development, theme or design work, or multi-region tax compliance beyond PCI. Any one of those can exceed everything summed in the worksheet above, depending on scope.

Version-specific figures — Shopware’s current patch line, PrestaShop’s exact release date — move on a rolling basis. Reconfirm them on Shopware’s changelog (opens in a new tab) and PrestaShop’s version page (opens in a new tab) rather than trusting this snapshot.

The framework is a starting worksheet, not a substitute for a vendor quote or a signed hosting contract. Use it to ask the right questions before either, not to skip them.

You should now see: exactly which numbers in this framework need re-verification before they go into a real budget decision.