Shopify Plus or a custom build?

This question usually arrives from a brand that has outgrown its plan and been given two very different answers by two very different vendors. One says upgrade to enterprise and stop worrying about infrastructure. The other says you are big enough now to own your stack and stop paying a percentage. Both are pitching a real product, and neither is describing your business.

The decision is not really Plus versus custom. It is: which parts of your commerce stack are you willing to be a tenant in, and which do you need to own? Once that is answered, the platform question answers itself.

What an enterprise commerce plan actually buys you

Set aside the feature list, which changes, and look at what you are actually paying for.

Infrastructure you never think about again. Uptime, scaling, security, PCI scope, patching. On the day your campaign goes viral, that is somebody else’s emergency. If your revenue is concentrated into a handful of trading days, this alone can justify the tier.

A checkout you are permitted to extend. Enterprise tiers open up checkout customisation in ways lower plans do not. This matters more than any other single feature, because checkout is where the money is and where you were previously locked out.

Higher limits and better automation. Staff accounts, API call ceilings, workflow automation, multiple storefronts under one account. Unglamorous, and the difference between a team of four operating comfortably and a team of four working around limits.

Multi-store and multi-market. Several storefronts, currencies and markets managed as one estate rather than as several projects.

A commercial relationship. A named contact, a support path, and a merchant success function. Worth genuinely more than people expect the first time something goes wrong at 9am on Black Friday.

A lower percentage. The fee steps down at higher tiers. On real volume, the difference between tiers can cover a meaningful part of the subscription.

Where it stops

Three boundaries, and they are the only three that matter.

The data model. Products, variants, collections. If your business sells something that is not shaped like that — configured goods priced from dimensions, service-and-product bundles, contracts, rentals, anything where a “product” is really a specification — you will spend forever translating your business into the platform’s nouns. Metafields and metaobjects go a long way. They do not go all the way.

The transaction fee, at very large volume. A percentage is a percentage. At sufficient scale the arithmetic that made the platform obviously correct starts to invert, exactly as it does further down the curve for smaller stores.

Deep operational integration. If commerce has to sit inside a larger system — an ERP that is the source of truth for pricing and stock, a manufacturing pipeline, a regulated audit trail, a bespoke B2B approval workflow — you eventually reach a point where the store is a component of a bigger application, and building it as a component is cleaner than bending a platform into one.

Everything else people cite as a limitation is usually a theme problem or an app problem in disguise.

What “custom build” actually means

The phrase covers three very different projects, and conflating them is why quotes for “custom” range so wildly.

Custom storefront, platform commerce. A bespoke front end over a commercial commerce engine. This is headless, and it is a storefront decision rather than a platform decision — we go through the threshold for it in headless commerce: worth it or expensive.

Open-source commerce, self-hosted. Building on an existing open commerce framework. You own the deployment and the data model; you do not write a cart from first principles. This is what most sensible “custom” projects actually are.

Genuinely bespoke commerce. Writing the commerce logic itself — catalogue, pricing, cart, order lifecycle, tax, fulfilment. This is a product build, not a website build. It is correct for a small number of businesses whose commerce logic is the business, and catastrophic for everyone else.

If somebody is quoting you “custom” without telling you which of the three, that is the first question to ask.

The four questions that decide it

One: is your commerce logic a differentiator or a cost? If how you price, bundle and fulfil is genuinely part of your competitive advantage, owning it is defensible. If it is the same as everybody else’s with different products, renting it is obviously correct.

Two: will you have an engineering team in three years? Not an agency for the build — a permanent capability. Custom commerce is a product you now maintain forever, including the security of the payment path. If the honest answer is no, the decision is made.

Three: does the fee arithmetic clear the fixed cost, with margin? Run it over five years, including engineers, infrastructure, security, compliance and the on-call rota. It has to clear comfortably, not narrowly, because you are also buying risk.

Four: is there a hard constraint, or a set of preferences? Preferences are expensive to build around. A hard constraint — a regulator, a data-residency rule, an ERP that cannot be secondary, a product model the platform cannot express — is a reason. A list of things you would like differently is not.

The five-year comparison

Enterprise plan: subscription, transaction percentage, apps, agency or in-house front-end work, integrations. Predictable, largely variable, and it goes up as you grow.

Custom build: a larger upfront build, then infrastructure, security, compliance, monitoring, and — the line that decides it — engineers. Not one; a team, because a single person owning your commerce stack is a business continuity problem rather than a solution.

The crossover exists. It sits much further up the revenue curve than custom vendors imply and rather closer than platform vendors imply. Two things move it more than anything else: whether you already employ the engineers, and how much of your revenue is concentrated in peak days that infrastructure has to survive.

The trap on both sides is the same. Platform quotes forget that the storefront still costs money to build and evolve. Custom quotes forget that year two through five have a headcount in them.

What custom genuinely wins

A data model shaped like your business. No translation layer, no metafield gymnastics, no workaround documented in a spreadsheet.

No percentage on your revenue. At sufficient scale, transformative.

Integration without permission. Your ERP, your pricing engine, your CRM, your custom logic, joined however makes sense.

Compliance and residency control. Where you store data, how long, and who can reach it. For some sectors this is the whole argument.

No category risk. Nobody can review your account and close it. For brands in categories platforms dislike, this is business continuity, not preference — we go through it in selling restricted products online.

What custom costs that nobody quotes

Checkout, properly. You are now responsible for the highest-stakes, most-optimised piece of software in commerce. Every percentage point you lose against a platform checkout is a permanent tax on the decision.

Security, forever. Payment paths, dependency patching, penetration testing, incident response. This never ends and it does not scale down when you are busy.

Every boring feature. Gift cards, discount stacking rules, tax edge cases, partial refunds, address validation, fraud screening, subscription dunning. Each is small. Together they are years.

The admin. Somebody has to build the tools your team uses. Custom builds routinely ship a beautiful storefront and an admin nobody wants to use, and then the operations team quietly runs the business out of spreadsheets.

Peak readiness. Load testing, capacity planning, and the confidence to trade on your biggest day.

Institutional knowledge. When the two people who understand the pricing engine leave, that is now a risk with a name.

The narrow band where custom wins

Two axes: revenue scale, and how unusual your commerce logic is.

High revenue, ordinary logic — an enterprise plan, almost always. You are buying reliability and a lower fee, and there is nothing to gain from owning the model.

Low revenue, unusual logic — an enterprise plan plus real engineering effort in the seams. You do not have the scale to fund a platform, and the unusual parts can usually live beside the platform rather than replacing it.

High revenue, unusual logic — this is the band. Enough scale to fund the team, and enough structural mismatch to justify owning the model.

Low revenue, ordinary logic — you should not be reading this article.

Most brands who ask us this question are in the first square and have been quoted for the third.

B2B is where this question gets decided most often

More of these conversations start with wholesale than with anything else, so it deserves its own section.

A brand selling to both consumers and businesses needs customer-specific pricing, quantity breaks, purchase orders, credit terms, approval chains, restricted catalogues, and often a completely different tax treatment. Historically that was the clearest possible case for a custom build, because platforms simply did not model it.

That has changed materially, and it keeps changing, which is why generic advice ages badly here. Enterprise commerce plans now carry real B2B capability, and for a large share of wholesale businesses it is sufficient. The brands for whom it still is not tend to share three traits: pricing that is negotiated rather than tiered, approval workflows with more than one step, and an ERP that must remain the source of truth for both price and availability.

If that is you, the middle option is again usually right — keep the platform for the consumer side and build the B2B portal as an application that talks to it. You get the strange logic modelled properly without duplicating a catalogue or owning a checkout.

If it is not you, test the platform’s B2B features against three real customer scenarios before deciding anything. Not a demo: your actual pricing agreements, your actual approval chain, your actual credit terms. Two days of testing has saved more brands from a bad architecture decision than any amount of comparison reading, including this.

The option in between, which is usually the answer

Keep the platform for what it is genuinely excellent at — catalogue, cart, checkout, payments, fulfilment, PCI — and build the unusual part as a service beside it.

A configurator that computes a price and hands a line item to the cart. A pricing engine that syncs to the platform. A B2B approval workflow that sits in front of an ordinary order. A subscription engine that owns the schedule while the platform owns the charge.

You get your data model where it matters, you keep the checkout that converts, and you avoid owning the security of a payment path. It is less satisfying as an architecture diagram and it is right far more often than either extreme.

The tell that this is your answer: your unusual requirements cluster in one or two places rather than running through everything. If you can draw a box around the strange part, build the box.

The five-year line items, side by side

Neither column is a quote. It is the list of things that will appear on your books, which is the part both pitches leave incomplete.

The honest summary: the platform converts most of these into one predictable number. Custom converts them into a headcount. Which of those two your business is better at carrying is not a technical question at all.

What we would want to see before recommending custom

Five things. Not one of them is about the storefront.

A written description of the commerce logic that does not fit, in plain language, that survives a challenge. If it turns into “we would like more control” under questioning, it was never a constraint.

A named engineering owner and a second one. Not a contractor, and not one person.

A five-year budget that includes year three. Custom projects fail in year three, when the build enthusiasm is gone and the maintenance is not.

A plan for checkout that is not “we will build our own”. Either you keep a proven one, or you have a specific, funded, tested plan for beating it. Most brands should keep one.

Executive patience. A platform store ships in weeks and improves continuously. A custom build takes months before anybody outside the team sees anything. Organisations that cannot tolerate a quiet quarter should not start one.

If four of those five are absent, we will say no. It is a smaller engagement for us and a much better outcome for the client — the same reasoning we apply when auditing a store before a replatform.

Three ways this decision goes wrong

Buying custom to fix a theme problem. The most common and the most expensive. The store feels rigid, everyone assumes the platform, and the actual constraint is a storefront that was built without any flexibility. Rebuild the storefront first — it is a fraction of the cost and it removes the question.

Buying enterprise to fix an operations problem. A tier upgrade does not fix a broken fulfilment process, an unowned data quality problem or an app pile-up. It just makes them more expensive.

Splitting the difference badly. Custom commerce with a platform checkout bolted on afterwards, or a platform with so many bespoke services around it that nobody can say where the source of truth is. Both happen when the architecture is decided incrementally rather than at the start. Decide the source of truth for pricing, stock and orders on day one and write it on a wall.

What it comes down to

An enterprise plan is a very good deal for a business with ordinary commerce logic and extraordinary volume. A custom build is a very good deal for a business whose commerce logic is genuinely part of what it sells, and which can fund an engineering team indefinitely.

Almost everything between those two poles is better served by a platform plus one carefully-built service.

The question we would ask before anything else: if the two people who best understand your commerce logic left next quarter, would the store still work? On a platform, yes. On a custom build, only if you funded it properly. That answer decides more of these than any feature comparison.

Been given two very different quotes? Send us both through the contact form, along with a sentence about what your business does that a standard commerce model cannot express. We will tell you which of the three “custom” projects you have been quoted for, whether the crossover is realistic at your scale, and whether the strange part could simply be a service beside the platform.

You can also read what replatforming actually costs or Shopify vs WooCommerce at scale.