Ecommerce Website Development Cost in India (2026): Shopify, WooCommerce & Custom Stores

The price of an ecommerce website is set by what the store has to do, not by the platform’s name or the number of pages. Two stores that look almost identical on a phone can be quoted very differently, because one sells forty simple products with a flat delivery charge and the other sells sized, coloured and bundled items with zone-based shipping, stock held in a separate system and prices that change for wholesale buyers.

That is why a serious quote begins with questions rather than a number. How many products are there, and how different are they from each other? What does a customer have to choose before buying? Which payment methods and delivery options must checkout support? Where does stock live, and what has to happen after an order is placed? Each answer adds or removes real work, and a quote that skips those questions is estimating a store it has not seen.

This guide works through those decisions in the order a store is actually built, then compares Shopify, WooCommerce and a custom build as ways of delivering them. It deliberately avoids market averages. Ecommerce budgets vary so much by scope that an average says very little about your store; the drivers below tell you where your own project sits and which parts of it deserve the money.

Every online store, on any platform, is made of four layers: the catalogue, the experience, the checkout and the operations behind it. Cost accumulates in each of them, and a proposal that does not account for all four is usually missing one.

Catalogue: products and variants

The catalogue is what you sell and how it is modelled — products, variants, options, collections, attributes and the data attached to each. It is the foundation every other layer reads from, which is why a poorly modelled catalogue makes everything above it slower and more expensive to build.

Experience: design and discovery

The experience is what a shopper sees and uses: the home page, collection pages, product pages, search, filters, content and the mobile layout. Design depth and discovery features are the main variables, and they are also the most visible ones, which is why buyers tend to over-focus on them.

Checkout: payments and shipping

Checkout turns intent into an order. It covers cart behaviour, customer details, delivery options and rates, discount codes, taxes and the payment step. How much of it can be changed depends heavily on the platform, so checkout requirements should be written down before a platform is chosen, not after.

Operations: orders and integrations

Operations is everything that happens after payment: stock updates, order routing, notifications, returns, customer records and the connections into inventory, accounting, CRM, ERP, courier and marketplace systems. Shoppers never see this layer, and buyers underestimate it more often than any other.

Shopify, WooCommerce and a custom build sit alongside these layers rather than above them. They are three different ways of delivering the same four things, each with its own limits, its own way of being extended and its own running costs.

Catalogue shape affects cost more than catalogue size. A thousand products that share one structure can be quicker to build than eighty products that each behave differently, because the work lies in modelling the differences, not in counting rows.

The number and type of products

Simple physical products with one price and no choices are the cheapest to set up. Cost rises with every product type that needs its own template, fields or rules: made-to-order items, bundles and kits, digital downloads, gift cards, subscription products, items that need an age or prescription check, and items that cannot ship everywhere. Each type adds page logic, checkout rules and testing.

Volume matters mainly through data entry and migration. If products are imported cleanly from a spreadsheet or an existing store, a large catalogue is an import job with a verification step. If descriptions, specifications and images must be written, gathered or corrected by hand, volume quickly becomes the dominant cost in the project.

Collections and categories

Collections are how shoppers browse and how search engines understand the store. A flat set of a dozen collections is quick to set up. A layered structure — by category, by use, by occasion, by season — needs planning so that products land in the right places automatically, pages do not duplicate each other, and navigation stays usable on a small screen.

Automated collections built from product attributes take longer to set up than hand-picked ones, but they save your team work every time a product is added or retired. That trade-off belongs in scoping. Deciding it after launch usually means rebuilding the attribute structure while the store is live.

Variants and options

Variants are where catalogues quietly become expensive. A shirt in five sizes and four colours is twenty variants, each of which can carry its own stock, price, SKU and images. Add a fabric choice and the count multiplies again. Every platform has its own limits on how variants and options are structured, and a catalogue that goes beyond them needs a workaround, an app or custom development.

The difference between a variant and an option matters for cost. Size and colour usually change stock, so they belong as variants. Engraving text, gift wrap or a preferred delivery date do not change stock, so they are better captured as options. Getting this right keeps the catalogue from multiplying into combinations nobody can manage.

Product data quality

Clean product data is the cheapest improvement a buyer can make before asking for quotes. Consistent names, one SKU scheme, complete attributes, weights and dimensions for shipping, and image files named to match their products all reduce build time. Messy data does not disappear on a new platform. Someone has to fix it, and that time is billed whether or not it appeared in the original estimate.

Search and filters cost little on a small, simple catalogue and a great deal on a large or technical one. The deciding question is how a shopper narrows down to the right product, and whether the platform’s default tools can answer that question well.

Basic keyword search and a handful of filters for price, size and colour come with most themes and platforms. They are adequate when shoppers already know roughly what they want and the range is modest. Cost rises when filters depend on attributes that must first be structured — fit, material, skin type, compatibility, metal purity, pack size — because every product then needs that data filled in consistently and kept that way.

When default search stops being enough

Default search tends to struggle with misspellings, synonyms, regional terms and partial model numbers. Stores that sell technical parts, broad ranges or products people describe in many different words often need a dedicated search app or a custom search layer. That brings a recurring fee or a development cost, plus the configuration work of tuning results and deciding what appears first.

On a catalogue with deep attributes, list the ten most common ways customers actually ask for products — from sales calls, WhatsApp chats and support tickets — before deciding what to build. Discovery should be designed around those questions, not around whatever filters a theme happens to ship with.

Filters and search visibility

Filters also affect SEO. Every filter combination can generate a new URL, and without care a store produces large numbers of thin, near-identical pages that compete with its real collections. Deciding which filtered views deserve their own indexable page, and which should stay out of search, is structural work that belongs in the build rather than in a clean-up project later.

Design is usually the most visible variable in an ecommerce quote and one of the easiest to control. There are three levels of design depth, and the right one is the simplest level that still lets the store sell the way the brand needs to.

A theme applied well

A good theme, configured with the brand’s typography, colours, imagery and content, is the fastest route to a working store. Cost here is mostly setup, content and product entry. The limit is that the theme decides the layouts, so products that need to be explained, compared or configured can feel squeezed into a generic product page.

An extended theme

Extending a theme means keeping its foundations while adding custom sections, product page components, size guides, comparison blocks or campaign layouts. It suits brands with a standard catalogue that still need a few distinctive moments. Cost rises with each custom component, and ongoing maintenance has to allow for testing those components whenever the theme is updated.

Fully bespoke design

Bespoke design starts from the brand and the shopping journey rather than from a template. Every template — home, collection, product, cart, account, content — is designed and built to specification. It costs the most, and it is justified when the product needs a particular storytelling structure, when visual distinction is central to the positioning, or when an off-the-shelf theme would have to be fought at every turn.

Content and product photography

Content is a design cost that buyers often leave out of the budget. Product photographs on consistent backgrounds, lifestyle images, size and fit imagery, short videos, material or ingredient explanations and written product descriptions all need producing or improving. A well-designed store filled with inconsistent images still looks unfinished, and no amount of layout work hides it.

If the catalogue needs new writing or visual direction, scope product copy, photography briefs and page content as a named workstream with an owner and a deadline, rather than hoping the material arrives in time for launch.

Checkout cost depends less on how the page looks and more on the rules it must enforce and how much the platform lets you change. A straightforward checkout with cards, UPI and a flat delivery charge is configuration. A checkout that must validate pin codes, collect GST details from business buyers, restrict cash on delivery by order value or area, and apply customer-specific pricing is a development task.

How much of checkout you can change

Hosted platforms keep parts of checkout under their own control for security and consistency. According to Shopify’s help centre, merchants can brand checkout through its checkout editor and use apps on the thank-you and order status pages, while apps that customise the information, shipping and payment steps are limited to Shopify Plus. On WooCommerce, checkout is part of your WordPress site and can be changed through plugins or custom code, within your payment gateway’s rules. On a custom build, structure and fields are designed as needed, but the payment provider still governs the payment step itself.

The practical consequence is simple: write the checkout requirements first, then test them against the platform and plan you are considering. A requirement that needs a higher plan or custom work is a cost, and it is far cheaper to find it at scoping than in the week before launch.

Payment methods and gateways

Indian shoppers typically expect cards, UPI, wallets, net banking and, in many categories, cash on delivery. Which methods you can offer depends on the payment provider and its approval of your business, not only on the platform. Adding a second gateway, EMI, pay-later methods or cash on delivery rules adds setup and testing, and every provider has its own fees and settlement terms.

The payment decision has a platform cost as well. Shopify’s help centre states that its third-party transaction fees apply to orders processed through third-party and alternative payment gateways, separate from whatever the gateway itself charges, and directs merchants to its pricing page for the rates. Before budgeting, confirm which payment options are available to an Indian store on the plan you are considering and what each will cost per order.

Guest checkout and customer accounts

Guest checkout should usually be available, with an account offered after the first order rather than demanded before it. Basic accounts with order history and saved addresses are standard. Accounts add cost when they need more: wishlists, loyalty points, one-click reorders, store credit, trade approval or account data pulled from a CRM. Scope each account feature against a real customer need rather than a competitor’s feature list.

Taxes and invoices

Tax handling is configuration on a simple store and a real workstream on a complicated one. Decide whether prices are displayed inclusive of tax, how tax rates differ across your product lines, whether business buyers need to enter a GST number at checkout, and what an invoice must show and when it is generated. Confirm the detail with your accountant, then give the list to the build team. A store that produces invoices your accounts team has to redo by hand has only moved the work.

Shipping costs little to build when the rules are simple and a lot when they are not. A flat rate with free delivery above a threshold is a setting. Rates by weight, zone, pin code serviceability, product type or courier service are rules, and rules need data, configuration and often an integration.

Delivery rules the store must enforce

List every rule before scoping: which pin codes you serve, which products cannot ship to certain areas, whether heavy or fragile items carry separate rates, whether cash on delivery is restricted, and whether customers choose between standard and express services. A store should tell a customer that an address cannot be served before payment, not after, and that check has to be designed and built.

Courier integrations and order tracking

Connecting to a courier aggregator or shipping platform to create shipments, print labels and pull tracking updates is usually an app or integration cost rather than a design cost. The effort depends on what the courier’s system exposes and whether tracking updates must flow back into order status pages, emails and WhatsApp messages. A tracking page that customers can find without contacting support is worth scoping explicitly.

Returns and exchanges

Returns belong to fulfilment and are often scoped last. A clear policy page with manual processing costs almost nothing to build. A self-service return or exchange flow, with reasons, pickup booking, refunds or store credit and automatic stock updates, is a feature in its own right and should be priced as one.

Categories where products are sized, coloured and exchanged regularly, such as fashion and apparel stores, feel exchange logic most, so it deserves early attention in those projects rather than a place on the post-launch list.

Promotions are inexpensive when they match what the platform already supports and costly when the business relies on its own mechanics. Percentage and fixed-value codes, free shipping thresholds and simple automatic discounts are standard on the major platforms. Buy-two-get-one across collections, tiered bundles, first-order offers, stacked codes, loyalty redemption and creator-specific pricing often need apps, custom functions or development.

Ask the marketing team which campaigns they ran last year, and which they wanted to run but could not. That list is the promotions scope. A platform that cannot express a campaign the business depends on becomes a recurring cost, paid either in app fees or in manual workarounds every sale season.

Pricing rules that go beyond discounts

Some pricing is structural rather than promotional: wholesale price lists, slab pricing by quantity, price per metre or per gram, prices that move with a daily metal rate, or quote requests in place of a fixed price. These rules sit close to both the catalogue and the checkout, and they are among the strongest signals that a standard setup will need extending or replacing.

Jewellery shows this clearly: rate-linked pricing, certification details and high-consideration buying all change what the product page and checkout must carry, which is covered in more depth in our guide on how jewellery brands win online.

Integrations are the layer most likely to move a quote, because their cost depends on systems the store builder does not control. A store that manages its own stock is far simpler than one that must read stock from an ERP, push orders into accounting software and keep listings in step with marketplaces.

Inventory and a single source of truth

The first question is where stock truth lives. If the store is the stock record, inventory is configuration. If stock sits in a warehouse, POS or ERP system, the store needs a dependable sync so that it never sells what cannot be fulfilled. The effort depends on whether that system offers an API, a scheduled export or nothing usable, and on how often stock changes across channels.

ERP and accounting

Pushing orders, customers, tax details and invoices into an ERP or accounting system is common for established retailers. Ready-made connectors exist for some combinations; others need middleware or custom development. The scope depends on field mapping, what happens when a sync fails, and who is alerted when the two systems disagree. Error handling is the part most often left out of cheap quotes.

Order handling and team roles

Before any external system is connected, the store has to manage orders well on its own. That means clear order states, partial fulfilment when one item is out of stock, cancellations and refunds, notifications to customers and staff, and notes that stay with the order. Platforms cover the common cases. Split shipments, gift orders sent to another address, pre-orders and orders that need approval before dispatch add configuration or development.

Team access is part of the same conversation. Merchandising, content, fulfilment, support and owner-level access rarely need the same permissions, and a store where anyone who can edit a banner can also change delivery rules is a risk. Agree who needs to reach what during scoping, because retrofitting roles after launch is slower than setting them up once.

CRM, marketing and support tools

Connecting the store to a CRM, an email or WhatsApp marketing tool, or a helpdesk lets teams see order history alongside customer conversations. Many of these connections are app-based. Deeper ones, such as segmenting customers by what they bought or triggering follow-ups from order events, need configuration, testing and a clear decision about which system owns the customer record.

Once order and customer data are connected, that data can drive automated follow-ups and assisted support; our article on using AI across sales, support and retention looks at what that means for D2C teams in practice.

Marketplaces

Selling on marketplaces alongside your own site raises the need for shared stock, consistent product data and consolidated orders. Marketplace connectors and multichannel tools carry their own fees and rules. Decide early whether the website or another system is the master catalogue, because changing that decision later means rebuilding the sync.

Analytics and tracking

Analytics setup — ecommerce events, conversion tracking for ad platforms, consent handling and server-side tracking where needed — is a small line item that causes large problems when it is skipped or done loosely. Agree which events must be tracked, and verify each one on a test order before launch.

Shopify, WooCommerce and a custom build are implementation choices, not budget tiers. Each can produce a modest store or an expensive one depending on scope. What differs is how they launch, how far design and checkout can be changed, how they connect to other systems, what they cost to run and which kind of business they suit.

Shopify

Shopify is a hosted platform, so there is no server to manage and a store is quick to set up. Design starts from a theme, with custom theme work for anything the theme does not provide. Checkout is Shopify’s own and follows its rules; customising the information, shipping and payment steps with apps is reserved for Shopify Plus. Integrations come through the Shopify App Store and APIs. Running costs are the subscription and any paid apps, alongside payment fees and, where an external gateway is used, Shopify’s third-party transaction fees. It is the natural fit for standard retail catalogues sold in standard ways.

WooCommerce

WooCommerce turns a WordPress site into a store, and its core plugin is free to download. The site runs on WordPress hosting you arrange, so performance, security, updates and backups are your responsibility or your developer’s. Design comes from themes plus custom development, and checkout is flexible through plugins and code. Integrations come from plugins and custom code; paid extensions and themes from the WooCommerce Marketplace are bought as subscriptions that renew. Running costs are hosting, plugin renewals and maintenance. It suits content-led stores, particularly where the business already runs on WordPress.

A custom build

A custom build is designed and developed entirely to your specification, with no platform deciding what the catalogue, pricing or checkout can do. It can be built directly into your inventory, ERP or CRM rather than connected through a third-party layer. The trade-off is ownership of everything: hosting, security, maintenance and every future feature are development work. It fits unusual workflows — per-customer price lists, configurable made-to-order products, complex trade ordering — or scale and integration needs that a platform cannot meet cleanly.

Headless as a middle route

Headless commerce separates the storefront from the commerce engine, so a custom front end sits on a platform that still handles carts, orders and payments. It helps when one catalogue serves several channels, or when the front end needs something a theme cannot produce. It also adds moving parts and cost, so it should be chosen for a specific reason rather than as a default.

The comparison below summarises these trade-offs. Read the best-fit row as a starting hypothesis to test against your own catalogue, checkout and integration list, not as a rule that settles the decision.

Reading the comparison against your own scope

The drivers in the earlier chapters map directly onto this choice. A standard catalogue, a theme applied well, platform checkout rules you can live with and integrations available as apps all point towards Shopify. An existing WordPress site with substantial content, a team comfortable managing hosting and a need to change checkout through plugins points towards WooCommerce. Pricing rules, trade ordering, configurable products or a system of record the store must sit directly on point towards a custom build or a headless front end. When the signals conflict, the checkout and integration requirements usually decide it, because design can be solved on any of the three.

Apps and plugins are the cheapest way to add a feature on day one and can become the most expensive way to run a store over time. The decision should be made feature by feature, not by habit or by whoever quoted lowest.

A well-maintained app that does one job — reviews, a size chart, a courier integration — is usually cheaper than building the same thing. Problems start when a store depends on many apps that overlap, load their own scripts on every page, charge fees that grow with order volume, or break when one of them changes how it works.

When an app is the right call

Choose an app when the feature is common, the app is actively maintained, its pricing is predictable at the order volume you expect, and removing it later would not strand your data. Test it on the actual theme and a real product before committing, because an app that works in a demo store can still clash with yours.

When custom development pays for itself

Build when the feature is central to how you sell, when several apps are being combined to imitate one workflow, when app scripts slow the pages that matter most, or when recurring fees across apps approach what a one-time build would cost over the period you expect to keep the store. Keep that comparison honest by counting maintenance on the build side too.

A store assembled from the lowest quote and a pile of free add-ons often follows the pattern set out in the real cost of a cheap website: the saving shows up at launch, and the bill arrives later as maintenance, rework and replacement.

The build is a one-time cost; the store is not. Every ecommerce website carries running costs, and the platform choice largely decides which kind you pay and who manages them.

Platform subscription or hosting

A hosted platform charges a subscription according to plan. A self-hosted store pays for hosting that must cope with traffic peaks during sales, plus a domain, security certificates where they are not included, backups and security tools. A custom build pays for whatever hosting and infrastructure were chosen for it, which should be sized and priced as part of the proposal.

Apps, plugins and extensions

Paid apps and plugins usually bill monthly or annually, and some scale with orders or revenue. Ask for every one to be listed in the proposal with its billing basis, so the running cost of the store is visible before launch rather than discovered on the first card statement.

Payment and transaction fees

Payment gateways charge per transaction, and settlement terms differ by provider and method. On Shopify, orders through a third-party gateway also attract Shopify’s own transaction fee, as described above. Model these costs against realistic order values and payment mixes rather than treating them as a fixed overhead.

Maintenance and continuing development

Themes, plugins, apps and APIs change. Someone has to apply updates, test checkout after each change, repair broken integrations, renew certificates and watch for errors. On WooCommerce and custom builds this is essential ongoing work; on Shopify the infrastructure burden is lighter, but themes, apps and integrations still need looking after. Budget separately for new features, because a store that sells well always asks for them.

A store’s speed is decided by what is loaded onto its pages, not only by the platform it runs on. Heavy images, large theme files, several app or plugin scripts and embedded video can make a store slow on any of the three routes, and a slow product page on a mid-range phone and a patchy mobile connection costs sales that never show up in a report.

What performance work involves

Performance work covers correctly sized and compressed images, loading only the scripts a page actually needs, keeping theme code lean, and testing real product and collection pages on real phones rather than only on a fast office connection. On a hosted platform, most of the effort goes into the theme and the apps. On WooCommerce and custom builds, hosting, caching and database performance join the list, so they need an owner as well as a budget.

Planning for sale days and growth

Traffic is rarely even. Sale events, influencer mentions and festive campaigns bring spikes that a store must survive with checkout intact. A hosted platform absorbs most of that infrastructure load for you. A self-hosted or custom store needs hosting that can scale, a tested plan for peak traffic and someone watching during the event. Integrations deserve the same scrutiny, because a stock sync that keeps up on a quiet day can fall behind when orders arrive together.

Scaling is also about the catalogue and the team. More products, more markets and more people editing the store all put pressure on how the catalogue was modelled and how access was set up. A store built on clean foundations grows by configuration; a store built on workarounds grows by rework.

Migrating an existing store usually costs more than launching a new one, because the old store holds products, customers, orders, content and search visibility that must survive the move. The work lies in extraction, mapping, redirects and verification, not in the design.

What moves and what may not

Products, variants, collections, customers and content usually move. Order history, reviews, gift card balances, active subscriptions and customer passwords may not move fully, depending on what the old system exports and what the new one accepts. Establish this from a real sample of your store before a quote is treated as final, and move a representative slice first so surprises appear before launch.

Redirects and search visibility

Every URL that earns traffic today needs a redirect to its closest equivalent. Product and collection structures should be kept where possible, the content that earned rankings should be carried over rather than trimmed, and indexation, redirects and errors should be checked deliberately after launch. Rankings can move after any replatform on any platform; a complete redirect map is what protects them.

Planning the cut-over

The switch from old store to new is its own piece of work. Keep the old store reachable until the new one is proven, freeze catalogue changes for a short agreed window, move the final orders and customers that arrived during the build, and have the redirect map live from the first minute. Place real test orders with each payment method and delivery option before announcing anything. A cut-over that is planned costs a few days of care; one that is improvised costs far more in lost orders and support messages.

SEO built into the store

Structural SEO costs little during the build and a lot afterwards. It means product pages that stand on their own, collections that match how people search, variants that do not create competing pages, structured data that reflects what the page shows, and filter URLs kept under control. None of it is visible in a design review, which is exactly why it gets cut.

Treat launch as the start of that work. Content, internal linking and ongoing search and answer-engine visibility are scoped as a continuing effort after the store is live, not folded into the build fee.

Subscriptions, international selling and B2B ordering each change what the platform must do, so they should be declared at scoping even if they launch later. Adding them to a store that was not built with them in mind is often where replatforming conversations begin.

Subscriptions

Subscriptions need recurring billing that your payment provider supports, customer self-service to pause, skip or cancel, and stock planning around renewal dates. On a platform this is usually an app plus the provider’s approval; on a custom build it is development. Confirm recurring payment support for the methods your customers actually use before committing to a subscription model.

International and multi-currency selling

Selling abroad adds currency display and settlement, international shipping rates and duties, localised content and tax handling for each market. The effort depends on how many markets you enter, whether prices are set per market or converted, and if your payment provider supports international cards and payouts. Starting with one well-served market is usually cheaper than launching several thinly.

B2B and wholesale

B2B features — approved trade accounts, customer-specific price lists, minimum order quantities, quote requests, credit terms and GST invoice details — are among the clearest reasons a standard setup needs significant extension or a custom build. Document exactly how wholesale buyers order today, including the phone calls and spreadsheets, before choosing a platform for them.

Branditify’s Ecommerce service currently starts from ₹30,000 per project for a focused store. That is our own starting point, subject to scope, not a figure for the market; the price rises with catalogue complexity, design depth, checkout rules, integrations and migration.

The live figures for every service sit with our published starting prices, which are the reference if this article and a later update ever disagree.

Branditify designs and builds on Shopify, on WooCommerce or as a custom storefront, and the recommendation comes from how you sell rather than from a platform preference. You can read how an ecommerce project is scoped with Branditify, from the catalogue you actually sell to the systems the store must connect to.

If you are still working out what the customer-facing layer must do — variants, stock behaviour, delivery rules and checkout — the D2C storefront system describes that part of the store on its own, separately from the wider build around it.

A prepared scope gets you comparable quotes and fewer surprises during the build. It does not need to be technical. It needs to describe how the business sells, what the store must do and what it must connect to.

1. Catalogue: product count, product types, variants and options, a sample export, and the honest state of images and descriptions.
2. Discovery: how customers search, which filters matter to them, and the collections you already use.
3. Design: reference stores and why you chose them, brand assets, pages that need bespoke work, and who supplies content and photography.
4. Checkout: payment methods, delivery rules, pin code coverage, cash on delivery rules, tax details, and guest and account checkout.
5. Promotions and pricing: the campaigns you run and any wholesale, slab or rule-based pricing.
6. Operations: where stock lives, which systems orders must reach, couriers, marketplaces and how returns are handled.
7. Growth: migration from an existing store, search priorities, subscriptions, international markets and trade buyers.
8. Ownership: who runs the store day to day after launch, and what support you expect.

Separate launch requirements from the later list

Mark every item as needed for launch or wanted later. A phased scope lets a store start selling on a solid catalogue and checkout while larger integrations, loyalty programmes or international markets follow. It also makes quotes easier to compare, because every vendor prices the same first phase.

Share real data, not descriptions of it

A product export, a list of pin codes, a sample of order data and screenshots of the systems you use tell a vendor more than any written brief. Where you cannot share data, say what exists and how it is kept. Vague inputs force vendors to guess, and a guess is either padded or wrong.

Recognise when the brief is no longer a store

When the requirements start to look like order management, trade portals or ERP work rather than a storefront, it helps to understand how custom software development costs are scoped, because the drivers and the conversation shift with them.

The quality of an ecommerce quote shows in what it asks and what it states plainly. Put these questions to every vendor, and compare the answers rather than only the totals.

• Which platform do you recommend, and what in our catalogue, checkout or integrations led you there?
• Which parts of our scope are uncertain, and how will they be resolved before build begins?
• Which apps, plugins or extensions does the quote assume, and what does each cost to run?
• What can and cannot be changed in checkout on this platform and plan?
• What exactly moves in the migration, and what does not?
• How will redirects, structured data and filter pages be handled?
• What does each integration depend on from the other system, and what happens when a sync fails?
• Who maintains the store after launch, and how is new work priced?
• Who owns the theme, code, accounts and data at handover?

A vendor who answers these clearly is pricing your store. A vendor who cannot is pricing a template and hoping your store fits it. The difference rarely shows in the first invoice, but it always shows by the first sale season.

Start with the catalogue you actually sell, the rules your checkout must enforce and the systems your orders must reach. Once those are written down, the choice between Shopify, WooCommerce and a custom build usually becomes much clearer, and so does the budget.