Shopify vs a Custom-Built Store: When Custom Makes Sense

Every few months a founder or a CTO asks whether they should just build it. The reasoning is usually sound on its face: we have engineers, we know our business better than any platform does, we would own everything, and we would not pay a subscription forever.

I want to take that seriously rather than dismiss it, because there are cases where building is correct. But I also want to be direct about what you are actually signing up for, because the cost is consistently underestimated — and the part people underestimate most is not the build.

What “custom” actually means

Be clear about scope first, because the word covers three very different things.

Fully custom means building the commerce platform itself: catalogue, cart, checkout, payments, order management, inventory, admin, the lot. You own every line and every obligation, including PCI compliance for card handling.

Headless with a commerce backend means building a custom storefront while a platform handles commerce and checkout underneath. Shopify’s Storefront API, Hydrogen, and headless builds live here. You get front-end freedom without rebuilding the risky parts.

Custom on a platform means using Shopify normally but building whatever bespoke functionality you need through custom apps, Functions, and integrations.

When people say “build our own,” they usually mean the first. Very often what they actually need is the second or third, and realising that saves an enormous amount of money.

The costs people underestimate

The build is the part everyone budgets for. Here is what tends to get missed.

The checkout is not a feature; it is a discipline. You are handling card data, which puts you in PCI scope. You need fraud prevention, 3D Secure and strong customer authentication where required, wallet payments, saved cards, failed-payment handling, refunds, partial refunds, and chargebacks. Shopify’s checkout is among the most optimised on the internet because Shopify has spent a decade and enormous resources on it. Yours will not match it, and every conversion point you give up is revenue forever.

Security is permanent. Dependencies need patching, vulnerabilities need responding to, and a breach on a system you built is your liability in a way a platform breach is not. That is not a project; it is a standing obligation with no end date.

Compliance keeps moving. Tax rules change. Privacy law changes. Accessibility requirements tighten. Payment regulations shift. On a platform, most of that arrives as an update. On your own system, each one is a ticket.

The admin is a product too. Your operations team needs order management, inventory, refunds, fulfilment, reporting, staff permissions, bulk editing. Shopify’s admin represents years of refinement, and every hour your team loses to a worse one is a real cost you will not see on any invoice.

Integrations are yours to build and keep working. No app store. Every payment provider, shipping carrier, tax service, email platform, review tool, and analytics connection is bespoke work, and each one breaks when the other side changes.

Scale is your problem. Traffic spikes need provisioning and load testing. The day you get the most attention you will ever get is the worst day to discover you got it wrong.

And the team must persist. This is the one that kills custom builds. A platform someone built and left becomes a liability nobody wants to touch. You are committing to keeping commerce engineering capability for as long as the store exists, through hiring markets and budget cycles you cannot predict.

When building makes sense

There are real cases, and they share a characteristic: the commerce model itself is the product, not a way to sell the product.

Your business model is not retail. Marketplaces with multi-vendor payouts, rental or resale platforms with complex inventory states, auction or bidding models, usage-based billing, or anything where the transaction logic is fundamentally different from “customer buys item.” Platforms assume retail; if you are not doing retail, the assumptions fight you.

Commerce is embedded in a larger product. If selling is one function inside a bigger application — a SaaS product with a marketplace, a service platform with transactions — building commerce into the application is often cleaner than bolting on a separate store.

You operate at a scale where platform fees exceed engineering costs. At large volume, revenue-linked platform fees can exceed what a capable in-house team costs. That crossover is higher than most people estimate and the calculation must include everything above, but it exists.

Regulatory or data-residency constraints rule out SaaS. Some sectors and jurisdictions require control that a hosted platform structurally cannot provide.

Commerce is your competitive advantage. Rare, but real. If how you sell is what differentiates you — not what you sell — owning that system may be strategic.

Notice what is not on this list: wanting more design control, disliking subscriptions, having engineers who would enjoy it, or needing a feature no app provides. Those are all solvable within a platform, usually for a fraction of the cost.

The middle path most brands miss

Here is the option that resolves this for the large majority of people asking.

Keep Shopify as the commerce engine — catalogue, cart, checkout, payments, orders, admin — and build custom exactly where you need it. A headless storefront in Hydrogen or Next.js if the front end is your differentiator. Custom apps for bespoke logic. Functions for pricing, shipping, and validation rules the standard tools cannot express. Custom integrations into your internal systems.

You get the custom experience and the bespoke logic, and Shopify keeps handling the checkout, PCI compliance, scaling, security patching, and the admin your operations team lives in. The risky, expensive, permanently-obligating parts stay with the platform.

For nine out of ten brands who arrive at “should we build our own,” this is the answer they actually wanted. It is worth testing seriously before committing to the full build, because the cost difference is enormous and the capability difference is usually small.

A worked example: the build that got talked down

A subscription brand with a unusual model — variable bundles, complex proration, customer-specific pricing that changed with tenure — came to us convinced they needed a custom platform. Their engineering lead had scoped it and the estimate was substantial but not absurd.

The scoping conversation went differently than they expected. We worked through their requirements one at a time and asked, for each, whether Shopify could express it. Variable bundles: yes, with a custom app. Proration: yes, through their subscription platform’s API with custom logic. Tenure-based pricing: yes, via Functions. Custom customer portal showing their unusual plan structure: yes, built against the APIs on their own domain.

What they would have rebuilt from scratch — checkout, payments, PCI scope, order management, inventory, the admin, fraud handling, tax — was all functionality they had no unusual requirements for at all. They were planning to spend most of their budget rebuilding commodity infrastructure in order to get four features.

They built the four features on Shopify instead, for a fraction of the estimate and in about a quarter of the time. Two years on they have no in-house commerce platform team, which is the cost they never priced in the original plan.

The general lesson: separate the requirements that are unusual from the ones that are just requirements. Almost always the unusual list is short, and almost always it can be built on top of a platform rather than instead of one.

If you do build, do it with open eyes

Should you decide custom is right, a few things make the difference between a good decision and an expensive one.

Do not build the checkout unless you must. Even brands with fully custom storefronts frequently keep a platform checkout, because the conversion, compliance, and risk profile is so much better.

Budget for the decade, not the launch. Model ongoing engineering, security, compliance, integration maintenance, and admin tooling across several years, then compare that with platform costs over the same period. Honest numbers change a lot of minds.

Plan for the team persisting. Who maintains this when the person who built it leaves? If you cannot answer confidently, you have found your biggest risk.

Start narrower than you think. Build the bit that is differentiated, and use existing infrastructure for everything else.

The ten-year cost model nobody builds

If you want to settle this argument internally, build the model properly. Most custom-build business cases compare a one-off build cost against a recurring subscription, which is not a comparison at all.

A defensible model runs several years and includes, on the custom side: the initial build; ongoing engineering to maintain and extend it; security patching and incident response; compliance work as tax, privacy, accessibility, and payment rules change; integration maintenance as third parties change their APIs; infrastructure and scaling; admin tooling your operations team needs; and the recruitment and retention cost of keeping commerce engineers.

On the platform side: subscription fees across the period; app subscriptions; and the custom development you would still do on top — apps, Functions, integrations, storefront work.

Then add two things most models omit. First, opportunity cost: what else would those engineers have built? Engineering spent on commodity commerce infrastructure produces nothing a customer notices. Second, conversion difference: if your checkout converts even slightly worse than Shopify’s, multiply that gap by your revenue across the whole period. That number alone frequently exceeds the entire platform fee.

Run that model honestly and the answer is usually clear. Run the naive version and custom always looks cheaper, which is why so many of these projects get approved and then quietly regretted.

What actually goes wrong on custom builds

Patterns repeat, and they are worth knowing before you commit.

The team changes. The engineers who built it move on, and their replacements inherit a system with no external documentation, no community, and no Stack Overflow answers. Velocity collapses. This is the single most common failure.

Version one takes far longer than planned. Commerce has more edge cases than anyone estimates — partial refunds, mixed carts, tax edge cases, address validation, failed payments, inventory races. Each is small; together they are most of the project.

The admin gets neglected. Customer-facing features get priority, so the operations team limps along with something half-finished, and the hidden cost lands on the people packing orders.

Integrations rot. Every connection you built is maintained by you. Third parties change APIs on their schedule, not yours.

Compliance surprises arrive. A tax change, a privacy regulation, an accessibility requirement. On a platform these arrive as updates; here they are unplanned projects.

Peak season exposes provisioning. The highest-traffic day of the year is the worst possible time to discover a capacity assumption was wrong.

None of these is inevitable with a strong team and honest planning. All of them are common enough that you should plan for them explicitly rather than assume you will be the exception.

Side by side

A decision sequence that works

Run these in order. Most people stop at step three.

One: write down what is unusual about how you sell. Specific rules in plain sentences, not categories. “Customers build a bundle from six tiers with pricing that changes at their twelve-month anniversary” — that kind of thing.

Two: for each item, ask whether Shopify can express it through an app, a Function, the Storefront API, or an integration. Get a technical opinion rather than assuming. Most lists come back mostly achievable.

Three: for anything that does not fit, ask whether it is essential or inherited. A surprising share of unusual requirements are accumulated history that nobody can justify when questioned directly.

Four: if unfittable requirements remain, ask whether headless solves them. Front-end and experience constraints usually dissolve here while commerce stays on the platform.

Five: only if the remaining gap is in the commerce logic itself — the transaction model, not the storefront — does a custom platform become the reasonable answer.

If you reach step five with a real list, build with confidence. Most organisations do not get past step three, and finding that out costs a week rather than a year.

The bottom line

For the overwhelming majority of brands selling products, building a custom ecommerce platform is the wrong economic decision, and the reason is not that platforms are more capable — it is that you would be rebuilding commodity infrastructure at great expense to obtain a handful of features a platform could have given you.

Custom is right when your business model is not retail, when commerce is embedded in a larger product, at exceptional scale where fee structures invert the maths, or under regulatory constraints that rule out SaaS. Those are real and they are narrow.

For everyone else the productive question is not “platform or custom” but “what specifically do we need that the platform will not do?” Write that list down. It is usually shorter than expected, and it is usually buildable on top of Shopify through custom development, Functions, and integrations — at a fraction of the cost and with none of the permanent obligation. If you want that list pressure-tested before you commit engineering budget, we are happy to do it, including telling you when building is the right call.

Frequently asked questions

How do I present this decision to a board or investors?

Build the honest multi-year model rather than comparing a build cost to a subscription. On the custom side include the build, ongoing engineering, security and compliance work, integration maintenance, infrastructure, admin tooling, and the cost of retaining commerce engineers. On the platform side include fees, apps, and the custom development you would still do on top. Then add the two lines most business cases omit: the opportunity cost of engineers working on commodity infrastructure instead of differentiated product, and the revenue impact if your checkout converts even slightly below a platform checkout, multiplied across the whole period. That last figure alone often exceeds the entire platform fee, and it tends to end the debate quickly.

We have an in-house engineering team already — doesn’t that change the maths?

It changes it less than you would expect, because the question is not whether you can build it but what else those engineers could be doing. Commerce infrastructure is commodity work: checkout, payments, order management, inventory, and admin tooling are solved problems that produce nothing your customers notice. Engineering spent there is engineering not spent on whatever actually differentiates you. Having a team also does not remove the permanence problem — you are committing to retaining commerce capability indefinitely, through hiring markets and budget cycles nobody can predict. The strongest teams we work with reach the opposite conclusion: they use a platform precisely so their engineers can work on things that matter.

Is it cheaper to build a custom store than pay Shopify fees?

Almost never, once you count honestly. The build is the visible cost; the invisible ones dominate — permanent security patching, compliance that keeps moving, integration maintenance, admin tooling your operations team needs, scaling and load testing, and above all keeping commerce engineering capability employed for as long as the store exists. Platform fees look like the obvious line item because they arrive as an invoice, while engineering costs hide inside salaries. At exceptional volume the maths can invert, but the crossover point is far higher than most people estimate, and it requires a team you can reliably retain.

Should I build my own checkout?

Almost certainly not. Handling card data puts you in PCI scope and commits you to fraud prevention, strong customer authentication, wallet payments, saved cards, refunds, and chargeback handling. Shopify’s checkout is among the highest-converting on the internet because it has had a decade of dedicated optimisation, and whatever you build will convert worse — which is lost revenue forever, not a one-off cost. Even brands running fully custom storefronts usually keep a platform checkout for exactly this reason. It is the clearest example of something that looks like a feature and is actually a permanent discipline.

What about headless — is that the same as custom?

No, and the distinction matters enormously. Headless means building a custom storefront while Shopify continues handling commerce, payments, checkout, and the admin underneath, connected through the Storefront API. You get near-total front-end freedom without taking on PCI scope, checkout optimisation, or platform maintenance. That is a very different risk and cost profile from building a commerce platform. For brands whose differentiation is the customer-facing experience rather than the transaction logic, headless usually delivers what they actually wanted from “custom.”

When is building the right call?

When your business model is not retail — marketplaces with multi-vendor payouts, rental or resale with complex inventory states, auctions, usage-based billing — because platforms assume a customer buying an item and fight you when that assumption breaks. Also when commerce is embedded inside a larger application, at exceptional scale where revenue-linked fees exceed a capable team’s cost, or under data-residency rules that rule out SaaS. Wanting more design control, disliking subscriptions, or needing a feature no app provides are not on that list; all three are solvable on a platform for far less.