Shopify is excellent at the parts of ecommerce that are expensive to build and dull to maintain: hosting, checkout, payment processing, PCI scope and a working app ecosystem. It becomes a constraint when your catalog, integrations or checkout logic push against documented platform limits. For most stores, the right answer is to stay and extend it deliberately rather than rebuild.
What does Shopify do genuinely well?
Shopify absorbs the operational risk that sinks self-hosted stores. You do not patch servers, renew certificates, size infrastructure for a flash sale, or carry the full weight of card data compliance. On Black Friday your storefront is Shopify's problem, not yours, and that is worth more than most founders realize until the first time a home-built store falls over during a promotion.
The read path is genuinely fast at scale. Shopify's own documentation states that the Storefront API has no rate limits applied to the number of requests and is built to handle surges in buyer traffic. That matters strategically: browsing, search and product pages scale, so the interesting architectural decisions all sit on the write side.
The app ecosystem counts for the same reason. Reviews, subscriptions, loyalty, shipping labels and tax exist as installable apps that work on day one, and building any one of them properly costs more than a year of subscriptions.
How Shopify's fees are actually structured
Three separate charges apply, and only one of them is really a Shopify commission. You pay a fixed monthly plan fee that does not vary with the sale, a card processing rate on the transaction itself, and, if you use a payment gateway other than Shopify Payments, an extra per order percentage that Shopify keeps for routing around its own processor. Those rates differ by country, by plan tier and by year, so read the current numbers off Shopify's own pricing page and help center for your market rather than from any review, including well maintained independent ones such as Style Factory's Shopify fees guide.
The structure survives whatever the current percentages are. The card processing rate is charged by whichever processor handles the card, so you would pay some version of it on any platform. The gateway override is the charge unique to Shopify, and it applies to every order for as long as you stay, scales directly with revenue, and buys you no feature. It only appears when Shopify Payments is unavailable in your country or you are contractually tied to another acquirer, so model it as a percentage of annual revenue, alongside per order app pricing, before you compare Shopify's total cost to anything custom.
Where does Shopify actually become a constraint?
Not at traffic. Almost always at write throughput and integration shape. Shopify publishes its limits, and the numbers explain most of the pain that growing stores describe as "our sync is slow".
| Plan tier | GraphQL Admin API | Customer Account API | What it affects |
|---|---|---|---|
| Standard plans | 100 points/sec | 100 points/sec | ERP and inventory sync speed |
| Advanced Shopify | 200 points/sec | 200 points/sec | Bulk catalog updates |
| Shopify Plus | 1,000 points/sec | 200 points/sec | Admin writes, not customer portals |
| Enterprise (Commerce Components) | 2,000 points/sec | 400 points/sec | High volume multi-system estates |
Those figures come from Shopify's API limits documentation, which also sets two ceilings that no plan removes. A single query may not exceed a cost of 1,000 points regardless of plan, and any input argument that accepts an array is capped at 250 items. The array cap is the one that binds first on bulk work: a product information system pushing 5,000 variant price changes cannot pass them as a single input array on any plan, because anything over 250 items returns an error. It has to be chunked, queued and retried, which is engineering work that a plan upgrade does not buy you out of.
Two further details help when you are diagnosing a slow integration. Admin API limits are scoped to the combination of app and store, so a badly behaved third party app is not stealing your custom app's capacity. And every response returns its throttle and cost data under the extensions key, which makes "are we being throttled" a measurable question rather than a hunch. Shopify also limits how many checkouts can be created per minute through the Storefront API, which is the limit to check if a viral drop stalls at the moment of purchase.
The checkout.liquid deadline you may still have
If anyone ever pasted a tracking script or a custom block into your checkout, you probably have migration work with a date attached. Shopify's checkout.liquid documentation confirms that checkout.liquid is already unsupported for the Information, Shipping and Payment steps, and that checkout.liquid and additional scripts were sunset for the Thank you and Order status pages on August 28, 2025.
Script tags follow the same path on a split schedule: sunset on those pages on August 28, 2025 for Plus stores, and on August 26, 2026 for non-Plus stores. The replacement is Shopify Extensions in Checkout, which is a better architecture than injected Liquid and also a rewrite rather than a copy and paste. Budgeting for occasional forced migrations like this one is part of the true cost of a hosted platform, because you do not control the roadmap.
Does Shopify Plus fix it?
Plus fixes admin throughput and very little else about the limits above. Shopify's developer changelog describes the Plus increase as 10x the standard Admin API rate limits and says Commerce Components merchants get unlimited API calls, while the current limits page lists concrete numbers instead (1,000 points per second for Plus, 2,000 for enterprise), so treat the limits page as authoritative and the changelog as evidence that the ceilings move upward over time.
What Plus does not change is more instructive. The Customer Account API sits at 200 points per second on both Advanced and Plus, so a heavy customer portal, a returns center or a B2B reorder screen hits the same ceiling after the upgrade. The 1,000 point single query cap and the 250 item array cap are plan independent.
Choose Plus if your constraint is admin write volume, checkout logic that needs Shopify Functions, or multi-store and B2B features. Do not choose Plus if your constraint is customer-facing account data, a product model that does not fit variants, or an app stack that is expensive because it is doing the wrong thing.
Signals it is time to extend or rebuild
Make the decision on measurements, not frustration. Each of these is checkable this week:
- Sustained throttling. Log the cost and throttle values from the extensions key on your integration calls. If you queue behind the limit during normal business hours, not just during a nightly bulk run, you have outgrown your plan or your integration design.
- Chunking everywhere. If most of your catalog and inventory code exists to work around the 250 item array cap and the 1,000 point query ceiling, your data model is fighting the platform's.
- App spend versus build cost. Total the subscriptions for apps that exist only to approximate one business rule. When that annual figure approaches the cost of building the rule once, building is cheaper and it stops breaking on someone else's release schedule.
- Manual steps in the order path. Anyone retyping data between Shopify and a warehouse or accounting system is a defect with a salary attached.
- Products that are not really products. Configured goods, quoted work, contract pricing and approval chains do not model well as variants, however many metafields you add.
The usual right move is not a rebuild. It is keeping Shopify for checkout, payments and fraud while moving the awkward logic into a custom app or service beside it: an integration layer to your ERP, a B2B portal with negotiated pricing, or a headless front end that takes advantage of the unmetered Storefront API. That pattern covers most serious Shopify development work, and often the honest recommendation is to change nothing but the app stack. If the product model itself is wrong, a custom commerce application becomes the answer, and our guide on build versus buy for core systems works through the same trade in the back office.
Common mistakes
Upgrading the plan to fix an app problem. Plan tiers change API throughput and feature access. They do not make an inefficient third party app efficient, and Admin limits are scoped per app anyway.
Rebuilding the storefront because the admin is slow. These are different systems with different limits. Read traffic is not the constraint, so a headless replatform aimed at speed often solves nothing that mattered.
Ignoring dated deprecations. The August 26, 2026 script tag sunset for non-Plus stores is scheduled work. Discovering it after your conversion tracking goes quiet is the expensive version.
Deciding without an exit read. Before committing further, confirm you can export products, customers and order history, and that subscription, loyalty and review data is retrievable. Lock-in is rarely the platform. It is usually the data trapped inside apps.
Pull one week of throttle and cost data from your integration's API responses, and put your app subscriptions in a spreadsheet next to it. Those two numbers tell you whether you have a plan problem, an app problem or a platform problem, and that is the only fork in the road that matters.