What You Sell Decides Shopify, WooCommerce or Custom

Most platform arguments are had in the wrong order. Someone asks "Shopify or WooCommerce?" and the answer comes back as a preference — one agency likes the monthly fee and the app store, another likes owning the code. Both answers can be right for different shops and neither has anything to do with the shop asking.

There are only three questions that reliably decide this, and all three are about what you sell rather than what you can afford. How many things are in your catalogue. How complicated a single product gets when you break it into options. And how much the checkout has to bend away from the standard add to cart, pay, done flow before it matches how your business actually takes money.

Get those three right and the platform is more or less chosen for you. Get them wrong and you will pay twice — once to build, once to migrate.

Start with the catalogue, not the design

Count your products. Not your product photos, not your categories — the number of distinct things a customer could buy.

Under roughly 200 products. Every platform handles this comfortably. Shopify, WooCommerce, even a hand-built cart. At this size the platform decision is genuinely low stakes, which means you should choose for the boring reasons: who will maintain it, how easily you can edit a product description at 11pm, and whether your staff can be taught the admin screen in an afternoon.

200 to about 5,000 products. This is where site search and filtering start to matter more than the homepage. If a customer cannot narrow "cotton kurtas" down to size, colour and price in three clicks, the catalogue might as well not exist. Shopify's built-in search is adequate and its filtering works off product metafields; on WooCommerce you will usually be adding a filtering plugin and, past a couple of thousand products, thinking about how the database handles a filtered query on a shared server. Neither is a dealbreaker. Both need deliberate work rather than a default theme.

Above roughly 10,000 products. Now the real question isn't the storefront at all — it's where the catalogue lives. If you are a distributor with ten thousand SKUs, your stock and prices almost certainly live in Tally, Busy, an ERP or a spreadsheet somebody updates every morning. The website is a display window onto that data. The build becomes a sync problem, and the platform matters less than whether it has a sane way to accept bulk updates without a human retyping them. This is where automating the flow between your back office and your storefront stops being a nice extra and becomes the project.

Variants are where platforms quietly break

A variant is a version of one product — size, colour, weight, finish. This is the number that catches people out, because a small catalogue can hide an enormous variant count.

Suppose you sell a school uniform shirt in 8 sizes, 3 colours and 2 sleeve lengths. That is one product in your head and 48 buyable combinations in the database. Ten such shirts and you are managing nearly 500 variants with ten product pages.

Shopify's limits here are public and worth knowing before you commit: historically 100 variants per product with three option types, now raised to 2,000 variants and up to three options on standard plans, with higher option counts available on the top tier. That ceiling is fine for clothing and footwear. It is not fine for something like made-to-measure tailoring, where the customer specifies a chest measurement in centimetres — you cannot enumerate that as a dropdown list, and pretending you can produces a monstrous product page.

WooCommerce has no hard variant ceiling, which is not the same as being good at volume. Variations in WooCommerce are stored as their own posts. A product with 400 variations is 400 rows of data that the admin screen tries to load when you edit it, and product pages that need a price lookup on every option change. Stores do run this way; they run it on decent hosting with object caching and someone who knows what to look at when the admin goes slow. Deciding that in advance is the whole point — see our note on what managed maintenance actually covers.

The signal to look for is simple. If your options are a fixed list, a hosted platform will cope. If your options are a measurement, a calculation, an uploaded file or a price that depends on two other choices — laminate area in square feet, glass thickness by dimension, print quantity breaks, engraving text — you are no longer selling variants. You are selling a configured quote, and that is a build, not a plugin.

How much the checkout has to bend

This is the question almost nobody asks and the one that most often forces a rebuild eighteen months in.

The standard checkout assumes a stranger, one address, one payment, one shipment, one price. Every Indian retailer I have spoken to has at least one requirement that fights that assumption. A few common ones:

• Cash on delivery, but not everywhere. You want COD for orders under ₹3,000, not for fragile items, not to pin codes your courier marks as high-return.
• Pin code serviceability before payment. Perishables, furniture, anything with a delivery slot. The customer must be told "we don't deliver to 110096 on Sundays" before they pay, not after.
• GST invoicing. A B2B buyer needs to enter a GSTIN and receive a compliant tax invoice with HSN codes and place of supply. That is a legal document, not a PDF prettied up by a theme.
• Different prices for different buyers. Dealer rates, distributor slabs, quantity breaks, credit terms. Retail-first platforms treat price as a property of the product; wholesale treats price as a property of the relationship.
• Partial payment. A ₹2,000 booking amount against a ₹40,000 order, balance on delivery.

Shopify is deliberately protective of its checkout, and for a good reason — it is the part that must not break. Direct editing of the checkout template has been retired in favour of app-based extensions, and the deepest customisation sits on the enterprise tier. What you gain is a checkout that is fast, tested on a scale you cannot replicate, and never your problem at 2am on Diwali. What you give up is the ability to insert your own logic mid-flow. Most of the requirements above are solvable on Shopify through apps; each app is another monthly subscription, usually billed in dollars, and another dependency you do not control.

WooCommerce lets you change anything, because the checkout is code on your server. That freedom is real, and it is the reason serviceability rules and GST invoicing are more often done properly on Woo in India. The cost is that everything you change is yours to maintain through every WordPress, WooCommerce and PHP update. That is an ongoing commitment, not a one-time fee.

Custom earns its place when the checkout is the product. Subscription boxes with pause and skip logic. Clinics booking a slot with a practitioner. A rental business calculating by days with a deposit. A manufacturer where the "cart" is a request for quotation that a salesperson prices before the customer pays. In those cases, bending a retail platform into shape costs more than building the thing that matches, and it tends to sit closer to your CRM than your catalogue.

A rough map

What I would not buy

Three things get sold in this category that rarely repay their cost.

A headless rebuild for a store doing thirty orders a day. "Headless" means splitting the storefront from the commerce engine so the front end can be built in a modern JavaScript framework. It is a legitimate choice at real scale. At small volumes it doubles the number of systems you maintain, makes routine content edits a developer ticket, and buys you speed you could have had by fixing your images and your hosting.

A bespoke platform written from scratch for a simple catalogue. If you sell 80 products with fixed options and a normal checkout, a custom cart means paying to reinvent payment retries, abandoned cart emails, tax handling and PCI scope — all of which already exist, tested. Custom should be reserved for the part of your business that is actually unusual.

A tower of plugins. A WooCommerce site running forty extensions, six of them overlapping, three abandoned by their developers, is the most common reason an owner tells me their store "just became slow". Every plugin is code you did not write and cannot audit, loading on every page. Fewer, better-chosen extensions and a little custom code beat a plugin for each requirement. The same applies to Shopify apps, where the monthly total creeps up unnoticed.

I would also be cautious about anyone who answers the platform question before asking for your product list. The answer is in the product list.

What to do next

Before you take another quote, write down three numbers and one paragraph. The number of products. The largest number of variants on any single product. The number of distinct prices the same product can have depending on who is buying. Then a paragraph describing exactly how an order is taken today, including the awkward parts — the COD limit, the pin codes you refuse, the advance you collect, the invoice your GST-registered customers demand.

Hand that to whoever is quoting. If the recommendation does not change based on what is in it, the recommendation was not about your business. If you would like us to read through it with you and say plainly which route fits — including when the honest answer is that your current store is fine and only needs fixing — tell us what you sell, or look at how we approach building and rebuilding stores first.

Questions we get asked