
Most people asking about Shopify vs custom eCommerce should stay on Shopify. The real constraint is usually a theme or an app, not the platform. That is the honest answer and it is the one this guide argues for, with the specific exceptions where building your own is the right call.
One distinction first, because blurring it is how these decisions go wrong:
Different decisions. Different costs. If you are weighing a front-end rebuild rather than a platform exit, read is headless Shopify worth it instead. This post is about leaving.

The useful question is not "which platform is better". It is "how much of this stack do you want to be responsible for". Every step away from Shopify hands you more control and more surface area to maintain. The second half of that trade is the one people forget to price.
A lot of "reasons to go custom" are repeated from blog posts written years ago. Three of the most common do not survive a check against Shopify's current documentation.
The variant ceiling. The old complaint was that Shopify capped you at 100 variants per product. Per Shopify's own API documentation, stores now have a default limit of 2,048 product variants per product. That is far beyond what almost any merchant will use. If someone is telling you to rebuild your platform over variant limits, they are working from stale information.
"You don't own your store." This framing is emotionally satisfying and analytically useless. Your products, customers and orders all export. A custom build does not make you independent either. It swaps one dependency for a longer list: your host, your payment processor, your CDN, your fraud provider, your tax engine, and the team that keeps all of it running. The real question is portability and switching cost. Price it, don't feel it.
Design limits. Outside of checkout, which gets its own section below, Shopify's front end is as flexible as you are willing to pay for. If your storefront looks templated, that is a theme and build-quality problem. Rebuilding an entire platform is an extraordinarily expensive way to fix a design problem.
Here is the limitation that is real, current, and most likely to force the decision. It also moved recently, which is why older advice gets it wrong.
Per Shopify's own developer documentation, checkout.liquid is deprecated and unsupported for the Information, Shipping and Payment steps. It was sunset for the Thank you and Order status pages on 28 August 2025. Script tags on those pages were sunset for Plus stores on the same date, and for non-Plus stores on 26 August 2026.
What replaced it, checkout UI extensions rendering on the information, shipping and payment steps, is available only to stores on Shopify Plus.
Put those together and the 2026 position is blunt: meaningful checkout customisation on Shopify is now a Plus feature. If your business genuinely depends on a non-standard checkout, say unusual duty handling, a quoting step, or a regulated verification before payment, your realistic options are Plus or leaving. That is a much sharper constraint than it was two years ago, and it is the trigger we see most often that actually holds up.
Payments are the second real cost. Shopify's pricing page confirms that third-party transaction fees apply when you use a payment provider other than Shopify Payments, at a rate that depends on your plan. That fee sits on top of your processor's own rate. If you are locked to a specific acquirer for regulatory or commercial reasons, you pay twice. At enough volume that becomes a line item worth modelling against a build.
Worth pressure-testing before you commit either way? Tell us what you are running into and we will tell you honestly whether it is a platform problem or a build problem.
The honest trigger is almost never "Shopify is too limited". It is that the business was never really a storefront.
Shopify is excellent at one shape: a catalogue, a cart, a checkout, an order. The further your model sits from that shape, the more of your build becomes fighting the platform instead of using it.

People estimate the build quote. What they miss is everything Shopify was doing invisibly, which you now own permanently.
PCI compliance scope. Fraud screening. Chargeback handling. Sales tax and VAT across jurisdictions. Payment-method coverage. Uptime through peak trading. A security surface that now includes card data. None of that shows up in a feature comparison, and all of it becomes a standing operational cost rather than a one-off.
So the decision is never "custom build versus Shopify subscription". It is custom build plus permanent operational ownership, versus Shopify subscription plus fees. We cover the cost modelling for the middle option in the headless Shopify guide, and for a lot of teams that middle option turns out to be the answer, because it keeps Shopify carrying compliance while giving you the front end you actually wanted.
We start by separating the constraint from the symptom, because those two get confused in most of these conversations. A slow, templated, badly converting store is usually a build problem. We will say so rather than sell you a platform migration, which is exactly why our Shopify CRO work exists. That is the more common diagnosis by a wide margin.
When the business genuinely is not a storefront, we build the thing it actually is. PayEver's marketplace builder and Mileprix's logistics platform were both custom because no storefront product was going to produce them. Not because their owners were annoyed with a plugin.
Across 150+ projects we have held a 98% client satisfaction rate and a 5.0 rating from 200+ reviews, working both sides of this decision: eCommerce builds and custom platforms. That is the only reason we can afford to tell most people to stay where they are.
For most businesses selling products, Shopify. It handles payments, PCI compliance, fraud, tax and uptime, and those are expensive to own well. Build your own when your model is not really a storefront: a marketplace, an operations platform, or a flow that genuinely cannot run inside Shopify's checkout.
Checkout is the significant one. checkout.liquid is deprecated for the information, shipping and payment steps, and the checkout UI extensions that replaced it on those steps are Shopify Plus only. Third-party payment provider fees are the other real cost. Variant ceilings and design flexibility get cited constantly and are not genuine blockers.
Two separate things. Payment processing, charged by whoever processes the card, and a third-party transaction fee that Shopify adds when you use a provider other than Shopify Payments, at a rate that depends on your plan. Using Shopify Payments avoids the second. Check your own plan's current rates on Shopify's pricing page rather than trusting a blog's numbers.
Rarely, if you count honestly. The subscription is the visible cost. The hidden one is permanently owning compliance, security, tax logic and uptime. Custom wins on capability, not on cost. If someone is making the case on cost alone, the arithmetic is usually missing the run cost.
Often, yes. Headless keeps Shopify's checkout, payments and compliance while letting you rebuild the front end, which is where most of the dissatisfaction actually lives. It is the middle option and it solves a surprising share of the problems people bring to a platform-exit conversation.
Longer than a Shopify build, and the gap widens with payments, tax and compliance requirements. The build is also not the end. A custom platform needs ongoing engineering in a way a Shopify store does not. Budget for the second year, not just the launch.