Shopify is very good at commerce, which is exactly why this decision is hard. The question is not whether it works, it is whether your margins, your checkout and your business logic still fit inside it. Here is where the platform genuinely wins, where the costs quietly accumulate, and how to tell if you have actually outgrown it.
When Shopify is the right answer, and when you should not hire us
Shopify is not a compromise. It solves problems that are genuinely expensive to build: card processing, PCI scope, 3D Secure and SCA in Europe, fraud screening, chargebacks, tax determination across jurisdictions, carrier rates and shipping labels, multi currency, inventory across locations, and an admin your staff already knows. None of that is glamorous. All of it takes months to get right and never stops needing maintenance.
If your catalog is a normal list of products with simple variants, your checkout is a normal checkout, your marketing runs on a handful of apps you actually use, and your order volume does not make percentage fees painful, stay where you are. Rebuilding to escape a subscription is a bad trade. So is rebuilding because the site looks dated: a theme rebuild on Online Store 2.0 is a far smaller project and solves that particular problem completely.
Do not hire us if you want someone on a weekly call, if you need a partner physically in your city, or if nobody on your side can write a clear brief and decide in writing. We work asynchronously and only in writing. That suits some teams and frustrates others, and it is better to know that now than three weeks into a build.
Where the cost accumulates: percentage fees and the app stack
The monthly subscription is rarely what hurts. Three other lines do.
First, percentage fees. If you process with Shopify Payments you pay a card rate; if you bring an external gateway, Shopify adds a platform fee on top, historically around two percent on the entry plan and falling on the higher tiers at the time of writing. Read your own invoices rather than the pricing page, because rates differ by country and by contract. A fee that is invisible at low volume becomes a line your finance team asks about once you ship thousands of orders a month.
Second, the app stack. Reviews, email and SMS, loyalty, bundles, subscriptions, search, back in stock, upsell. Most of them price on usage rather than on a flat fee: Klaviyo bills on profile counts and sends, subscription apps take a percentage of subscription revenue plus a platform fee, search tools bill on queries or catalog size. Your software cost therefore grows on exactly the metric you are trying to grow, and unlike a build, it never ends.
Third, the tier jump. Full checkout customization, B2B catalogs and the heavier scripting features sit behind Shopify Plus, which is quoted per contract in the low thousands of dollars per month at the time of writing. Plenty of rebuilds start not when the entry plan gets expensive, but when a founder reads the Plus quote and asks what else that money could buy.
Checkout, business logic and the limits you meet in production
Checkout is the sharpest boundary. Shopify hosts it, which keeps your PCI scope small and is exactly why you cannot do whatever you like with it. Since checkout.liquid was retired, customization goes through Checkout Extensibility: UI extensions that render in defined slots, and Shopify Functions for discount, delivery and payment logic. Functions run as WebAssembly against a hard instruction budget, their input is a fixed GraphQL query, and they have no network access. If your pricing rule needs to ask an external service what this customer pays today, that rule does not fit.
The second wall is data modeling. Variants are a combinatorial grid. That works for size and color. It breaks for configurable products where one option constrains another, or made to measure items priced from a formula. Metafields and metaobjects cover a lot, but filtering and faceting on them in the storefront depends on what your search layer supports.
Integration has its own failure modes. The GraphQL Admin API is rate limited by calculated query cost against a leaky bucket, so a naive ERP sync that walks orders in a loop throttles in production and never in staging; large catalog reads belong in the Bulk Operations API. Webhooks are delivered at least once, out of order, with retries that give up after a couple of days, so every consumer has to verify the HMAC, be idempotent, and sit behind a reconciliation job for the events that never arrive. None of this makes Shopify a bad platform. It makes it a platform with a shape, and your business either fits that shape or fights it.
Front-end performance: what a theme controls, and what it does not
Shopify renders Liquid on its own infrastructure and serves assets from its CDN, so time to first byte is usually fine. The damage happens later, in the browser, and it is almost always JavaScript you did not write.
The pattern repeats in every audit. Marketing installs an app, the app injects a script on every page, and Interaction to Next Paint degrades over two quarters. Shopify moved tracking into the sandboxed Web Pixels runtime, which helps, but app embeds and leftover script tags still land on the main thread, and older apps that wrote directly into theme.liquid leave fragments behind when you uninstall them. You end up with a review widget, a chat widget, a consent banner, a personalization script and two tag managers fighting for the same thread, while Largest Contentful Paint suffers because the hero image is loaded by a slider that boots in JavaScript.
Most of that is fixable inside a theme: audit the script tags, defer everything below the fold, delete apps you stopped using, replace an app with twenty lines of Liquid. Do that before you conclude the platform is the problem, because usually it is not.
What a theme will never hand you is the rendering pipeline itself: your own caching strategy, your own bundle, your own line between server and client. If Core Web Vitals are a business constraint rather than a dashboard you glance at once a month, that is the real argument for moving the front end. The fee schedule is not.
The hybrid path: keep Shopify as the engine, own the front end
The choice is not binary. You can keep Shopify for orders, inventory, payments, tax and the admin your team already uses, and build the storefront against the Storefront API with Hydrogen, Next.js or anything that speaks GraphQL. The cart lives in Storefront API cart mutations, the customer is handed to Shopify's hosted checkout at the end, and your PCI scope stays exactly where it was. You gain control of rendering, caching and routing, and you keep the parts that would take a year to rebuild badly.
Be clear about what you give up. The theme editor stops being how the site gets changed, so anything marketing wants to edit has to be built as editable content on purpose: metaobjects, a headless CMS, a customizer. A meaningful share of apps only work by injecting into a Liquid theme, so audit your app list before you commit, not after. Hosted customer accounts only bend so far. And you now own invalidation: a stale price on a cached product page is a real support ticket, so plan webhook driven revalidation from day one, and decide in advance what the page does when a webhook arrives late.
Going fully custom is the right call when the business logic is the product: per customer pricing, quotes, contract catalogs, deep ERP coupling. It also means you inherit SCA and 3D Secure, tax determination, fraud rules, partial refunds, overselling under concurrent checkout, carrier rates and returns. That inheritance is the honest cost of leaving, and it should be a decision about capability, not about invoices.
How two people in Dijon work with a client eight time zones away
There are two of us. Robin Monteiro writes the code, Next.js and React. Florian Loppion handles marketing and acquisition. One office, at 9 rue Jean-Jacques Rousseau in Dijon, France, and none anywhere else. There is no account manager between you and the person typing, which for an international client is a fair trade: you deal with the builders, and nothing gets lost in relay.
Everything happens in writing, by email. No calls, no video, no scheduled slots, not even as an option. That is a hard policy, and outside France it tends to be the part clients like best. A founder in California never takes a call at 3am to accommodate Central European Time. A team in Bangalore is not holding an evening slot open. You write when it suits you, we reply within 24 business hours, and the work moves while you sleep.
The second benefit is boring and enormous: every decision is searchable. Why checkout behaves that way in Quebec, who signed off on the cutover date. Six months later it is a thread you can find, not somebody's recollection of a call nobody wrote up.
What changes on your side: write the brief properly, decide in writing, and batch feedback against a staging URL instead of drip feeding reactions. Teams used to reaching for a call find the first couple of weeks strange. Most stop noticing. The businesses we work with (Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats, Vectosolve) are French SMEs, and the method is the same whoever you are. Pricing is on request, there is no mandatory subscription, and the code, the accounts and the domain name are yours.
