Where Shopify's checkout stops bending

The boundary is a plan, not a feature

Shopify's help docs draw a hard line down the checkout. Apps built with web pixels, post-purchase extensions, and public Shopify Functions work on Basic and up. Apps that customise the information, shipping, and payment pages, and custom apps built with Shopify Functions, are Plus only. So a merchant on the Advanced plan can restyle the thank-you page and install a public discount app, but cannot ship their own function that prices a bundle the way their business actually prices it.

That upgrade is priced. Shopify's pricing page today lists Advanced at $299/month paid yearly, $399 monthly, and Plus starting at $2,300/month with no yearly discount shown. Third-party payment fees drop from 0.6% to 0.2% across that jump, which claws some of it back at volume. Run the arithmetic and the 0.4% saving only covers the $1,900 monthly difference at about $5.7M a year in third-party-processed sales. Below that, and if you use Shopify Payments the fee saving is zero, you are paying the difference for the right to write your own checkout logic.

Even on Plus, functions run on a fuel gauge

Pay for Plus and you get Shopify Functions, which run your code inside the checkout. They run inside published limits: 11 million WebAssembly instructions per execution, 128 kB of input, 20 kB of output, a 256 kB compiled binary, and 10 MB of linear memory. Shopify now scales some of those proportionally for carts over 200 line items, and it recommends Rust over JavaScript specifically so you stay inside the instruction budget.

The input query has its own budget of 30 points, and reading a metafield costs 3 whether you need one field from it or ten. Shopify's own guidance is to pack configuration into a single JSON metafield rather than read several, and to avoid aliasing an expensive field. That is a real constraint on how much context your pricing logic can see. Merchants hit the instruction limit years ago on wholesale carts: a developer on Shopify's own examples repo measured a TypeScript discount function running out of fuel at 34 cart lines, and a hand-tuned C++ version at 69.

None of this is sloppy engineering on Shopify's part. A function that runs on every checkout in the world needs a fuel gauge. But it means the thing you are buying at $2,300/month is bounded extensibility, and the bound is not negotiable by paying more.

What the workarounds actually cost

The shape of the problem is familiar from the Stay World Class migration. That stack was Webflow and Xano rather than Shopify, and the app worked. What had accumulated was a layer of workarounds keeping the logic inside a platform that could not express it. Replacing it with Next.js, NestJS, and Supabase moved Lighthouse from 55.91 to 91 out of 100 and cut LCP by 77%, and the hard part was never the new code. It was a four-stage ETL that mapped legacy IDs to PostgreSQL UUIDs so that years of history survived the move intact.

For commerce, the honest version of that arithmetic starts with counting workarounds. Add up the apps installed only to work around a checkout limit, their monthly fees, the engineering time spent making them agree with each other, and the plan upgrade you took to unlock a function. In 2026 a custom checkout flow on Stripe or Adyen is a few weeks of AI-assisted work, not a quarter. When the workaround column crosses that, the platform is costing more than it saves.

The catch nobody mentions: Shopify checkout converts well because Shop Pay already has the customer's card. You do not inherit that. Anyone quoting you a rebuild should model the conversion loss, not wave it away.

When staying on Shopify is the right answer

If your checkout is a cart, a shipping rate, a discount code, and a payment, stay. That is the case Shopify has optimised for harder than anyone, and you will not beat it with a custom build. The same goes if your unusual logic fits inside a function: 11 million instructions is a lot of room for most rules, and Plus is cheap next to an engineering team.

Migrate when the logic genuinely does not fit. Complex B2B pricing tiers, usage-based billing, multi-party splits, contract-specific catalogues that need to be queried rather than duplicated. If you are on Advanced and eyeing Plus purely to write one function, price both paths before you commit to either. And if you are on Shopify and it works, the right move today is to write down which workarounds exist and what each costs. Not to move. Just so the decision is made with numbers when it comes.