Ecommerce cost: Shopify, WooCommerce and custom builds

Key takeaways

• The platform subscription does not represent the store’s total cost.
• A fair comparison includes migration, maintenance, fees and staff hours.
• In B2B, price lists and ERP integration can change which solution offers the best value.
• Development estimates need to be justified with tasks, hours and acceptance criteria.
• The marketing budget remains separate from the technical and operational cost of ecommerce.

When I put together a budget, I start with what the business needs to sell and manage. A catalogue with direct purchasing and a portal with restricted pricing may look similar on screen, but they require different work behind the scenes. Choosing on entry price alone means comparing different things.

If every quote includes different tasks, you need an agreed scope before choosing a platform. That is where I would start when designing and developing your ecommerce store: turn commercial needs into testable requirements, then assign a cost to each block.

What makes up the total cost of an ecommerce store?#

The total cost includes what you pay to build the store and what you spend to keep it running. I always separate the initial investment from recurring costs and people’s time.

Total cost of ownership is the sum of the costs required to build, use and maintain a solution over a defined period. Often called TCO, it is calculated here over 36 months.

The formula I use is: initial investment + recurring costs over the period + payment processing fees + internal work. I exclude stock purchases, warehousing, packaging, shipping, advertising and ongoing content production. These belong in the channel’s profit and loss account, but they do not help isolate the comparison between technical solutions.

How much does Shopify cost, including plans, themes, apps and development?#

Shopify needs to be assessed as a subscription plus setup, customisation and additional services. I would consider it when the sales process can stay close to the platform’s standard approach.

Among the prices published by Shopify, Basic is listed at €19 per month with annual billing in the official Shopify guide, while Grow and Advanced are listed at €56 and €289 per month respectively in the Shopify cost guide.

For month-to-month billing, Shopify publishes prices of €27 for Basic, €74 for Grow and €384 for Advanced in its shipping services comparison. The quote should specify monthly or annual billing: a monthly equivalent with an annual commitment is not a month-to-month contract.

Hosting, an SSL certificate to protect the connection and free themes are included, according to the official Shopify description. That does not remove the design work: choosing a theme does not mean your categories, product pages, shipping and purchase journey are already organised.

For staff access, Basic includes no additional staff accounts, Grow includes 5 and Advanced 15, according to the official Shopify plan comparison. I would not share the owner’s login to save on the plan. First, I would establish who needs to work in the store.

Introductory promotions do not enter my multi-year calculations. Even when an introductory offer is available, I prefer to assess the standard cost, specifying the currency, billing frequency, applicable taxes and contract terms in the quote.

Does B2B necessarily require Shopify Plus?

No: Shopify states that B2B features are included in Basic, Grow, Advanced and Plus. However, it reserves certain capabilities for Plus, including catalogues assigned to individual companies for customer-specific pricing, as explained on the official Shopify B2B page.

The plan comparison lists up to 3 B2B catalogues for Basic, Grow and Advanced, versus unlimited catalogues for Plus, in the Shopify feature comparison. For me, the useful question is therefore not whether the platform supports B2B, but whether it represents your exact commercial rules without expensive adaptations.

How much does WooCommerce cost if the core software is free?#

Free software does not make the project free: infrastructure, configuration, development and maintenance remain. I would assess WooCommerce when the freedom to customise justifies taking more direct technical responsibility.

WooCommerce states that its core software is free, with no monthly platform subscription or revenue share, on its official pricing page. Hosting, the service that houses the store, and add-ons still need separate budgets.

For business features, one example is B2B Pricing for WooCommerce. The product documents role-based pricing, price visibility and registration approval, but excludes credit and deferred payment workflows from its scope, according to the official extension page. I would not treat it as a complete, ready-made business portal: it covers a specific set of needs.

For each extension, I would ask for an itemised list covering the licence, renewal, permitted stores and support. In the budgets below, I use a hypothetical allowance for these components, not the price of a specific product. The final list depends on the requirements.

Are low-cost hosting and maintenance the same thing?

No. As an infrastructure reference, OVHcloud publishes an introductory price for Performance of €6.99 plus VAT per month for 12 months, renewing at €19.99 plus VAT per month, on its official hosting page. The same plan lists 500 GB of storage and a database with 512 MB of RAM, according to the OVHcloud specifications. These are infrastructure specifications, not a guarantee of your store’s performance.

I would not choose hosting on storage space alone. I would ask for a separate test environment, known as staging, backup terms, a restore procedure and responsibility for updates. I do not consider these tasks included until they are written into the contract. The same applies to malware removal and fixing incompatibilities.

When budgeting for ecommerce security and backups, I would distinguish saving data from the work needed to get running again after a problem. A backup that nobody knows how to restore is not a complete operating procedure.

When do you need a custom ecommerce store, and how do you estimate the cost?#

Custom development makes sense when an important requirement has no sustainable solution within the available platforms. I would not choose it just for a different visual design: first, I would isolate the part that is genuinely distinctive.

Here, by custom development I mean an application designed with dedicated logic and interfaces, rather than a modified theme. This approach can still use existing components: it does not mean rewriting every element of the system.

My estimate would start with separate blocks: catalogue, search, accounts, pricing, orders, administration, integrations, testing, deployment and documentation. For each, I would define a testable outcome and a workload. A total without this breakdown is hard to assess and even harder to control during the project.

First, I would also compare an all-in-one platform with an integrated stack, meaning a set of connected tools. Often, custom work can be limited to an integration or a commercial feature, without building the entire store from scratch.

Where do this article’s development estimates come from?

The scenario figures are budgeting exercises I have put together, not market averages, supplier quotes or results from real projects. I use a purely hypothetical rate of €60 per hour, the same for every solution, to make the relationship between planned work and investment clear.

This is not my price list. An actual proposal should consider data quality, integration complexity, responsibilities, required skills and project risk. I prefer a justified estimate to an apparently precise price with no defined scope.

How much do payments, maintenance and internal operations add?#

Payment fees depend on the amounts processed and methods used; maintenance depends on agreed responsibilities; internal operations depend on the work left to people. I calculate them separately because each has different cost controls.

As payment references, Shopify publishes an online card fee for Basic of 1.9% plus €0.25 per transaction in its official cost guide; Stripe lists 1.5% plus €0.25 for standard European Economic Area cards in its Italian pricing schedule. These are not universal rates for every card or contract.

If you use an external provider instead of Shopify Payments, Shopify lists possible additional fees. The table shows 2% for Basic, 1% for Grow and 0.6% for Advanced in the official Shopify comparison. Before choosing a gateway, the service that handles online payments, I would ask for the total cost applicable to the specific payment method.

The working formula is: amount actually processed × percentage + number of transactions × fixed fee. I would not start with accounting revenue: the calculation needs the amounts on which the provider charges its fee.

Maintenance must distinguish corrective work from new features. Internal operations cover catalogue updates, checking anomalies, customer support and order oversight. In the examples, I keep these hours the same across platforms: assigning an unproven staffing saving to one solution would distort the comparison.

How much does a standard B2C ecommerce store cost over three years?#

In the following hypothetical scenario, the total cost is €42,060 with Shopify, €45,240 with WooCommerce and €63,000 with custom development. These are model outputs, not market prices or spending promises.

Shared requirements and assumptions

Imagine a B2C store, selling to end consumers, with 500 products, one language, sales in Italy, a standard purchase process and no ERP connection. I assume 300 orders per month, each with €80 actually collected, all paid using cards eligible for the rates considered: 10,800 transactions and €864,000 processed over the period.

For Shopify, I assume one internal administrator and the Basic plan. For every solution, I allow for already organised data, images and text supplied by the business, one initial import, essential analytics setup and training. I exclude product subscriptions, configurators and special commercial rules.

All modelled expenses exclude any applicable VAT. Order amounts, however, represent sums processed, not revenue net of tax. I do not account for price increases, inflation, financing, refunds or chargebacks: these should be added if relevant to the business.

How I build the calculation

1. I estimate build and testing work at 80 hours for Shopify, 100 for WooCommerce and 300 for custom development.
2. I add 20 hours of migration for each solution. At the stated hypothetical rate, startup costs become €6,000, €7,200 and €19,200 respectively.
3. I set aside €30 per month for Shopify apps, €20 for WooCommerce extensions and nothing for additional licences in the custom build; the corresponding features are included in the assumed development work.
4. I allow for 2, 4 and 6 hours of maintenance per month respectively, costed at the same hypothetical rate.
5. I add infrastructure, domain, payment fees and 12 hours of internal work per month at a hypothetical cost to the business of €25 per hour.

To make the calculation repeatable, Shopify fees are 864,000 × 0.019 + 10,800 × 0.25; Stripe fees are 864,000 × 0.015 + 10,800 × 0.25. The reference rates are those for Shopify Basic and Stripe standard EEA cards, applied only to the stated assumptions.

In this exercise, I would choose Shopify over a custom build: no requirement emerges that would justify dedicated development. The comparison with WooCommerce remains sensitive to the actual maintenance workload and payment fees. Changing those assumptions may also change the cost ranking.

How much does an ERP-integrated B2B ecommerce store cost over three years?#

In the second hypothetical scenario, the total becomes €62,244 with Shopify, €69,960 with WooCommerce and €96,240 with a custom build. The difference from B2C comes from the commercial process and integration, not from calling the store “B2B”.

A precise commercial scope

Imagine a distributor with 2,000 products, 200 authorised companies and 3 customer groups with restricted price lists. Customer roles are purchasing groups with different terms, not a hierarchy of requesters and approvers. I assume one portal administrator: the rest of the staff work in the ERP system.

The ERP system controls prices and stock availability; the store receives these data and sends orders back. I assume periodic updates, available technical documentation and no extra cost to access the ERP system. That last assumption needs confirmation from its supplier.

For Shopify, the model applies only if the customer groups can be represented using the plan’s catalogues, without requiring individual assignments reserved for Plus. I would have a process test signed off before issuing the final quote. If it fails, the budget needs reworking, rather than adding a small generic contingency line.

To define this scope, I would use a list of B2B ecommerce requirements. The distinction that matters is between rules shared by customer groups and exceptions negotiated with each individual company.

Integration: API availability and the work required

An API is an interface that allows two programs to exchange data. WooCommerce documents reading and writing orders, products and customers through its REST API in the official developer documentation. This provides a technical connection; it does not automatically resolve product codes, duplicates, errors or reconciliation.

In the project, I would ask for agreement on which system takes precedence when data conflict, how failed transfers are recovered and who receives alerts. For me, an integration is ready when it can also handle things going wrong.

Financial assumptions and result

I assume 100 monthly orders with €500 actually collected per order: 20% of orders and amounts are paid by card, with the rest paid by bank transfer. Over the period, this means 720 card transactions and €360,000 processed by card. I assume zero marginal cost for bank transfers under the hypothetical banking contract; this is not a reference bank rate.

I allow 180 build hours for Shopify, 200 for WooCommerce and 500 for the custom build, adding 100 hours of integration and 40 of migration to each. The rate remains the hypothetical €60 per hour. For internal staff, I allow 20 hours per month at a hypothetical cost to the business of €30 per hour.

This table does not cover credit limits, multi-level approvals, complex individual price lists, sales agents or configurators. If needed, these become requirements to estimate. B2B payments and deferred payment terms also need to be described as workflows: displaying a due date to a customer and managing trade credit are not the same task.

I would not read the result as an automatic win for the cheapest solution. First, I would eliminate options that fail the process test. Only then would I compare the totals for those remaining.

How do you choose a solution and compare quotes?#

The best-value solution meets the necessary requirements at the lowest sustainable cost over the period. I would rule out incompatibilities first, then assess price, operational responsibilities and the ability to change supplier.

The document sent to suppliers should cover the catalogue and variants, markets, languages, commercial terms, payment methods, expected volumes, data to migrate, staff access and systems to connect. I would add real examples of straightforward and problematic orders, with personal data removed.

If running a multilingual ecommerce store is part of the plan, I would ask for a separate line for initial translation, review and content updates. Leaving it under a generic “internationalisation” item makes it hard to understand what you are buying.

Every proposal should distinguish startup costs, recurring costs, usage-based charges and exclusions. I would also ask who owns the domain, accounts and custom code, which data can be exported and what support is provided for a possible move to another supplier.

How to assess the risk of overruns

I have not added a general contingency to either model: the totals represent the stated scope, not a guaranteed spending cap. Before committing the budget, I would have separate estimates prepared for poor-quality data, incomplete ERP documentation and customisations still needing clarification.

The assumed maintenance does not fund new features. For these, I would request a separate enhancement budget, to be used after approval. That is more transparent than promising unlimited support without explaining what it means.

How to apply it in your business: first steps#

I would start with a shared document involving sales, administration and whoever will run the store. The intended outcome is not an immediate platform choice, but clear proposals based on the same scope.

1. Describe the sales process. Write down how a customer gains access, sees a price, orders and pays. This is complete when every important commercial exception has an example.
2. Prepare a data sample. Gather products, variants, images, customers and price lists. This is complete when a technical specialist can assess import quality without relying on general descriptions.
3. Define the integrations. For each data item, state the source, destination, frequency and responsible person. This is complete when error recovery also has an owner.
4. Build the cost spreadsheet. Separate startup costs, subscriptions, renewals, payments and staff. This is complete when every amount is classified as a published price, quote or assumption, and VAT treatment is explicit.
5. Have risky requirements demonstrated. In B2B, test access, price lists and order transfer to the ERP system. This is complete when the workflow works with representative data, rather than demonstration screens alone.
6. Compare proposals and responsibilities. Align exclusions, maintenance, deliverables and change management. This is complete when a price difference corresponds to an understandable difference in work or service.

Mistakes to avoid#

The most expensive mistakes often happen before development, when the scope remains implicit. I would avoid these in particular.

• Mistaking the subscription for the budget. The platform price does not automatically include setup, migration and day-to-day operations.
• Comparing promotional prices with renewals. An introductory saving does not describe normal spending or the contractual commitment.
• Writing only “ERP integration”. Without a data list and error handling, two suppliers may estimate very different work.
• Treating B2B as a discounted catalogue. Roles, price lists and individual terms need to be mapped before choosing the plan or extensions.
• Treating internal hours as free. Time absorbed by the store reduces capacity for other tasks, even when it generates no external invoice.
• Confusing maintenance with feature development. Fixing a problem and adding a feature are different assignments: they need separate funding and approval.