Skip to content
Ecommerce Pune Online store development
Platforms PUBLISHED 24 AUGUST 2026 · 18 MIN READ

Which ecommerce platform is right for an Indian business

Every platform is a set of constraints you are agreeing to live with. This is what hosted, open source, headless and custom each commit you to, and which constraints matter most in India.

There is no best ecommerce platform, and any article that names one in its first paragraph has told you something about the article rather than about the platform.

What there is, is a small number of genuinely different shapes a platform can take. Each one hands you a different set of constraints, and the useful question is which set you can live with for the next three years.

This covers what a platform actually is, the four shapes, what each commits you to, and the requirements that are specific to selling in India and that half the comparison articles on this subject ignore because they were written for a different market.

If you have already narrowed it to the two obvious candidates, the Shopify versus WooCommerce comparison goes deeper on that head-to-head than this page does. Start here if you have not narrowed it yet, or if you suspect neither of them is the answer.

What an ecommerce platform actually is

The software that holds your products, takes an order and moves it towards being paid for and dispatched. Everything else people call a platform feature is built on top of those three jobs.

Underneath the marketing, every platform is doing the same short list of things. Knowing the list is what lets you compare two of them honestly, because it separates what a platform does from what a theme, an app or an agency does. What an ecommerce website costs in Pune breaks that second list down.

It holds the catalogue

Products, variants, images, prices, stock levels and the categories they sit in. How well it does this at your catalogue size is the thing that ages worst, and the thing nobody tests during a demo.

It runs the cart and the checkout

Adding, changing quantities, applying tax and shipping, collecting an address, handing off to a payment provider. This is where platforms genuinely differ, because it is the part most of them will not let you rewrite.

It records orders and customers

Order status, history, refunds, customer accounts. Simple until you need it to talk to your accounting system, at which point the quality of its data model starts to matter.

It renders the storefront

The pages a customer sees. Increasingly optional, which is the entire point of headless, covered further down.

Notice what is not on that list. Email marketing, loyalty, reviews, live chat, analytics and shipping labels are all things you bolt on. When a platform advertises them as features it usually means it has an app store, which is a different claim from having built them, and each bolted-on piece is an integration somebody maintains.

Platform or marketplace, which is a different question

Worth separating early, because the words get used interchangeably and they describe opposite arrangements.

Your own store on a platform Selling on a marketplace
Who owns the customer YouThey do
Who brings the traffic YouThey do
What you pay Subscription, hosting or build costCommission per sale
Control over the experience Almost totalAlmost none
How fast you can start WeeksDays
What you are building An assetA revenue channel
Most Indian sellers who succeed Build one eventuallyStart here to prove demand

They are not alternatives so much as different stages, and doing both is normal. The mistake is treating a marketplace listing as a substitute for owning a storefront, because the day the commission changes or the algorithm moves, you find out how much of the business was theirs. The build guide covers the sequencing in more detail.

A third arrangement exists and is worth naming: a marketplace you own, where other sellers list and you take the commission. That is a fundamentally different business from retail, with seller onboarding, split payouts and a chicken-and-egg demand problem, and no off-the-shelf platform makes it easy.

The four shapes, and what each commits you to

Almost every option you will be shown is one of these four. The differences between two products inside the same shape are small, which is why comparisons framed as WooCommerce vs Magento vs Shopify, or Ecwid vs WooCommerce, tend to produce less signal than people expect. The differences between shapes are the ones that decide the next three years, and ecommerce website maintenance, meaning who patches it and when, is the largest of them.

Shape Who runs the servers What you can change How you pay Real cost
Hosted The vendorEverything but checkoutMonthly, plus per orderA ceiling you cannot raise
Open source YouAll of itHosting and licencesMaintenance, forever
Headless You, mostlyThe entire front endBoth, usuallyTwo systems to keep in step
Custom YouEverythingBuild and retainYou own every bug
Choose by Who maintains itYour unusual ruleOrder volumeNot by feature count

The last column is the one to read twice. Every shape has a cost that does not appear on a pricing page, and it is the same cost in every case: somebody has to keep the thing alive. What changes is who that somebody is and what happens when they are unavailable.

Hosted platforms, and the India tax nobody mentions

Shopify, BigCommerce, Wix, Squarespace and the India-focused builders that have grown up around ONDC and WhatsApp commerce all sit here. The vendor runs everything, you configure rather than build, and you can be selling this week.

For a standard retail catalogue this is a genuinely good deal and there is no shame in taking it. You are buying the removal of an entire category of problem: no hosting, no patching, no backups, no three in the morning outage that is yours to fix. That is most of what a Shopify build buys you.

The constraint you accept is the checkout. On most hosted platforms you extend it within what the vendor permits, and where that is not enough the answer is an app or a plan upgrade rather than code. If your business has a rule that lives inside the checkout, this is the shape that will fight you, and no amount of budget changes that. The Shopify vs WooCommerce guide goes through how to test whether your rule is one of those.

The part that is specific to India

Shopify Payments does not operate in India, reportedly because of the Reserve Bank of India framework for payment aggregators and cross-border settlement. Every Indian Shopify merchant therefore uses a third-party gateway, and Shopify charges an additional transaction fee on every order that does not go through its own payment product. In most markets that fee is avoidable. Here it is not.

That fee runs around 2% on the entry tier as of August 2026, falling on higher plans, and it sits on top of whatever your gateway already charges plus 18% GST on that. It is the single largest structural difference between hosted and open source for an Indian store at volume, and it belongs in the model before you compare anything else. The payment gateway guide works through the full stack of charges.

Ask any hosted vendor two questions before signing: what is the total percentage taken per order including any platform fee, and what happens to your data and your URLs if you leave. The second question is the one that separates a platform from a trap.

Open source, and a deadline that has just passed

WooCommerce and Magento Open Source are the two that matter in practice. You own the code, you run the server, no vendor takes a percentage of your orders, and every part of cart and checkout is yours to change.

The cost is not the licence, which is usually nothing. It is that a WooCommerce store needs somebody to apply updates, in an order that does not break the checkout, ideally on a staging copy first, for as long as the store exists. That person is a line in what a WooCommerce store costs to run, and usually the largest one. That is the whole trade. Businesses that make it explicitly are usually happy here. Businesses that assume it away are the ones that call us eighteen months later with a security incident.

If you are on Magento, read this part now

Adobe ended regular support for Adobe Commerce and Magento Open Source 2.4.5 and 2.4.6 on 11 August 2026. Adobe Commerce customers on 2.4.6 have a further year at no additional cost, running to August 2027, followed by a security-only transitional period to May 2028. Magento Open Source merchants on those versions got no extension. For them, 11 August 2026 was a hard stop.

11 Aug 2026
Regular support ended for 2.4.5 and 2.4.6
Adobe lifecycle policy
2.4.9
Current Magento Open Source release, out 12 May 2026
Magento release timeline
May 2029
End of life for the current 2.4.9 line
Magento release timeline
June 2028
End of life for Adobe Commerce 2.4.7
Adobe lifecycle policy

If your store is running 2.4.5 or 2.4.6 on Magento Open Source today, it is receiving no new security patches. That is not a planning problem for next quarter. It is a live exposure, and the honest first step is to find out which version you are actually on, which a surprising number of owners cannot answer.

The other thing worth knowing is that Magento Open Source now has a community-governed fork, Mage-OS, created to guarantee the platform a future independent of Adobe's commercial priorities. It is designed for straightforward migration in either direction and supports existing Magento 2 extensions, which makes it a real option rather than a hobby project.

None of this is an argument against open source. It is an argument for knowing your version number and your end-of-life date before you need them. Every open-source platform has these dates. Most owners discover them the week they matter.

If you are on an unsupported version now, the options are upgrade, fork or replatform, and they are very different projects. Migration work is where that decision gets made properly, and a maintenance arrangement is what stops it recurring.

What headless commerce actually means

A term that gets used to mean modern, which it does not. Headless means one specific thing: the storefront your customers see is separated from the commerce engine that holds products and orders, and the two communicate over an API.

The head is the front end. Removing it means the platform stops rendering pages and becomes a service that answers questions about products and accepts orders, while something else entirely draws the shop.

What you gain

Complete freedom over the front end, the ability to serve several channels from one catalogue, and a storefront that can be made extremely fast because it is not constrained by the platform's templating.

What it costs

Two systems instead of one. Two deployments, two sets of dependencies, and a category of bug that exists only in the gap between them. Also a front-end developer, permanently, not just for the build.

Who it genuinely suits

Large catalogues, several storefronts or regions from one back end, a content-heavy brand experience, or a team that already has front-end engineers and a reason to use them.

Who it does not

Almost every store under a few thousand products with one storefront and no in-house developer. The performance you were promised is usually available on a conventional build for a fraction of the effort.

The honest summary: headless is a real architecture with real benefits, and it is also the most oversold idea in ecommerce right now. It is often proposed as a fix for slowness that was actually caused by too many plugins, or for rigidity that was actually caused by nobody being allowed to touch the theme. Both of those have cheaper fixes than a redesign and migration.

What gets said

We should go headless so the site is faster.

Speed is a symptom. Find out what is actually slow first, because the answer is usually images, plugins or hosting, and none of those are fixed by an architecture change.

What to ask

What can we not do today that headless would let us do?

If there is a specific, named answer, it may well be the right move. If the answer is a feeling, it is a very expensive way to buy one.

When custom is right, and when it is vanity

Building the commerce logic yourself rather than adopting somebody else's. Rarer than the people who want it think, and more common than platform vendors admit.

The test is not scale and it is not budget. It is whether the way your business takes an order can be expressed in a platform without a workaround. Manufacturers with negotiated dealer price lists, businesses selling configured or made-to-measure goods, rental and subscription models with unusual terms, and anything where an order needs approving before it is an order. Those are genuine custom cases, and forcing them into a retail platform produces something everybody quietly hates.

GOOD REASON

The order process itself is the business

Approval chains, credit checks, configuration rules, quantity breaks that interact with contract terms. If the logic of taking an order is where your competitive advantage lives, renting somebody else's logic is the wrong shape.

GOOD REASON

You are integrating more than you are selling

When the store is mostly a front end onto an ERP, a production system or a dealer network, the commerce part is small and the integration is the project. Platforms add constraints without adding much here.

BAD REASON

We want something unique

Uniqueness lives in the design, the copy, the products and the service. All of those are achievable on a standard platform, and none of them require owning the checkout code.

BAD REASON

The platform does not do one thing we want

Building an entire store to solve one gap is the most expensive possible fix. Price the workaround first. It is usually two orders of magnitude cheaper and reversible.

A B2B ecommerce platform, in the sense people usually mean, is one that can hold customer-specific prices and approval rules rather than a single public price list. Dealer ordering deserves a specific mention because it is the most common genuine case we see in Pune. Customer-specific pricing, credit limits, minimum quantities and approval steps sit exactly where hosted platforms draw their boundary, which is why B2B portals so often end up either open source or custom rather than hosted. Dealer ordering portals covers what those rules involve.

What "best in India" actually requires

This is where most global comparison articles stop being useful, because the features that decide it here do not appear in a US-written feature table at all.

Requirement Why it matters here What to check
GST-correct invoicing HSN codes and the CGST, SGST or IGST split by place of supplyWhether it is native, an app, or your problem
Cash on delivery, with rules COD was 60% to 65% of Indian orders in 2024 per ET Prime ResearchValue caps, pin-code rules, part payment
UPI at the checkout The default payment method for a large share of buyersThat the intent handoff works on a mid-range phone
Pin-code serviceability Delivery coverage varies enormously outside metrosWhether it can be shown on the product page
Indian courier integration Labels, pickups, tracking and COD remittanceWhether remittance flows back to the order
WhatsApp as a channel Order confirmation and support happen here, not by emailWhether it is supported or bolted on
A platform failing three of these Is not cheaperIt has moved the cost to you

Almost every platform can be made to do all six. The question is whether it does them natively, through an app you will pay for monthly, or through work somebody has to build and then maintain. That distinction is the actual price difference between two platforms that looked similar, and it is why we treat integrations as their own scope rather than a line at the bottom of a build.

One more, easy to forget: the last one on that list is not a nice-to-have. If your customers expect to be told about their order on WhatsApp and your platform can only send email, that gap is an ecommerce integration rather than a setting. Where the platform cannot be told, you will discover the gap through support tickets rather than through a feature comparison.

Is one platform better for SEO

Not in any way that decides a ranking. Every mainstream platform produces crawlable pages, and the difference in outcome between two stores on different platforms is almost entirely explained by their category copy, product detail and internal linking rather than by the software underneath.

What does differ is how much of the technical surface you control, and that only becomes significant at scale.

URL structure

Hosted platforms usually impose fixed path segments for products and categories. Not a penalty, never fatal, but not yours. Open source and custom give you the lot.

Crawl control on filters

Facet combinations generating thousands of URLs is the most common technical problem on a large catalogue. Controllable everywhere, considerably easier when you own the server.

Speed

Core Web Vitals are assessed on real user sessions, so hosting quality and plugin count matter more than the logo on the platform. Hosted is fast by default; self-hosted is exactly as fast as you paid for.

The thing that actually decides it

Whether anyone writes the category descriptions and links the catalogue together sensibly. Identical on every platform, and the reason most stores do not rank.

If search is a real part of the plan rather than something to look at after launch, the decisions that matter are structural and belong at build time, which is what building with SEO in from the start means. Retrofitting it afterwards is ecommerce SEO work, and a longer job.

What Amazon and Flipkart run on, and why it does not help you

A question people search for often enough that it deserves a straight answer, whether it is asked as which ecommerce platform Amazon uses or as which platform Flipkart runs on. Neither uses a commercial ecommerce platform. Both built their own, in house, over many years, tuned to problems that only exist at their scale, and neither stack is available to anybody else. If you are weighing real options instead, comparing Shopify and WooCommerce is the more useful page.

The useful takeaway is not that you should build your own. It is the opposite. They built custom because at that volume the constraints of any off-the-shelf platform would cost more than an engineering department. That calculation reverses completely below a certain size, and almost every business is below it.

The pattern worth copying from them is not the architecture. It is that both treat the website, its SEO and the checkout as the product rather than as the wrapper around it. That is available on any platform, and it costs attention rather than engineering.

How to choose, in the right order

Work down this list. Most businesses have their answer by the third question, and the ones that do not have genuinely unusual requirements rather than a difficult decision.

Who maintains this in two years?

Answer by name, not by intention. If the answer is nobody, you have just eliminated every self-hosted option, and that is a useful thing to know before you look at features.

Is there a rule that lives in the checkout?

Write down the most unusual thing about how you take an order. If it belongs inside the checkout, hosted platforms will fight you. If it does not, they will not, and the rest is preference.

What is your order volume, and what is your margin?

A per-order platform fee is trivial at fifty orders a month and material at five thousand. This is where hosted stops being obviously cheaper, and it is arithmetic rather than opinion.

How many of the six India requirements are native?

Count them from the table above for each candidate. The gaps are either monthly app costs or build work, and both belong in the comparison.

What happens if you leave?

Data export, URL structure, tokenised cards. Ask before signing, because the answer never improves later.

  • Write your most unusual ordering rule in one sentence.
  • Name the person or retainer who will apply updates.
  • Estimate monthly order volume and multiply by any per-order platform fee.
  • Score each candidate against the six India requirements, natively or not.
  • If you are on Magento, find out which version you are running today.
  • Ask every vendor what happens to your data and URLs if you leave.

If two options are still tied after that, they are genuinely equivalent for your business and you should pick the one whoever maintains it knows better. That is a real tiebreak, not a cop-out, and it predicts satisfaction better than any feature comparison will.

Want this narrowed down with your actual requirements?

Tell us what you sell, how orders reach you today, and what your pricing does that a template would not express. We will tell you which shape fits and why, including when the answer is the cheapest one.

Questions we get asked about this

What is an ecommerce platform?

The software that holds your catalogue, runs the cart and checkout, and records orders and customers. Everything else people describe as a platform feature, including email marketing, reviews, loyalty and shipping labels, is usually an app bolted on top rather than part of the platform itself.

Which is the best ecommerce platform?

There is no single answer, and the question is better asked as which shape fits. Hosted platforms suit standard retail catalogues where nobody wants to own infrastructure. Open source suits businesses with unusual rules and somebody to maintain it. Headless suits large catalogues or several storefronts with front-end engineers available. Custom suits businesses where the ordering process is itself the product.

Which ecommerce platform is best in India?

Whichever one handles GST-correct invoicing, cash on delivery with rules attached, UPI at the checkout, pin-code serviceability, Indian courier integration and WhatsApp natively rather than through six paid apps. Those six requirements move the real cost far more than the subscription does, and they are the ones global comparison articles leave out.

What is headless commerce?

An arrangement where the storefront customers see is separated from the commerce engine that holds products and orders, with the two talking over an API. You gain complete control of the front end and the ability to serve several channels from one catalogue. You take on two systems to maintain instead of one, and a permanent need for a front-end developer.

Which ecommerce platform does Amazon use?

Its own, built in house and not available to anyone else. Flipkart is the same. Both built custom because at their volume the constraints of an off-the-shelf platform would cost more than an engineering department, which is a calculation that reverses completely for almost every other business.

Is Magento still a safe choice in 2026?

It is viable, but only with your eyes open about version support. Adobe ended regular support for 2.4.5 and 2.4.6 on 11 August 2026, and Magento Open Source merchants on those versions received no extension, so a store still on them is unpatched today . The current line is 2.4.9, released 12 May 2026 with end of life in May 2029, and the community-governed Mage-OS fork now gives the open-source side a future independent of Adobe.

Should a small business use a hosted platform or WooCommerce?

Hosted if nobody in the business will own updates, which is the single best predictor of regret. WooCommerce if you have a developer or a retainer , if order volume is high enough that a per-order platform fee starts to bite, or if you need to change something a hosted checkout will not let you change.

Written by Yogesh Jadhav

Founder, Ecommerce Pune

More than ten years in software development, now building and maintaining online stores for businesses across Pune and Pimpri-Chinchwad on Shopify, WooCommerce and custom code. Everything here comes out of that work rather than from a content calendar.