Let's start with the honest answer: Shopify is the right choice for most e-commerce businesses at most stages of their growth. It's fast to launch, the ecosystem is mature, and the infrastructure is genuinely good. If you're under $2M in revenue and primarily selling to a single market, the odds are high that Shopify is the best place to be.
This article is not about why you should leave Shopify. It's about how to recognise the specific moments when staying starts costing you more than moving would.
What Shopify actually does well.
The fastest path from zero to a functioning store with real sales is still Shopify. That matters more than most technical people acknowledge. You get a reliable checkout, Shopify Payments, a massive app ecosystem for every capability you might need, and infrastructure that doesn't fall over during a sale event. For $0 to $5M in annual revenue, that combination is hard to beat on pure economics.
Shopify's limitations are not a reason to avoid the platform. They're a reason to understand where the ceiling is — so you're not surprised when you hit it.
The three real limits — not vendor FUD.
There's a lot of noise about Shopify's limitations that overstates the problem. What follows are the three constraints that actually matter in practice, the ones we see cause real pain at scale.
1. Checkout customisation is a hard ceiling. Shopify's checkout is locked. You can change colours and fonts. You cannot change the flow, the fields, the step structure, or the logic that governs what happens when. For most direct-to-consumer brands, this is fine — Shopify's checkout converts well and has years of optimisation behind it. But for businesses with complex checkout requirements — B2B net-30 payment terms, custom approval workflows, subscription bundle configuration, or purchase order inputs — the locked checkout is a genuine ceiling that no app fully solves. You can bolt things onto it, but you cannot change what it fundamentally is.
2. Custom pricing and catalogue logic breaks under complexity. Shopify handles straightforward pricing well. Tiered bulk pricing, customer-group-specific pricing, multi-currency with custom rules per country, and conditional product visibility by account type — these are the cases where Shopify's data model starts to show its seams. Every workaround involves an app, and apps have performance costs, maintenance costs, and interaction costs with each other. A single pricing app is manageable. Three overlapping pricing apps trying to work together is not.
3. Data ownership becomes a constraint at scale. Your data lives in Shopify's schema, accessed through Shopify's API, which has rate limits and a fixed structure. At $500k in revenue, this is a non-issue — you're probably not running sophisticated analytics pipelines. At $10M, when you're trying to build custom reporting, wire up an ERP, or run bespoke attribution models, the API becomes the bottleneck. The data is technically yours but practically trapped in a format and access model that Shopify controls.
The signals that it's time to look elsewhere.
Abstract limitations are hard to act on. These are the concrete signals we look for when a business asks whether they've outgrown Shopify:
Your Shopify app bill exceeds $500/month. This is a leading indicator, not a definitive answer — but it means you're solving real business problems through app accumulation rather than through platform capability. Each app is a workaround for something the platform doesn't natively do, and workarounds compound.
Your checkout has a multi-step workaround for something that should be native. If you're using a combination of draft orders, custom scripts, and a third-party checkout extension to handle something that is a standard feature of how you sell — B2B pricing, bundle configuration, net terms — you're paying a hidden tax in maintenance and customer experience degradation every day.
Your operations team has manual steps that exist because of platform limitations. When the people running the business have a routine that includes "then we manually export the CSV and re-import it because Shopify doesn't connect directly to the ERP," the platform has started generating operational overhead. That overhead scales with revenue.
You're building your third custom middleware integration. One middleware integration between Shopify and an external system is normal. Three means you're maintaining a bespoke integration layer that has to be kept in sync every time either Shopify or the external system updates. That's engineering time that isn't building the business.
International expansion is stalled. If the reason you haven't launched in a new market is checkout localisation, tax handling, or currency logic — and those problems have been on the roadmap for more than six months without resolution — the platform is the blocker, not the plan.
What "custom" actually means.
When we say a business needs a custom e-commerce solution, we don't mean building an e-commerce platform from scratch. That would be a multi-year project at costs that almost no merchant can justify.
In practice, "custom" usually means one of two things. The first is headless Shopify: Shopify continues to run as the back-end — handling orders, inventory, Shopify Payments, fulfilment — but the storefront is replaced with a custom-built frontend, typically in Next.js or a similar framework. This gives full control over the customer experience, the performance characteristics, and the checkout flow up to the point of payment, while preserving the Shopify infrastructure that works well. The Shopify checkout can be preserved even in a headless setup — you're replacing what happens before the checkout, not the checkout itself.
The second is a full platform migration: moving from Shopify to a commerce layer — Medusa, Commerce.js, a custom-built stack on Stripe — where the data model, the business logic, and the checkout are all owned. This is appropriate for businesses where Shopify's data model is the constraint, typically at higher revenue levels or with genuinely complex catalogue and pricing requirements.
We've done both. For Stef Sotra, an industrial B2B supplier expanding across 190+ countries, the standard Shopify setup couldn't handle the per-country pricing logic, net-terms checkout, or the ERP integration the business required. The result was a custom platform built around the specific requirements of B2B industrial supply — not a theme with apps on top of it. For Sigma Beauty, the problem was different: years of app accumulation had made the store slow and fragile, but the core Shopify setup was sound. The fix there was an architectural rebuild within Shopify's ecosystem, not a migration away from it.
The distinction matters: most businesses that think they need to leave Shopify actually need a better Shopify implementation. The ones that genuinely need to leave have hit one or more of the three hard limits above and can demonstrate the business impact.
When not to go custom.
Under $2M in revenue, the economics of a custom build rarely make sense. The development cost, the ongoing maintenance, and the loss of Shopify's ecosystem benefits add up to a number that is hard to recover against the performance improvement. There are exceptions — a B2B business with genuinely complex requirements from day one might need custom infrastructure earlier — but they're exceptions.
If you're still validating product-market fit, a custom build is the wrong conversation entirely. The ability to move fast, add features through apps, and change direction without an engineering sprint is worth more than platform control at that stage.
If your store is slow and you're frustrated, the answer is almost certainly not leaving Shopify. A slow Shopify store is usually a fixable Shopify store — app audit, image optimisation, theme cleanup, script consolidation. We've taken stores from a 38 PageSpeed score to 90+ without changing the platform. The platform is rarely the reason for poor performance; the implementation is.
The decision framework.
The question isn't "Shopify or custom?" as an abstract platform preference. It's: "What is the platform costing us that we can't solve within it, and does the cost of custom development pay back against that over a reasonable time horizon?"
If the honest answer to that question points toward custom, then the next question is which flavour of custom — headless Shopify, a full migration, or something in between — based on where the specific constraints are.
If the honest answer is that the problems are solvable within Shopify, the right move is to solve them within Shopify. Platform migrations carry real risk and real cost. They're worth it when the constraint is genuine. They're not worth it when the constraint is an implementation problem dressed up as a platform problem.