Start on Shopify. Build custom only when you can write down, in one sentence, the thing your business does that Shopify refuses to do, and that sentence is about your commercial model rather than your design taste. That's the whole decision. Everything below is how to check whether your sentence survives contact with a spreadsheet, because custom e-commerce development versus Shopify is a cost-of-ownership question long before it's a technology question.
We've built both. We've also migrated brands off custom stacks they paid handsomely for, usually two years after launch, usually because the one developer who understood the checkout left.
What you're actually paying Shopify for
Not the theme. The theme is the cheap part and the part founders fixate on.
You're paying for PCI-compliant card handling you never touch, a checkout that has been A/B tested across more carts than any team in India will ever see, uptime through a Diwali traffic spike without anyone sitting up at 2am watching CPU graphs, and a payments layer where adding Razorpay or a second gateway is a configuration job rather than a sprint. You're paying for the fact that when a card network changes a 3DS rule, somebody else deals with it.
On a custom build, every one of those becomes a line item on your engineering roadmap. Forever. Security patching does not stop being your job because you shipped.
The three-year arithmetic, with the numbers written out
Take a D2C brand doing roughly ₹2 crore a year, 400-ish SKUs, one warehouse, COD at maybe 45% of orders.
Shopify route. Theme customisation, data migration, payment and shipping integrations, a couple of bespoke sections: call it ₹7,00,000 as a realistic one-time build with an agency that knows what it's doing. Platform subscription plus the five or six apps that actually earn their keep: assume ₹40,000 a month all in. Three years = ₹14,40,000. Add ₹2,00,000 of ad-hoc dev across those three years for new features. Total: ₹23,40,000.
Custom route. A production-grade commerce build (catalogue, cart, checkout, payments, order management, admin, returns, reporting) is not a three-month project no matter what the proposal says. Six months with a small competent team in India lands between ₹18,00,000 and ₹35,00,000. Take ₹25,00,000. Then maintenance: one backend developer, part of a frontend developer, hosting, monitoring, and someone on call. ₹2,00,000 a month is lean. Three years = ₹72,00,000. Total: ₹97,00,000.
Gap: about ₹73 lakh over three years. On ₹6 crore of cumulative revenue, that's a bit over 12% of topline spent on the difference between two ways of showing a product page.
Now the part the spreadsheet hides. In those three years the Shopify store got checkout improvements, new payment methods and fraud rules it didn't pay for. The custom store got whatever its roadmap had budget for, which is never the boring infrastructure work. If you want the component costs broken down properly, we've published our Shopify development cost ranges for India rather than hiding them behind a call.
When custom e-commerce development is genuinely the right call
There are real cases. They're narrower than most founders believe.
- You're a marketplace, not a store. Multiple sellers, split settlements, per-seller payouts and commission logic. Shopify is a single-merchant system at its core, and the multi-vendor apps bolted on top get fragile around money.
- Your pricing is a calculation, not a number. Industrial B2B with customer-specific rate cards, slab pricing, credit limits and approval workflows. Some of this is doable on Shopify's B2B features. Deep ERP-driven configurators with hundreds of dependent options are not.
- The thing you sell isn't a product. Insurance, lending, ticketing with seat inventory, anything where the "cart" is a regulated application form with underwriting behind it.
- Usage-based or metered billing that has to reconcile against consumption data from your own systems.
- A contractual or regulatory requirement to hold data in your own infrastructure that your legal team has actually written down, not one someone assumed.
Notice what isn't on that list: wanting a unique design, wanting faster pages, wanting better filters, wanting a custom bundle builder. All of those are theme and app problems.
The things founders think need a custom build, and don't
"Our catalogue is too big for Shopify." We hear this most often from jewellery, auto parts, pharma distribution and apparel brands with deep size-colour matrices. The catalogue is almost never the problem. The problem is that the default collection page makes 4,000 SKUs unshoppable, so the brand assumes it needs a bespoke search engine. It needs faceted filtering and decent on-site search, which is a job for something like FilterPro, our own filters and AI search app, or any competent equivalent. Six weeks of merchandising work beats six months of engineering.
"Our checkout needs to be different." Usually this means one extra field, a GST number capture, or a COD confirmation step. All of that is available through Shopify's checkout extension points now. A genuinely different checkout is a reason to think hard; a different checkout field is not.
"The site is slow, so we'll rebuild it properly." Rebuilding a slow Shopify store as a slow custom store is a popular and expensive move. Most Shopify stores that load badly are carrying eleven apps' worth of render-blocking script and a 900KB hero image. Fix the cause. Our speed work routinely takes an LCP in the 4-second range down under 2 without touching the platform.
"We want to own our code." You will own a Liquid theme and any apps you commission. You will not own the checkout. Decide whether that actually matters to your business or whether it's a feeling.
Headless Shopify: the middle option, and the wrong reason for picking it
Headless keeps Shopify's checkout, admin and payments, and replaces the storefront with your own React or Hydrogen frontend talking to the Storefront API. It's a legitimate architecture. It is also the most over-prescribed one in the market.
Good reasons: you're running a storefront that's genuinely an application (configurators, logged-in dashboards, heavy personalised state), or commerce is one module inside a much larger product, or you need content and catalogue from several systems stitched together at the edge.
Bad reason: speed. A well-built Liquid theme on a modern Shopify stack is fast. A badly built headless storefront with an over-eager JS bundle is slower than the theme it replaced, and now your merchandising team can't change a banner without a deploy. Headless roughly doubles the build cost and permanently adds a frontend maintenance line. Take it on only if you've named a capability, not a metric.
The India-specific questions that decide it faster than architecture does
COD is the one that catches custom builds out. If 40-50% of your orders are cash on delivery, your RTO exposure is the single biggest lever on margin, and you need address verification, risk scoring, prepaid nudges, order confirmation over WhatsApp, and partial-advance flows. On Shopify that's an evening of app configuration and a week of tuning. On a custom stack, every one of those is a build, and the vendors who'd happily sell you an app have no API into your system.
Then GST. Place-of-supply logic, HSN codes, e-invoicing above the turnover threshold, credit notes on returns, and a format your CA will accept without grumbling. It's solvable either way. It is dull, fiddly, and it changes, which makes it exactly the kind of thing you want somebody else maintaining.
Festive load is the third. A sale that does 20x normal traffic for four hours exposes every unindexed query and every synchronous payment callback you wrote. We have watched a custom stack fall over during a 9pm Diwali drop. The post-mortem took a week, the lost revenue didn't come back, and the brand was on Shopify within four months.
Where this breaks: the awkward cases
Shopify is not always the easy answer, and pretending otherwise would be dishonest.
Multi-location inventory with store-level fulfilment rules gets messy. It works, but if you run eight retail outlets plus a warehouse plus a quick-commerce dark store, expect to spend real money on inventory logic and expect some of it to live in an app rather than in Shopify. Running B2B and D2C off one catalogue with different pricing, different tax treatment and different shipping is doable and still involves compromise. Multi-country with separate legal entities often means separate stores, and separate stores mean duplicated merchandising work.
And if you need deep logic inside the checkout itself, that's Shopify Plus territory with Functions, which changes the cost comparison. Plus is worth it when your checkout logic or your volume demands it, and not a month earlier. We've told brands doing ₹3 crore to stay off Plus. Most agencies won't.
How to settle this in a week
Write down the five things your business does that you believe a standard store can't handle. Be specific: "dealer prices vary by state and credit terms", not "complex pricing".
Take each one to a Shopify developer who has built the thing before and ask how it would be done, how long it takes, and what breaks. Three of the five will have a standard answer. One will need a custom app, which is a few weeks, not a platform decision. If the fifth genuinely has no answer and it's load-bearing for your revenue, you have a case for building. If all five have answers, you've just saved ₹70 lakh and about five months.
If you're already on a custom stack and the maintenance bill is the reason you're reading this, the migration path is better-trodden than you'd think, and URL structure and SEO equity are the parts to plan first, not the design.
Send us the five sentences. We'll tell you which ones are real, in writing, before anyone talks about scope. A free audit is a reasonable place to start if you'd rather we look at the store first.