The short answer
The cost of a professional eCommerce website is not determined by product count or platform alone. It reflects data quality, templates, checkout, payments and shipping, integrations, content migration, testing and responsibility after launch. A useful proposal turns those needs into clear deliverables, exclusions and acceptance criteria.
Sources reviewed: 13 September 2026. This guide explains cost variables; it is not a price list or financial, legal or tax advice. Examples are illustrative.
1. Why two stores with the same product count can have very different costs
A store with 500 simple products, clean images and an import-ready file may require less work than one with 80 products that have variants, technical attributes, customer-specific prices and a warehouse connection. Product count is one signal. The real question is how many rules must be designed, implemented and tested.
Firstidea’s central eCommerce development service treats the store as both a buying experience and an operational system. A proposal therefore covers more than customer-facing screens. It also needs to explain how stock changes, how orders reach the team and what happens when a payment, shipment or return leaves the ideal path.
2. A reliable scope starts with five maps
Before asking for a price, describe five areas: catalogue, buying experience, platform, integrations and operational acceptance. You do not need to write a technical specification. You do need to know what you sell, who buys it, which systems the business uses and which steps must not fail.
| Area | What to map | Example cost variable |
|---|---|---|
| Catalogue | Products, variants, categories, filters, content | Data cleaning and field mapping |
| Purchase | Product page, cart, checkout, account, returns | Custom UX and checkout rules |
| Platform | WooCommerce, OpenCart or custom foundation | Existing system, extensions and technical debt |
| Connections | ERP, CRM, courier, payments, feeds | APIs, sync jobs, logs and exceptions |
| Acceptance | Devices, order scenarios, SEO, analytics | QA coverage and support period |
This map gives two suppliers a chance to price the same project. Without shared scope, a lower quote may simply leave more work with the client or postpone it until later.
3. The catalogue costs more when product data is not ready
The work is not the same when products come from an organised ERP and when they are spread across spreadsheets, an old store and image folders. Categories, attributes, filters, variants, identifiers, availability, prices and product relationships all need an agreed structure.
Official WooCommerce documentation shows that even a standard product can include inventory, weight, dimensions, shipping class, linked products and other settings. Review the product editor fields. The more of this information that must be cleaned or created, the more the project becomes a data and content programme.
Define who supplies photography, descriptions and translations, who repairs source data and how many review rounds are included. “We will upload the products” is not a sufficient deliverable.
4. Custom UX is not measured by page count
An eCommerce website may use a small number of templates but still contain many states: available or out-of-stock products, size selection, personalisation, free shipping thresholds, B2B users with negotiated prices or checkout with store collection. Every state needs content, design and testing.
Product pages, filters and checkout directly influence purchase decisions. Custom design costs more than adapting a ready-made theme because it covers information architecture, responsive behaviour, accessibility, states and iterations. It is not automatically better; its value comes from solving real catalogue and customer needs.
5. WooCommerce, OpenCart or custom: licence cost is not total cost
An open-source platform may have no initial core licence fee, while the project still requires design, development, hosting, extensions, integrations, updates and support. Compare cost over time rather than stopping at launch day.
WooCommerce development is often suitable when content and commerce belong in WordPress. OpenCart development fits projects focused on catalogue and order operations. B2B and specialist processes may require custom eCommerce architecture. Our WooCommerce or OpenCart guide helps teams compare the decision beyond initial installation.
6. Payments, delivery and commercial rules change the project
Core store configuration includes selling locations, taxes, shipping, payments, accounts, privacy and emails. The official WooCommerce settings overview illustrates how many decisions exist before any custom feature is added.
A proposal should name the payment gateways, cash-on-delivery rules, instalments, shipping zones, lockers, collection options, courier connections and status notifications. A line saying “payments and courier integration” does not establish whether sandbox tests, refunds, failed transactions, labels or split shipments are covered.
7. ERP, XML and feeds need specification and monitoring
An integration is not a simple import button. The team must define which system owns the product, price, stock and order, how often data synchronises and how errors or incomplete records are handled.
The guide to connecting an eCommerce store with ERP or XML explains the main data flows and controls. Firstidea’s ERP, XML and API integration service focuses on real operational responsibility. Ask a proposal to specify endpoints or feeds, direction, frequency, logs, alerts, retries and a manual recovery process.
8. Migration and SEO protection are a separate workstream
If a store already exists, migration involves more than products and customers. It needs a URL inventory, category and product mapping, metadata, images, orders, accounts, redirects and post-migration checks. Not every record moves in the same way, especially when the data model changes.
Google explains that navigation and internal links help it understand an eCommerce site’s structure. Categories should lead to subcategories and products through real links. Google’s eCommerce structure guidance. Firstidea’s technical SEO guide for eCommerce covers further requirements for a migration scope.
9. QA, launch and stabilisation should be visible in the price
A store may look finished and still fail during a real purchase. QA should cover mobile and desktop, browsers, search, filters, variants, coupons, taxes, payments, shipping, emails, cancellation and refunds. Integrations also need scenarios for delays, duplicates and temporary outages.
Ask who accepts each scenario, what will be fixed before release, how long stabilisation lasts and when a request becomes new development. Team training and operating documentation reduce cost and uncertainty after launch.
10. Calculate total cost of ownership, not only build cost
The first year may include hosting, domains, paid extensions, payment fees, email services, monitoring, backups, security, technical support, content, SEO and marketing. Some costs are fixed, some recur annually and others scale with usage or revenue.
Build a three-year view with three columns: initial implementation, predictable recurring costs and variable costs. Add an owner for each service and state what happens if the supplier relationship ends. This exposes inexpensive starting points that rely on costly manual work or unclear vendor dependency.
11. How to compare two eCommerce development proposals
Compare proposals line by line rather than by total alone. Each quote should distinguish what is included, what the client supplies, what is excluded and how work will be accepted. If migration, product content or QA is absent, do not assume it is included.
| Comparison question | What you want to see |
|---|---|
| What is the exact scope? | Templates, functions, content, integrations and languages |
| Who owns each responsibility? | Named inputs, approvals and owners |
| How is work accepted? | QA scenarios and measurable completion criteria |
| Which costs recur? | Hosting, licences, monitoring and support |
| What happens after launch? | Stabilisation, SLA or a process for new work |
12. When it makes sense to phase the project
Phased delivery helps when scope is large or source data is uncertain. An initial phase can cover discovery, taxonomy, a data sample and checkout prototype. The next can deliver the core B2C catalogue, with a later phase adding B2B, international markets or advanced automation.
Every phase needs operational value and clear boundaries. Launching half a checkout or an integration without monitoring is not a useful phase. The aim is for each stage to be testable, deliverable and capable of informing the next decision.
Checklist before requesting a proposal
- Record product types, variants, languages and data sources.
- Describe B2C, B2B, subscription or other commercial rules.
- List payments, couriers, countries, returns and collection options.
- Share ERP, XML, API or legacy catalogue samples before pricing is fixed.
- Agree who creates copy, photography and translations.
- Request a migration plan, SEO checks, analytics and real test orders.
- Document recurring costs, support, ownership and exit arrangements.
- Compare deliverables and acceptance criteria, not totals alone.
Frequently asked questions
Can a store be priced from product count alone?
Not reliably. Product count helps, but variants, data quality, filters, languages, integrations and selling rules can change the effort substantially.
Is WooCommerce cheaper because it is open source?
Its core has no licence fee, but design, development, hosting, extensions, security, maintenance and support still cost money. Total cost of ownership is the useful comparison.
Should product entry be included in the quote?
It should be stated explicitly: how many products, which source, which fields, who cleans the data and who approves the result.
How much does custom design affect cost?
It depends on templates, states and design rounds. Custom UX with research, responsive states and usability checks requires more work than adapting a ready-made theme.
Are ERP and courier connections part of a standard build?
Not automatically. Each integration needs a defined scope for data, direction, frequency, authentication, monitoring, exceptions and tests.
Should SEO have a budget during development?
Yes, at least for URL architecture, crawlable navigation, metadata templates, structured data, migration redirects where relevant, performance and indexability checks. Continuous content strategy can be a separate workstream.
Which recurring costs should I expect?
Typically hosting, domains, extensions, backups, monitoring, security, technical support and third-party services. Payments, messaging and automation may charge by usage.
Is it safe to launch an MVP store?
Yes, if the first phase completes a real purchase journey and core order operation. Payments, shipping, security and critical QA should not remain incomplete.
How do I know whether two proposals are comparable?
They should describe the same functions, data, integrations, responsibilities, deliverables, exclusions, timeline, QA and support. The total alone is not enough.
What is the first step towards a specific quote?
A short discovery using a catalogue sample, commercial rules, current systems and objectives. This supports a scope with fewer assumptions and clearer boundaries.
A good proposal makes the store’s real operation visible
The useful question is not “how much is a website with products?” It is which buying experience and daily operation the system must support. When catalogue, checkout, integrations, migration, QA and support are explicit, the cost becomes understandable and proposals become comparable.
If you are planning a new store or replacing an existing one, collect a product sample, the essential flows and the systems that must connect. You can then discuss a specific eCommerce project with Firstidea.