What eCommerce website development costs in India

Most requests for an eCommerce quote open with a product count. It is the wrong opening number, and it sends the conversation in the wrong direction from the first line.

A hundred simple products is a smaller job than twenty complicated ones. Twenty products with size, colour, bundle logic, subscription options and different tax treatment will take longer to build, longer to test and longer to migrate than a hundred items that each have one price and one variant.

This piece sets out what actually drives the cost of an eCommerce build in India: how variable your catalogue is, what the store has to talk to, how much of the design is genuinely new, and what has to be carried over from an existing shop. There are no figures here on purpose. A number quoted before any of that is understood is a guess, and guesses are corrected later at your expense.

Three different things called an online store

Name which one you are buying and most of the quote variation disappears.

A themed store. A well-chosen theme, configured properly, with your branding, your catalogue and your payment and shipping setup. This is a real project done well, and for a great many brands it is the correct answer for a first store.

An adapted store. A theme taken apart and rebuilt where it matters: the product page, the collection filtering, the cart and checkout experience. The parts customers touch most get individual attention, the rest stays sensible.

A custom store. Templates drawn from a blank page, usually because the selling model does not fit what themes assume — configurable products, trade pricing, bundles, or a catalogue that behaves like a database rather than a shelf.

Briefs frequently describe a themed store and then list requirements that only a custom one can meet.

What is actually on the invoice

A complete store quote has more lines than most buyers expect, and the build is only one of them.

Discovery. Catalogue structure, variant logic, tax and shipping rules, and who does what after launch.

Design. Templates, states, and a component set the build follows.

Build. The storefront, plus any custom logic behind it.

Data. Products, variants, images, customers and past orders, loaded and checked.

Integrations. Payments, shipping, accounting, and whatever else runs your business.

Testing. Real transactions on real devices, including failed payments and returns.

Launch. Redirects, DNS, tracking, and a plan for the first week.

When a quote is dramatically cheaper than the others, compare it line by line rather than at the total. Something in this list has usually been left out or assumed to be your job.

Catalogue complexity beats catalogue size

This is the single most reliable predictor of what a store will cost to build.

Simple products are cheap at any volume. One price, one image set, one stock number. Thousands of them are a data exercise, not an engineering one.

Variants multiply everything. Size and colour is straightforward. Size, colour, material and made-to-order lead times, where some combinations do not exist and others are priced differently, is a modelling problem. It affects the product page, the filtering, the stock logic and every test you run.

Ask yourself three questions before requesting quotes. Does the price change by customer, quantity or region. Do products come in sets or bundles that need their own stock behaviour. Does anything need configuring by the buyer before it can be added to a cart. Any yes moves you towards the custom end, and any agency worth hiring will want the answers before quoting.

The integrations that decide the number

Integrations are where two quotes for the same brief diverge most, because each agency makes different assumptions about what already exists.

The usual set. Payments, shipping and courier allocation, accounting or ERP, email and messaging, and analytics.

What makes one expensive. Not the connection itself, which is often a known quantity, but the reconciliation around it. What happens when an order succeeds in the store and fails in the ERP. Who notices, and what fixes it.

List every system by name in your brief, including the ones you plan to replace. An agency that knows your accounting package can tell you in a sentence whether it is a connector or a project. Leaving the list vague guarantees the estimate is padded, or wrong, or both.

Payments and the Indian specifics

An Indian store carries requirements that a template built elsewhere does not anticipate.

Cash on delivery. Still a large share of orders in many categories. It changes the checkout, the fraud checks, the courier selection and the accounting. Treating it as a payment method to switch on understates it considerably.

UPI. Fast, cheap and expected. The work is in the failure path rather than the success path — timeouts, duplicate attempts and the reconciliation that follows.

Returns and refunds. Higher volumes than most overseas benchmarks assume, particularly in apparel. The refund flow is real product work, not an afterthought, and it is where customer trust is won or lost.

None of this is exotic. It is ordinary work for a team that builds for this market, and unfamiliar territory for one that does not. Ask which stores an agency has actually launched here.

Migration is usually the biggest single line

If you have an existing shop, moving it is often larger than building the new one.

What has to move. Products and variants, images, customer accounts, order history, reviews, content pages, and every URL that currently earns traffic.

What quietly breaks. Discount logic, subscription arrangements, loyalty balances, and integrations wired into the old platform in ways nobody documented.

What decides whether it goes well. The redirect map. Getting that wrong is the one migration mistake that shows up directly in revenue, and it is entirely preventable.

If a quote for a replatform does not mention redirects, ask about them before anything else. The answer tells you whether the team has done this before.

Design: theme, adapted, or from scratch

Design is where buyers most often pay for the wrong thing, in both directions.

Paying for a fully custom design on a first store, before you know how customers actually move through it, is usually premature. So is running a business for years on an unmodified theme that fights the way you sell.

The parts that repay custom work. The product page, the collection and filtering experience, and the cart. Those three carry almost all of the revenue effect.

The parts that rarely do. The about page, policy pages, and the blog. A good theme handles those perfectly well.

A sensible middle path is to adapt: keep the theme where it is competent, rebuild the three templates that matter. It costs a fraction of a full custom build and captures most of the benefit.

Content is the schedule, and usually the budget

The single most common cause of a store launching late is not development. It is that the product content is not ready.

Photography, descriptions, specifications, size guides and category copy all have to exist before a store can go live, and they are almost always the client’s responsibility. A build can be finished and sitting idle for weeks waiting for images.

The honest version. If you have a large catalogue and no photography standard, that work is bigger than the website. It should appear on the plan as its own line with its own owner, not as an assumption.

Decide early who writes product copy and who shoots the images. If the answer is the agency, it belongs in the quote. If it is you, it belongs in your timeline.

What starts costing at launch

A store is an operating system for a business, not a project that finishes.

Platform and app fees. The platform subscription, plus every app doing a job the theme does not. App fees accumulate quietly and are worth auditing twice a year.

Maintenance. Updates, security, broken integrations, and the small fixes that follow any real usage.

Improvement. The first version of a store teaches you where customers hesitate. Acting on that is where the return actually comes from, and it needs budget you have not already committed to the build.

Plan for the store to change continuously in its first year. Teams that treat launch as completion tend to be rebuilding within three years, having spent more in total than continuous improvement would have cost.

How to brief so quotes are comparable

Four additions to a brief remove most of the variation between quotes.

Describe the catalogue honestly. Not just how many products, but how variable they are, and whether pricing changes by customer or quantity.

Name every system. Payments, courier, accounting, ERP, email, and anything internal.

Say what exists. Photography, product copy, brand guidelines, an existing store and its platform.

State the first success measure. More orders, higher average order value, fewer support emails, faster fulfilment. It changes what a good agency recommends, and it lets them tell you what to leave out.

Five questions that separate a good quote from a cheap one

What is not included? Ask it directly. The answer separates a scoped quote from an optimistic one immediately.

Who loads the products, and who writes the copy? The most commonly disputed line in any store project.

What happens to our existing URLs? If you are replatforming, this question protects your traffic.

Which apps are we committing to, and what do they cost us monthly? A build can look inexpensive and carry an expensive tail.

What do we own, and how do we leave? Store admin, repository, theme files, app accounts. The answer should be short and clear.

What we would cut, in order

When a store has to fit a tighter scope, this is the order we would reduce it.

Cut custom design on secondary pages. Keep the theme for anything that is not product, collection or cart.

Cut apps. Launch with the smallest set that lets you trade. Add them when a real problem justifies one.

Cut the second sales channel. Marketplaces and social selling can follow once the core store works.

Cut historical data, carefully. Order history can sometimes stay in the old system for reference rather than being migrated. This is a judgement call, not a default.

Do not cut testing, redirects or the returns flow. Each of those costs far more to repair after launch than to do properly before it.

What it comes down to

The cost of an eCommerce build in India is set by four things: how variable your catalogue is, how many systems the store must talk to, whether an existing shop has to be carried across, and how much of the design is genuinely new rather than adapted.

Product count barely features. Nor does page count. An agency that asks about variants, pricing rules and integrations before quoting is scoping the work properly. One that asks how many products you have and returns a number the same day has not started yet.

If you have a brief or a quote in hand and want a second opinion, send it over. We will tell you what we would ask before committing to a number, and we will say so plainly if the quote you have is a fair one.