Shopify or a custom build: how to actually choose

The usual framing is flexibility versus convenience: Shopify is easy but limiting, custom is powerful but expensive. It sounds balanced and it is misleading, because it implies the two sit on one axis and you pick a point on it.

They do not. They fail in different places, and the question that decides between them is not "how much flexibility do we want" but "which specific constraints are costing us money right now".

This article is a decision framework rather than a comparison table — although there is a table, because some of it genuinely is a comparison.

What each option actually costs you

Start with what you are trading, stated honestly on both sides.

The bottom two rows are where most of the real cost sits, and they are the ones least often discussed before a decision. A custom build is not a project you finish; it is a system you now maintain. If nobody is going to own it in eighteen months, that is a stronger argument against custom than any technical consideration in this article.

The six questions that settle it

Work through these honestly. If four or more push toward custom, the case is real. If one or two do, you almost certainly have a fixable problem rather than a platform problem.

1. Does a product fit the product-and-variant model? — If your catalogue needs configurable options with computed pricing, time-based availability, or per-customer specifications, the platform is fighting you at the schema level. This is the strongest single indicator.
2. Is your pricing a function or a number? — Fixed prices with discounts are fine anywhere. Contract pricing, volume tiers, usage-based charges and negotiated rates are where hosted platforms need increasingly elaborate workarounds.
3. Does checkout need a step the platform does not allow? — Deposits, split payments, quote approval, purchase orders, or a mandatory data-capture step. Shopify's checkout extensibility covers more than it used to — check what it does now before assuming it cannot.
4. Is the storefront the system of record for anything? — If the store is the source of truth for stock, pricing or customer data rather than a view of it, you have more logic in the storefront than a hosted platform is designed to hold.
5. Can you fund ongoing engineering? — Not build cost — running cost. Security patches, dependency upgrades, browser changes, integration breakages. If the answer is no, hosted is correct regardless of the other five.
6. Have you ruled out the cheaper fix? — Slow storefront, bad search, painful integration and awkward merchandising are all usually fixable in place. Confirm they are not before rebuilding.

The cases where the answer is obvious

Stay on Shopify when

• Your catalogue is products with variants, and the variants are attributes rather than configurations.
• Checkout is standard: cart, address, shipping, payment.
• Your team is small and there is no permanent engineering capacity.
• You sell into markets Shopify Markets already handles.
• Your complaints are about theme performance, app sprawl or search quality — all fixable without leaving.

Build custom when

• Your product model needs dimensions the platform has no slot for.
• Pricing is computed per customer, per contract or per usage.
• Checkout requires steps or rules the platform will not permit.
• The storefront must hold business logic that belongs to you, not to a vendor.
• You have — and will keep — engineering capacity to own it.

Consider headless when

There is a third answer people forget: keep the commerce engine and replace only the front end. If your back-office model is fine and your complaint is entirely about the storefront — performance, design freedom, content flexibility, integrating a separate CMS — then headless commerce gives you the front-end control without taking on payments, PCI scope or order management.

It is the right answer more often than either extreme, and it is under-recommended because it is a smaller sale.

What “we've outgrown Shopify” usually turns out to mean

When a team says they have outgrown their platform, the sentence is doing a lot of work. Underneath it is almost always one of five specific complaints, and only two of them are actually about the platform.

Only the fourth row is a platform problem in the strict sense, and even it deserves one attempt at metafields and metaobjects before you conclude the model cannot bend. Shopify's structured-data capabilities have grown considerably, and a good deal of "our catalogue does not fit" turns out to be "our catalogue was modelled with tags in 2019 and nobody revisited it". We go through that properly in the Shopify development guide.

The fifth row is worth its own note because it is the most common and the least often diagnosed. A store where every content change is a ticket does not have a platform problem; it has a build problem. Replatforming with the same habits produces the same outcome on more expensive infrastructure.

The costs nobody puts in the business case

Both directions have expenses that reliably go missing from the comparison. Putting them in changes the answer often enough to be worth the hour.

Missing from the custom-build case

• Hosting, monitoring and error tracking, ongoing and growing with traffic.
• Dependency upgrades. Frameworks move; a codebase left alone for two years becomes expensive to touch, and security patches are not optional.
• On-call. Somebody answers when checkout breaks at 9pm on Black Friday. That is either a retainer or a salary.
• Compliance work you inherited — PCI scope decisions, cookie consent, accessibility, data retention.
• The second system. A custom build usually needs an admin interface for merchandisers, which is a product in its own right and is routinely forgotten in estimates.
• Rebuilding what apps were doing — reviews, loyalty, subscriptions, email flows — each of which was a subscription and is now a project.

Missing from the stay-put case

• Operational workarounds. Hours per week spent reconciling, re-keying or correcting because two systems cannot talk properly. This is usually the biggest number and it never appears in a software budget.
• App subscriptions, which compound quietly. Fifteen apps at modest monthly prices is a meaningful annual figure.
• Transaction fees at scale, which grow with success.
• Opportunity cost of the things you decided not to do because the platform made them hard. Hard to quantify, and often the real answer.

The exercise that settles most of these arguments: track, for one month, how many person-hours go into work that exists only because the platform cannot express something. Multiply by twelve. That number is what a custom build has to beat, and it is often larger than anyone expected — or much smaller, which is equally useful to know.

The mistake both directions make

Moving to custom for reasons that were never platform problems is the common one — performance, design, search — and it converts a fixable problem into a rebuild.

The opposite mistake is quieter and often more expensive: staying on a platform your model outgrew years ago, and paying for it in apps, manual work and workarounds nobody counts. A team spending two days a week reconciling data between systems because the platform cannot express a relationship is paying for a custom build every year without getting one.

Count that cost before deciding. It is usually invisible because it sits in operations rather than in a software budget.

Three businesses, three answers

The framework is easier to apply against examples. These are composites of situations we have been asked about, not client case studies — the point is the reasoning, not the outcome.

A fashion brand doing well on Shopify

Growing quickly, twelve apps, a slow storefront, and a team frustrated that every content change needs a developer. Considering custom because the site "feels limiting".

Answer: stay, and rebuild the theme. Nothing in the complaint is a platform constraint. Apparel is the canonical fit for a product-and-variant model, the slowness is app scripts, and the content frustration is a theme that was never set up for merchandisers. A theme rebuild and an app audit address every symptom for a fraction of the cost, and leave payments, PCI scope and peak-traffic capacity as Shopify's problem.

If the design ambition genuinely exceeds what a theme can express — and occasionally it does — a headless front end against the Storefront API is the next step, not a full custom build.

An industrial supplier selling configurable parts

Products with eight configurable dimensions, prices computed from a formula, per-customer contract rates, and stock held in an ERP that is the system of record. Currently running on a hosted platform with an elaborate quote-request workaround, because nothing can actually be bought online.

Answer: build custom. Four of the six questions point that way decisively. The catalogue cannot be enumerated into variants, pricing is a function rather than a number, the storefront needs to consume live ERP data, and the checkout has to support purchase orders and approval. This is the case custom development exists for — and the returning value is not a nicer website, it is that customers can complete a purchase at all.

A subscription business with 30,000 active subscribers

On Shopify with a subscription app, unhappy with the app's limitations around pausing, swapping and prorating. Tempted to build.

Answer: it depends entirely on question five, and the migration risk dominates. Subscription state is the hardest data in ecommerce to move: billing dates, payment tokens, dunning history and plan changes rarely migrate cleanly, and errors here charge real customers the wrong amount. The engineering to build subscription logic is tractable; the migration is where the risk is.

The realistic sequence is to evaluate whether another subscription platform solves it first, and if a build is genuinely needed, to migrate cohorts gradually with both systems running rather than switching everyone at once. That is a much longer project than the build estimate suggests, and pricing it as "build the feature" is how these go wrong.

What moving actually involves, in either direction

Whichever way you go, the move is a migration, and migrations have a fixed set of expensive parts. Worth knowing before the decision rather than after.

Moving to custom means the full replatforming checklist — URL mapping, redirects, data migration, structured data, customer accounts. Plus rebuilding whatever your apps were doing: reviews, loyalty, email flows, subscriptions. Each was a monthly subscription and is now a project, and this is the most commonly underestimated line in the whole exercise.

Moving from custom back to hosted happens more often than anyone advertises, and it is not a failure — it is usually a business recognising that it does not want to run software. The constraint is that your data model has to be squeezed back into the platform's, which is the hard part if the model was the reason you left.

Moving to headless is the smallest of the three, because the commerce back end does not change. Products, orders, customers and checkout stay where they are; only the front end is rebuilt. The URL and redirect work is the same, but the data migration largely disappears — which is a significant part of why it is the under-used answer.

Key takeaways

• The two options are not points on a flexibility axis — they fail in different places.
• The data model is the strongest deciding factor. Design freedom and speed are not.
• Custom is a system you maintain, not a project you finish. Fund the second year before starting the first.
• Headless is the under-used third answer when the storefront is the only problem.
• Staying too long on an ill-fitting platform costs real money — it just shows up in operations rather than in a software line item.