CodeKabir
On this page
Search for this and you will find confident price ranges that disagree with each other by a factor of twenty. They are not lying; they are answering different questions. An agency quoting for a brand with a photo shoot, a translation budget and an ERP integration is pricing a different project from a freelancer setting up a catalogue of forty products on an existing theme.
This article does not give you a number. It gives you the structure behind the number, so you can read a quote, see what is missing from it, and compare two proposals that look nothing alike.
The quick answer: what actually drives the price
Four things decide most of the cost, and none of them is the platform you pick. In rough order of impact:
- Integrations. Every system the store must talk to — ERP, accounting, stock, shipping, a marketplace — adds work that scales with how awkward the other side is.
- How far you sit from default behaviour. Standard checkout, standard pricing, standard shipping is cheap. Every rule that differs is development.
- Catalogue. Not the number of products, but how much structure they need: variants, options, per-customer pricing, and who writes the content.
- Design. A configured theme, a customised theme and a bespoke design are three different budgets.
Types of store, and why the label matters less than you think
Labels like "small store" set expectations badly, because a forty-product store with unusual pricing rules can cost more than a four-thousand-product store that sells the ordinary way. It is more useful to locate your project by what it has to do.
| Type | What it involves | Main cost driver |
|---|---|---|
| Catalogue store | Products, cart, checkout, standard shipping and payment | Catalogue preparation and design |
| Standard online store | The above, plus promotions, accounts, basic reporting | Breadth of configuration |
| Store with integrations | Orders, stock or customers synchronised with other systems | The other system's API, and who owns the rules |
| B2B store | Customer groups, negotiated prices, quotes, payment terms | Pricing logic and access control |
| Marketplace or multi-vendor | Several sellers, commissions, payouts, moderation | Money flows, and the rules around them |
Who builds it: four routes
| Route | Works well when | Watch out for |
|---|---|---|
| Do it yourself on a hosted platform | Standard needs, small catalogue, tight budget | Your time is a real cost, and it is the one nobody counts |
| Freelance developer | Clear scope, direct communication, specialised work | Availability, holidays, and what happens if they stop |
| Agency | Several skills at once, strict deadlines, long projects | Higher overhead; ask who actually does the work |
| Custom build | Rules no existing platform supports | Longest and most expensive route; justified less often than it is chosen |
These are not quality tiers. A freelancer is not automatically cheaper once you count the project management you end up doing yourself, and an agency is not automatically safer if the work is subcontracted onward. Judge the route by how well it fits the project, not by the label.
What you pay for up front
- Discovery. Turning what you want into something that can be built and priced. Skipping it moves the cost later, with interest.
- Design. Theme configuration, theme customisation or bespoke design — and the mobile version, which is where most of the traffic is.
- Development. Everything the platform does not do out of the box.
- Product data. Photos, descriptions, variants, stock. Often the largest hidden line, and usually yours to do.
- Payments. Provider account, verification, and testing in real conditions.
- Shipping. Rates, zones, carriers, and any connection to their systems.
- Integrations. Each connection to another system, priced individually.
- Testing and launch. Order journeys end to end, redirects from the old site, and the switch itself.
What you pay for every year afterwards
A store is not a purchase; it is a subscription to several things at once. The recurring side is where projects quietly go over budget, because it is rarely in the quote.
Platform fees are the one part you can check for yourself before talking to anybody, and they vary by country more than people expect. On Shopify's French pricing page, the entry plan was listed at €36 per month billed monthly, or €27 billed annually, with an online card rate of 2.1% + €0.30 — while the Canadian page listed CA$49 per month and 2.8% + 30¢ for the same tier. Both figures were checked on 31 October 2026 and will change; they are quoted here to show that the currency and country matter, not as a recommendation.
Self-hosted platforms such as WooCommerce or PrestaShop charge no subscription, but move those costs to hosting, extension licences and maintenance. Neither model is free; they bill different people.
- Hosting, domain and certificates, or a platform subscription.
- Extension and application licences, often renewed annually or monthly.
- Maintenance: updates, compatibility checks, backups you have actually restored once.
- Security: the real cost here is an abandoned component nobody is watching.
- Support: who answers when checkout breaks on a Saturday, and under what agreement.
- Improvements: the changes you will want in year two, which no launch budget includes.
A three-year calculation framework
Comparing quotes on the build price alone favours whoever left the most out. Put every proposal through the same three-year frame instead.
| Line | How to fill it | Common mistake |
|---|---|---|
| Build | The quoted figure, with its scope attached | Comparing two quotes whose scopes differ |
| Platform or hosting | Monthly cost × 36, in your currency | Using another country's published price |
| Licences | Annual renewals × 3 | Counting only year one |
| Transaction fees | Expected revenue × the applicable rate | Forgetting the extra fee some platforms add for third-party payment providers |
| Maintenance | An annual provision × 3 | Leaving the line empty, then paying it as emergencies |
| Changes | A realistic provision for year two and three | Assuming the site is finished at launch |
| Your own time | Hours × a real internal rate | Treating it as free because it is not invoiced |
Freelancer or agency: how to judge
Ask the same questions of both and compare the answers rather than the hourly rates.
- Who writes the code, and will I be talking to that person?
- What happens to the project if you are ill, or if we stop working together?
- Where does the code live, and is the repository mine?
- What is in scope, and what will be quoted separately?
- How are changes handled once we have started?
- What do you need from me, and by when? A silent client is a late project.
The last question matters more than it looks. Most delays in e-commerce projects come from content and decisions arriving late, not from the development itself.
The costs that are not in the quote
- Scope changes. The most common overrun. Agree early how changes are priced, so the conversation is routine rather than tense.
- Data migration. Products are manageable. Order history and customer accounts are harder, and often quoted separately or not at all.
- Integrations. Priced on the assumption the other system behaves. Undocumented APIs and missing test credentials are where estimates break.
- Third-party fees. Payment, shipping and application fees scale with your sales rather than with your project.
- Compliance. Tax rules, consent and privacy obligations depend on where you and your customers are. Confirm what applies to you.
- Training. Somebody has to run the store. An hour of handover is cheaper than a year of workarounds.
How to evaluate a quote
- Is the scope written as deliverables, or as a list of technologies?
- Is every integration named individually, with what happens if the other side is not ready?
- Who is responsible for product content, and is that stated?
- Are hosting, licences and maintenance listed, even when they are not the developer's invoice?
- Is there a redirect plan, if you already have a site with traffic?
- How is a change priced once work has started?
- Who owns the code and the data at the end, and in which repository?
- What is tested before launch, and who signs it off?
- What support exists after launch, for how long, and at what response time?
A quote that answers these is not necessarily the cheapest. It is the one that is least likely to grow by forty per cent halfway through, which is usually the number that matters.
Before you contact anyone
The single thing that improves both the price and its accuracy is a clear brief. It does not need to be long. What do you sell, how many products, how do customers pay and receive it, which systems must the store talk to, which rules are non-negotiable, and when does it have to be live.
With that, any competent developer can give you a meaningful estimate — and you can tell the difference between a quote built on your project and a quote built on an average. That applies whether the work ends up as a WooCommerce build, a PrestaShop build, or something on a hosted platform with a little custom work around the edges.
Planning an e-commerce website? Share your requirements and get a project-specific assessment.
Request a quote
