Shopify vs Custom Build: When Each Is Actually Right

Every few weeks someone asks us to quote a custom e-commerce build, and most of the time our answer is that they shouldn't buy one. That isn't modesty. The thing they're frustrated by is usually a theme problem, an app problem or an operations problem, and a ground-up rebuild fixes none of those while adding a payment integration, a tax engine and PCI compliance to their roadmap.

"Just use Shopify" is lazy advice too, though. There is a real category of business the platform will fight you on, and if you're in it, finding out eighteen months and four workaround apps later is expensive. Here's how we tell the difference on a scoping call.

Start from what Shopify is actually selling you

The monthly fee is the least interesting part of the platform. What you're buying is the work nobody enjoys doing: PCI compliance, fraud scoring, a checkout that stays up on Black Friday, tax rules across jurisdictions that change without notice, shipping label generation, and payment rails that already work in the countries you sell into. Rebuilding that responsibly is a year of engineering before you sell anything.

Shopify also runs the checkout itself, and that cuts both ways. You get a page conversion-tested across millions of stores. You also don't own it, and that single fact decides most of the cases below.

Where the money actually goes

Founders tend to compare the monthly plan fee against a $60,000 build and conclude the platform is cheap. The plan fee is rarely the number that matters.

• Percentage fees scale with revenue and never stop. Card processing applies to every order, and if you use a gateway other than Shopify Payments, Shopify charges an additional transaction fee on top: 2% on Basic, 1% on Grow, 0.6% on Advanced, 0.2% on Plus.
• Apps are the line item that surprises people. Most stores end up with a handful of paid ones for reviews, subscriptions, bundles and search, and published app-cost surveys put typical spend between roughly $50 and $300 a month, climbing steeply past a few million in revenue.
• Plus, the tier most serious customization requires, starts at $2,300 a month on a contract.
• Theme and development work, which you'd pay for on any route.
• Plan limits that turn into costs later: inventory locations, staff seats, B2B catalogs and API rate multipliers all step up by tier, and Advanced-to-Plus is a large step.

At a million in annual revenue the percentage fees alone are real money, and that's the point where founders start pricing rebuilds. It rarely pencils out, because a custom build has percentage fees too (Stripe doesn't work for free) plus hosting, monitoring, security patching and a permanent maintenance line. The honest comparison is platform fees against a standing engineering commitment, and the platform stays cheaper well past the revenue level most people guess.

The four things that genuinely break on Shopify

These are constraints we've hit on real client work, not a list of theoretical drawbacks.

1. You need to own the checkout

This is the most common reason a serious brand outgrows the platform, and it got sharper this year. checkout.liquid, the old way of editing checkout markup, was only ever available on Plus and is now unsupported for the information, shipping and payment steps. Script tags on the thank-you and order-status pages were sunset for Plus stores in August 2025 and are scheduled to sunset for everyone else on 26 August 2026, which is weeks away as this goes up.

Shopify Scripts went the same way. It was sunset on 30 June 2026, and anything still published simply stopped running. The supported replacement is Shopify Functions, compiled WebAssembly that runs inside Shopify's own infrastructure, plus checkout UI extensions for the visual layer. Functions delivered through a custom app require a Plus plan; public apps carrying Functions work on any plan.

None of that is bad engineering on Shopify's part. A sandboxed, versioned extension model is exactly why their checkout stays fast and hard to break. But it means the answer to "can we do X at checkout" is now "only if X fits an extension point Shopify has published." If your business depends on a checkout step nobody else needs, a credit check, a prescription verification, a contract price that a human has to approve, you are either on Plus writing Functions or you are off-platform.

2. Your catalog is a configuration, not a list

Shopify models products as variants, and that model recently got much roomier. The ceiling went from 100 to 2,048 variants on 15 October 2025, on every plan, which retired the single most-cited reason to leave. What didn't change is the number of options a product can have, still three. Size, color, material, and you're full.

So the catalog question is no longer "how many SKUs." It's whether your product is a SKU at all. Made-to-measure furniture, print priced live by dimension, industrial parts selected by compatibility rather than by attribute: those are configurators with a pricing function behind them, and pre-generating them as variants is a losing fight however high the ceiling goes. That logic has to live somewhere, and it doesn't have to mean leaving Shopify. More on that below.

3. You're not a single seller

Shopify is built for one merchant selling their own inventory. A marketplace needs vendor accounts, commission rules, split payouts and orders that fan out to several fulfillers, and none of that exists natively. You can bolt it on with apps, and plenty of businesses have. You then have your core economics running inside a third-party app you don't control, on a platform with no particular reason to support your model long term.

This is the clearest custom-build case we see. If vendors, commissions and payouts are your business rather than a feature of it, build the thing properly. Open-source commerce engines like Medusa mean you're not starting from an empty repository, and marketplace-specific starters built on it already handle vendor dashboards and split payouts.

4. The ordering logic is the product

Complex B2B is the other honest case. Shopify's B2B tooling has improved and price lists cover a lot of ground, but there's a point past which quoting, approval chains, credit limits, contract pricing that varies by customer and volume, and an ERP that owns the truth about stock all have to work together. When the commerce logic is the differentiator rather than the plumbing, running it inside someone else's admin gets painful.

A practical early signal here is API pressure. Shopify's GraphQL Admin API is rate limited on a calculated query-cost budget, and the ceiling scales by plan: Advanced gets roughly twice the standard rate and Plus roughly ten times. Storefront traffic from real buyers isn't capped the same way, so this bites integrations rather than shoppers: nightly ERP syncs, bulk price recalculations, inventory pushes across many locations. If you're designing around the rate limit before launch, that's information worth acting on.

The option most teams skip

The choice isn't binary, and the middle is where most of our e-commerce work lands. Keep Shopify as the commerce engine for checkout, payments, tax and orders, and build custom precisely where the constraint is:

• A custom storefront on the Storefront API with Shopify still owning checkout. That's headless.
• Custom services running alongside the store for the logic that doesn't fit: a configurator, a pricing engine, a vendor portal, an ERP bridge, each talking to Shopify over the Admin API.
• A custom app with Functions, if the gap is specifically checkout logic and you're on Plus.

Headless deserves a warning, though, because it gets sold as a performance upgrade and bought for the wrong reasons. Real builds run from around $10K for something minimal to $150K and beyond for a full composable project, with meaningful monthly maintenance after launch, and you lose the theme editor your marketing team uses every day unless you wire up a headless CMS to replace it. The same breakdown puts payback for a mid-market build at 12 to 18 months and argues that below roughly $5M in revenue, that budget spent on conversion work and acquisition returns more. That matches what we've seen.

The question was never whether Shopify can do it. With enough apps and enough patience, Shopify can do almost anything. The question is what you'll be maintaining in three years, and who owns the part your business depends on.

What each route costs, honestly

• Shopify with a good theme and a disciplined app stack: platform fees plus a build in the low tens of thousands, live in weeks. Right for most brands, and right for longer than people assume.
• Shopify plus custom services around it: same platform fees, plus a scoped build for the one thing that doesn't fit. Usually the cheapest way to solve a genuine constraint.
• Headless on Shopify: $10K to $150K and up depending on scope, plus ongoing maintenance and a CMS decision you now own.
• Fully custom: commonly quoted at $20K to $150K and beyond to build, hosting and maintenance on top, and compliance, uptime and payment integrations become permanently yours.

Those ranges are wide because scope is wide. The same logic we set out in how much an MVP actually costs applies here: any number quoted before someone has written down what you're building is a guess, so get the scope first.

The test we run on a scoping call

Five questions, in this order:

• Does the thing you can't do live at checkout? If yes, the real options are Plus with Functions, or leaving. There isn't a third answer.
• Is your product a SKU or a configuration? Configurations need a pricing engine somewhere, on-platform or beside it.
• Do you take money on behalf of anyone else? If yes, you're a marketplace, and Shopify wasn't built for that.
• Does an ERP or pricing system already own the truth? Then you need an integration budget, not necessarily a new platform.
• What breaks first if you grow five times: the platform, or your operations? It's almost always operations, and no rebuild fixes that.

If none of those land, the honest recommendation is to stay where you are and spend the money getting more people to the cart. We've given that answer and lost the bigger project. It was still the right call.

Where we land

Most of the e-commerce work we take on is Shopify build and customization, because for most retail brands that's the version that ships fastest and costs least to run. The custom builds we do accept are the ones where a specific mechanic, a configurator, a vendor model, a pricing engine, is the actual business. Even then we usually keep Shopify underneath for payments and orders instead of rebuilding what's already solved.

If you're weighing this up, the useful next step isn't a proposal. It's a call where we ask the five questions above and tell you which side you're on, including when that means you don't need us. See what we've shipped, or send us the constraint you're stuck on and you'll get a written scope and a fixed quote before any commitment.